Hi all! I have been discussing staging with a customer. If you have any suggestions or experience in this matter, I'd be grateful. It seems to me that this kind of staging is not really possible unless staging features are built into every part of the system. But I could be wrong. These are the alternatives we have discussed:
0. Preface - The system should be split in two: a staging part and a production part. They do not have to be different servers or even different eZ Publish installations. - Staging requires login, production does not (obviously). - There are several editors producing content, and several administrators approving content. - It must be possible to preview the complete state of the staging server before content is approved. This rules out the standard approval workflow, because it does not publish content until it is approved. - The editor activates a mechanism that sends an email to the administrators - The administrators get a mail with a link to the content, where they can approve or deny. - Enhancement: A feature for reverting and merging changes, like in svn. 1. One installation, two subtrees On approval, content is copied from the staging subtree to the production subtree using a custom module. Pros: + This can at least theoretically satisfy all the requirements in my case Cons: - Copying content is simple enough. But there are many other possible changes, like moving/deleting content, and changing section, relations, priorities, sort order and visibility flag. This is complex and requires many kernel hacks. - Add to this that some edit actions are dependent of others, one cannot be approved without the other. Example: #1 Create article A, #2 delete article A. Here, #2 cannot be approved until #1 is approved. This adds complexity and development time. - Without a feature for reverting changes, the staging content could soon become so different from production that efficient change management is impossible. 2. Two installations, syndication Use the syndication extension to transfer content. Pros and cons: Similar to nr. 1. 3. Two installations, replication On approval, content is transferred to production using database replication. Pros: + This provides complete replication of every possible change on the staging server + Very quick + Short development time Cons: - Requires cluster setup (files in database) - Problems with cache files in database - Problems when you have content produced on production, like article comments. This can be solved though. - Impossible to approve only a subset of changes. It must be all or nothing. (This is a showstopper in my case.) best regards, -- Gunnstein Lye Systems engineer [EMAIL PROTECTED] | eZ Systems | http://ez.no -- Sdk-public mailing list [email protected] http://lists.ez.no/mailman/listinfo/sdk-public
