It would need a lot more than that, you would have to do it for feature tables like mp_HtmlContent, mp_Blogs etc., pretty much most tables. I think it will be an overly complex solution and will lead to problems that are hard to figure out.

mojoPortal was not deisgned for pushing content from one server to another. You can stage content right in the site by creating a section of the site that is only visible to content authors and approvers then push the content from a non public page to a public page (ie visible to all users).

I recommend create all content on the production server. For testing get a backup of the production db and files and restore it on a dev machine.

I do not ever recommend pushing from dev or staging to production, production should be the definitive db and dev should use a restored copy of production.

Hope it helps,

Joe

To me when discussing testing I'm talking about software testing and there is nothing unusual or unnatural about testing on a copy of production data. In fact in my experience that is the norm.

Now in terms of content review and publishing yes there are systems that do it as you would like, but that involves a good deal more complexity. From a users point of view as long as content can be reviewed and approved I don't see where a multi server or multi installation architecture for publishing is to be considered always better. The vast majority of companies want simplicity and are not running sites on web farms and those are my primary targets. If some mega company wants to use mojoportal and they need this kind of formality of architecture they can sponsor development to get what they need or pursue other solutions. I certainly don't say mojoportal is the best solution for every situation, but its a damned good solution for most businesses.

If you'd like to build an API to deploy content in that fashion feel free, I'm not opposed to it but I think it will be challenging. Perhaps it should just be for the Html module to keep it simpler. Other features like blogs and forums it just doesn't seem to make sense for as the content often comes from the community and enters the system naturally through the production site. So definitely if using those you would want to sync from production to test or staging.

The main challenges as I see them are the fact that images are uploaded to the file system and the urls which are part of the content may be different for the dev and production environments unless you structure the staging site very similar. It does use releative urls for the html module, but the blog for example uses fully qualified urls because theyare needed for outbound rss feeds to correctly show them.

The other challenge that comes to mind is keeping the search index synchronized as it is also file system based.

These same issues also make mojoPortal not quite suitable for web farm deployment. I plan to implement a solution for web farm support but it will be an add on product and will not be free because it will reqwuire a lot of work and most people won't need it.

Best,

Joe

I think if I were going to implement this the way I would go about it is to implement RESTful web services for the features that need to be published this way. This would make the image handling and search index sync much easier because content coming in via the web service can be handled the same as from the web UI. Then a cross site publishing can be implemented by site to site web service requests and its very de-coupled and much less complex than directly talking to another site's db.

Best,

Joe

Sounds like we are in agreement about never restoring a db from dev to production and really have the same concerns but talk about it from different angles.

I am not opposed to an API for cross site publishing workflow for specific content features. We don't have it now but if anyone wants to work on it and willing to implement it as RESTful web services they will have my support. I would even consider implementing it myself if someone wants to sponsor it financially, but short of that its not a high priority for me.

Content versioning is coming in the near future and will make it possible to mitigate most concerns about losing any previous version of content. It will be easy to preview and restore any previous version.

Also a better approval workflow system is planned but currently it is envisioned as self contained in a single site. The combination of this with content versioning to me seems like it would meet most requirements. I will think about how to do this as web services and then maybe the same solution can be configured for cross site workflow.

Best,

Joe