Crazy Idea (Synchronization)

Hi guys,

This is one crazy idea that I think will be very2 useful for MODx and Tattoo. Ever thought about having Synchronization capability for MODx/Tattoo? Here is where the idea comes from. When I was planning to prepared myself before going back to my homeland, I struck with the fact taht in my homeland, internet connection is not as reliabale and as fast as US. So I was thinking to have MODx being built offline, while it will later can be deployed on the production server. Well this thing basically had been covered, it’s so simple and easy, all we need is just to dump all the data to the server and re-adjust the config file.

Now I do realize that I have this core hack to allow several domains being hosted under one MODx. SO Site Administrator able to see all the documents for all the domain hosted on this MODx installation. It’s good for small dynamic website that can be easily maintained by me. I’ve used this hack for this past few months for 4 websites that are now running just fine with no problem. So to cut the story short, if I use this kind of installation, there is no way for me to close the production server, dump all database from production server to local server, create and edit a new page as necessary and re-dump the file to the production server, and open up the production server again. This is so inconvinient.

So here is the idea, basically MODx has a logging capability built into the system already. If we can analyze this log, then we can do all the necessary syncronazation between the production server and local/development server. This can also be use to mirrored a site, and have the mirrored site to syncronize its data with the main site every night.

What do you guys think? I haven’t set any plan to do this yet, but this will be one major thing that might be one of the swiss army for MODx to stand different from others.

Let me know if it’s do able.

PS: The files/folders syncronization inside the assets folder will be tough though, if somebody have an idea to handle this, it will be totally awesome.

Thanks

Wendy, this will be possible via a planned feature called Deployment Packages in Tattoo. That’s not an official name; just what I’m calling it so far. The idea is that any persistent object or static web resource managed by the CMS can be exported to a data source agnostic, serialized format (not using PHP serialization, as this is incredibly inefficient) that can then be imported into another deployment via the Tattoo installation services. In fact, the core installation will simply be a quick check for/creation of the proper data structures for the version of the objects being stored, followed by the import of a core Deployment Package (including any necessary data transformation that might need to occur to recreate the object in the version of the system being imported into). In this way it will be easy to create custom CMS deployments for niche markets, rebrand a distribution package for your new business, easily distribute web applications comprised of various related components, or simply move your site (or a subset of it) from a test environment to production.

True offline content publishing and synchronization is another feature I’d like to think about as well, and could probably be implemented using this same mechanism in conjunction with the planned content revision services in Tattoo, but that will take a lot more thought and work to implement effectively.

I’ll reserve comment on how/if these or similar features might be implemented in future release of MODx, though I see no reason to think the same concepts could not be applied to MODx in some form.

Jason, it seems that you have everything organized so far. Honestly, I’m still wondering how you’re going to achieve all that with Tattoo with only you do the hard coding yourself. But anyway, I’ll look forward for the first alpha release of Tattoo, and can’t wait to start contribute to the code.

As far as MODx goes, I think I will need to wait for Raymond thought on this.

Hi ,

(Kinda late but...)

I think it’s a great idea and would like to see it working in both MODx and Tattoo.

I think a few of the commercial CMS has this capability but they call it staging where the content is developed offline then publish to an online server.

Cool, that sounds much better to me.

The only concern that I have right now, imagine having all the links hardcoded with the document id, while the document id is basically some integer number being auto incremented by mysql. Great, imagine having 2 sites running, the first one is the production site. We have some snippet like newspublisher to allow user create a new docs and etc. Now we have the second site which is the test site, which have the current latest data from 2 days ago. Now the development team start to code several things on the testing site and create a few new docs. Lets see what’s gonna happen when we sync them both? The one on the production site has a docid with different content, and the documents created on the testing site can be appended to the latest incremental number, but how about all the hardcoded doc id on the template or on the doc that linked to other docs, which based on the testing site doc id, not the one on the production site.

It’s a simple problem, but it might cause several issue. The best solution will be to avoid the use of id in document linking, we can use plugin that Jason created a while back, but it’s still not a good idea, considering certain snippet such as newslisting and etc are depending so much on doc id.

The best solution will be to use UID, the chance of conflicting id will still be possible, but the chance is farrr lesser than using auto increment number. I can see the reason why true database server mostly use uid instead of auto increment.

Any thought on this? I’ve suggested a better user system for MODx, with SSO capability, as well as this staging system (the cool name ). I do think that this is a major features that are important to our product. More discussion regarding this will be awesome, so we can come up with a really2 good solution from all the team.