modx_staging - staging module, was: Draft Mode or Editor Mode for site.

It would be the cat’s pajamas if it could synch. between a localhost site and a remote site.

Syncing indeed can be tricky. How would you propose handling a situation where new functionality is being worked on in development (say a new password protected area), but ongoing content is being added to the live site (e.g., press releases).

Thoughts?

I toyed with the idea of setting the auto-increment on the live site to something really high, but there’s problems there too … perhaps the live site needs a plugin that populates new docs to both places on save, or at least checks the next available doc ID from the staging site. Or ideally you’d have a grid that allowed you to selectively migrate pages (and associated TVs) from staging to live. It gets complex fast!

Quote from: rthrash at Jan 26, 2009, 04:48 AM

Syncing indeed can be tricky. How would you propose handling a situation where new functionality is being worked on in development (say a new password protected area), but ongoing content is being added to the live site (e.g., press releases).

Thoughts?

That’s a good question - I haven’t really thought about that problem.

Briefly, if the development is affecting different tables from the content updates, and different file folders, then combining the two shouldn’t be too hard. But, remember, this is table-level solution. If both the dev-site and the staging-site modify the same tables, then a row-level solution would have to be made. Then you get into mucking with keys and row duplicates, etc etc. At that point, I think, you would want to rewrite the CMS from the ground-up to handle staging.

Updated my first post with version 0.21 of the staging module.

I realize this is an old thread, and Revolution will fix this issue, but I’m currently working with Evolution, and I came up with a similar solution. The problem I have is that by doing a table-by-table drop and copy from the staging to the live server, end users could potentially receive a deformed page, or a file-not-found, or some sort of other error. More importantly, we have a system in place that monitors whether the web server is up and running. If it attempts this verification during the aforementioned table-by-table drop and copy, it has—on at least one occasion—thought that the site was down, and proceeded to kick us over to the backup server.

I’m thinking a better solution might be to point the live server at the staging database temporarily, then update the live database, then switch back...

Anyone have any thoughts?

Also, are there any consequences to simply dumping the siteCache.idx.php file in addition to the *.pageCache.php files. Again, I’d come up with something very similar, but was afraid to just dump the siteCache.idx.php file...

This module is very useful, but the config string is wrong. You set rm_path and rsync_path, but use $rm and $rsync. You have to change either of this...

Quote from: bmiller at Apr 29, 2010, 02:44 PM

I realize this is an old thread, and Revolution will fix this issue, but I’m currently working with Evolution, and I came up with a similar solution.

I’m starting with Revolution and I’m curious how it is supposed to fix the issue?

All what I see is this doc, but wonder what kind of workflow is one supposed to have for: developing locally ---> staging ---> production