Trying to do a fully automated MODx deploy

Hi,

I’m currently running MODx Evolution (rev 6066) with friendly URLs turned on. I have the MODx codebase stored in Subversion (SVN), with a deployment script which takes the latest version of the code from SVN, deploys it to the server and puts it live.

Stored in assets/cache in SVN are only the following files: index.html, siteCache.idx.php, sitePublishing.idx.php and the rss folder.

MODx is being served by Nginx using rewrite rules to correctly direct traffic to the MODx front controller.

My problem then is this: whenever I do an automated deploy from SVN, the front-end URLs break: accessing any content URL shows me the standard Nginx "ERROR: Too many forward attempts!" error message. To fix this, I have to log into MODx’s /manager back-end and either press Save on any resource page or toggle a feature like Friendly URLs off then on again. So it feels like the problem and fix may be caching related?

I guess my main question is: is there something I’m storing or not storing in SVN that is causing this problem? If not, and this is a feature of MODx (perhaps something to-do with cache rebuild), then is there any way I can automate the fix in my deployment script (e.g. a MODx page I could wget)?

Interested to hear your thoughts, thanks in advance for any help you can give.

Alex

I am also very interested in this as well but how do you deal with the database side of things?
Do you run the build scripts manually or take a vanilla build then update the relevant tables?

Quote from: thiswayup at May 17, 2010, 08:45 AM

I am also very interested in this as well but how do you deal with the database side of things?
Do you run the build scripts manually or take a vanilla build then update the relevant tables?

I ran the MODx installer to initially populate the MySQL tables. Then I wrote a custom script (Bash, though will eventually move it to Python) which takes the current contents of the database and stores it in a populate_db.sql file in SVN. This allows the team to make changes in the MODx manager interface which I can then store to SVN.

The siteCache.idx.php is your problem. You need to not store that in Subversion, and make sure when deployment is completed that your trigger the clearing of the cache.

Quote from: OpenGeek at May 17, 2010, 10:38 AM

The siteCache.idx.php is your problem. You need to not store that in Subversion, and make sure when deployment is completed that your trigger the clearing of the cache.

Thanks Jason, I’ve now deleted siteCache.idx.php from Subversion and now I get a MODx error instead of an Nginx one after deployment. The fix is still the same (go into the /manager back-end, Save any page).

As the next step, how do I programmatically trigger the clearing of the cache? Is there a page I can wget or a table I can empty?

Thanks,

Alex

Quote from: alexatkeplar at May 17, 2010, 11:19 AM

Thanks Jason, I’ve now deleted siteCache.idx.php from Subversion and now I get a MODx error instead of an Nginx one after deployment. The fix is still the same (go into the /manager back-end, Save any page).

As the next step, how do I programmatically trigger the clearing of the cache? Is there a page I can wget or a table I can empty?

Yeah, the problem is you need a valid file there that is writable for MODx to operate (and Evo does not recreate it if it does not exist, Revo does however).

To trigger the cache process in Evo, you will need to execute the synccache() function from cache_sync.class.processor.php. You will need to create this as either a CLI PHP script you can execute or find a way to do it via a secured Resource/Snippet in MODx. The CLI approach will be much easier IMO.