setting up a two-tier acceptance/production environment

Simply put, my users want to be able to preview page changes without overwriting the existing version of the page on the production server.

My rough gameplan for this is to make their working MODx Manager environment be an acceptance server. They can save the pages and preview the changes, and have not yet overwritten the production version.

Then when they are certain they want to publish to production, then can do so via **some extended bit of functionality that I have yet to identify**.

Ideally, I’d like to add a "Publish" button to the floating button set (Save/Cancel/etc.). Could that be done, and tied to Provisioner(?), so that when clicked it would mirror the current resource from the acceptance server to the production server?

Also, if the above scenario is feasible, I’d like to hide the "Published" checkbox and make all resources published by default (to the local/acceptance server) so as not to confuse the meaning of "publish".

Am I on the right track in solving this problem, or is there some cleaner/more elegant way to do this?

Provisioner only pulls, it doesn’t push, so to use this you would have to get your production user to update the resource in question from the acceptance server, not the other way round. You could have manager open in two tabs, one on acceptance, one on production, when ready the user would go to the production tab and use Provisioner to ’pull’ the change.

Not very integrated as you would have to find the resource to pull in Provisioner’s resource tree but doable, especially if you split your browser panes so you can see both sites at once.

OK, so Provisioner - as it currently stands - is out.

How about just writing some PHP that would copy the current resource from the ’acceptance’ modx_site_content table to the production modx_site_content table. Could I create a button that would fire a plugin and do that?

Where are your databases? If they are on the same server this is fairly easy, get your resource, make a connection to the production database, write it into it. Note they will both probably end up with differing id’s but your users probably won’t worry about that. If you have two physically separate servers it becomes harder.

I had tentatively been planning to use separate physical servers, but I’m not tied to that. Just out of curiosity, why is it more difficult? Is it because it is a second/separate SQL connection, as opposed to just choosing a different database on the existing connection?

The idea of the resource IDs not being in sync does not sound good. I’d have to have some way of mapping them; publishing the acceptance version of a resource to production could be done an infinite number of times with any given resource - it would have to know which resource to overwrite. It seems like having the resource ID be identical on both servers is essential to pulling this off (or at least, would avoid a whole lot of extra complexity).

My thought was

• retrieve the entire record for the resource from the acceptance server from the modx_site_content table
• check to see if a record with matching resource ID exists on the production server
• If so, do an UPDATE; if not, do an INSERT

Am I way oversimplifying this? Is there a whole bunch of other stuff that happens when a resource is saved besides the modx_site_content record being updated?

Most MYSQL server setups are configured to run on localhost which is not exposed to any of the external network interfaces on the server, i.e its not visible outside the box itself. It doesn’t have to be like that, they can be anywhere but they must be visible.

if you want to connect to a MYSQL server on a separate physical server you will need to expose it through that machines firewall and map it to an network interface so you can see it. On a local LAN this is not so bad as no one on the internet can see it but on internet connected machines it is, because everybody will be able to see it and you will quickly become the object of attacks, this not to be recommended.

As far as the syncing goes you can’t really do this using id, separate MYSQL servers can’t really be forced to use the same id’s in tables.

The INSERT will generate a new id on production every time, there is nothing to say it will match the id on acceptance, your just relying on timing here. Initially you will have to use INSERT, you can only UPDATE after this. You’d be better of matching on page title assuming each resource is titled differently rather than id.

Then theres backup’s/restores/failures to consider also.

Perhaps this plugin would work for you? http://modxcms.com/extras/package/77
Essentially, this lets you save several document versions. Haven’t used it in a while, the last time was when 0.9.6.2 came out or thereabouts. A great, and often overlooked plugin, imho.

Sorry, didn’t realize this was a Revo thread... must be the sun...

On a local LAN this is not so bad as no one on the internet can see it

It would be on a local LAN if I did do two separate servers.

You’d be better of matching on page title assuming each resource is titled differently rather than id.

I don’t think I could safely assume unique titles. However, I believe that context+alias is unique when friendly URLS are used... so I suppose I could match on that.

But no - not having identical IDs would blow up any code that uses hard-coded IDs in links. If the page author puts a link to [[~17]] in their page, then resource #17 on the production box better be what they are expecting it to be...

OK, I’m probably already halfway up the wrong tree here, but how about this:

On acceptance server:
-hide the ’published’ checkbox
-onDocFormRender plugin: set ’published’ to 0 (always sets to unpublished when a doc is opened for editing)
-"Publish" button - duplicates ’save’ button, but sets ’published’ to 1 before saving. (And only appears after a document has been saved once???)
-onDocFormSave plugin:

• check value of ’published’
• check whether this resource has been saved before (can this be done?)
• if never saved before, then copy to production server (INSERT) w/ ’published’=0
• ...throw an error if the id’s don’t match
• if has been saved before, and published=1, copy to production (UPDATE)

It seems like with a setup like that (and assuming that you started with both ’acceptance’ and ’production’ resource ids in sync), you’d always have matching resource ids on both sides (and throw an error if some sort of weird race condition happens and you don’t).

I think this solution currently suffers from a complete lack of understanding of how & when plugins work. But... is there anything in there that someone with smarts could turn in to a viable solution?

One thing I omitted to mention above was deletions, you’ll have to delete from both servers at the same time so you’ll need to hook this as well. Also if the id’s don’t match and you throw an error what do you expect the user to do here? Presumably no one can ’use’ the production server i.e. create content in it directly either.

I think I can see what you want, you want created resources to be visible only after some ’vetting’ process has been undertaken, if passed its released to the main site, the only real way of doing this at the mo is to use the publish/unpublish feature. I don’t think theres a solution to this sort of workflow other than publish/unpublish, especially across two servers/databases. On the upside if you do get this working robustly expect many a call from MODxers!

My thoughts along this line are that a good versioning system is the first step in almost any type of workflow implementation, including two-tier environments.

I’m sure many of us would benefit from some focus being placed on resource versioning. The feature appears much more feasible in Revo. I can’t imagine these types of workflows being implemented well without versioning. I can’t imagine a workflow situation that couldn’t be more easily implemented on top of a good versioning system.