Page 1 of 1

Synchronize instances of CMSMS on page level. Possible?

Posted: Wed Aug 05, 2009 8:41 pm
by nhaack
Hi there,

I do not need it at the moment, but I though, how would one go about setting up several instances and have them synchronize content. Sort of a staging concept :)

e.g. http//stage.example.com would display the current editorial status and http//www.example.com would display the actual live content. Ideally, each page would have a button to upload the changed content to the production instance of CMSMS.

The simplest method (I think), would be to have an external script that just copies the DB content to the next instance. It's truly not very granular. Some pages might still be in work progress. The script could check for the status of the pages and copy them accordingly or one could use an extra field to tell if this is live-content or if it is work in progress.

I'm just curious if someone of you had this situation and how they solved it. Something like this would be a good one to allow CMSMS step into the technology departments of e.g. larger online agencies as some customers demand staging possibilities ;)

Best
Nils

Re: Synchronize instances of CMSMS on page level. Possible?

Posted: Wed Aug 05, 2009 11:14 pm
by calguy1000
Something like this would be a good one to allow CMSMS step into the technology departments of e.g. larger online agencies as some customers demand staging possibilities
You're asking two questions about two different subjects...  As these subjects come up quite regularly, I'll try to share my opinion on them both and hopefully put these issues to bed.   (I'm being overly optimistic).

a) multi-site
    Every time somebody brings up a question about multi-site it has a slightly different flavor: i.e:
    * can I manage multiple domains from one install
         variation i) with different user accounts, permissions, page structure, templates, content, modules...
         variation ii) with the same user accounts, but different page structure, templates, content, modules...
         variation iii) with the same user accounts, templates, modules, but different content
         variation iv) with the same user accounts, content, and modules, but a different look and feel
         (add as many combinations as you want in this variation list... somebody has asked for it)
    * Even the people asking these questions often don't know exactly what they want, or when they'll need it, or how it'll eventually work if
       they do.
    * My personal conclusion is that there is no way to satisfy even 50% of this crowd
    *  It'd be a significant amount of work to build and test interfaces and modify the code to handle all of this to only satisfy a small fraction of
       the 'I want multisite' crowd.  
    * Please read the stuff I've written below on "Cost vs Benefit".because it applies equally.
    * The development team has discussed this issue at length, and decided that we will not support multi-site installs (one site that handles
       multiple domains) in any way, shape, or form.... primarily because of the issues described above.

b) versioning/content-control
   * This involves keeping a separate version of all of the content (and what about the page attributes, the title, the menu text, the
      metadata....)
for every time you hit the submit or apply button.  It also involves a significant modification to the permissions model,
      and a significant change to the user interface for scrolling back versions, marking certain versions as 'published', etc.
   * Next, to carry on, you'd want the same type of thing in the modules... for News articles etc.  so that a user could write an article, but keep
     track of his changes, and revert to an earlier version, and so that user B could mark it as 'published'.  Again, youre talking about
     significant amount of coding, and significant amount of interface change, testing etc.
   * Numerous more questions arise as to how it should work in some situations, i.e: deleting pages?  is there an undelete capability?  
     does that functionality have to be 'approved' to?  what about cooperative approval, so that a person couldn't 'approve' their own      
     changes.   Does versioning apply to templates and stylesheets too?   If so, then how do you maintain the relationship between the
     templates, stylesheets, and content so that the site has complete rollback mechanisms?  I can probably think of a bunch more.  
    Therefore, there are some significant technical difficulties to overcome, to say the least.

   Now lets talk about target audience.
   *  CMS Made Simple is designed to allow professional developers to relatively quickly build small-ish websites for small-er companies
      (like a small-ish  business, charity, club, or non profit organization) and allow the inexperienced user to be able to maintain the content
      on that website.
   *  CMSMS was never designed to be the be-all and end-all, or the kitchen sink of content management systems.  It was designed to fill a
      certain need for a tool in which you could build a small website and hand it off to the average receptionist, customer, or spouse
      to maintain content.  We firmly believe in using the right tool for the right job.   That's why there's no E-commerce functionality, full-blog
      capability, or  fancy portal capabilities built in the CMSMS package you download.  They are all third party add-on modules.
   * The number of organizations that really NEED things like versioning, and content control is allot smaller than the target audience I
      mentioned above.
   * The vast majority of organizations that THINK they need real versioning and content control, often only merely need a good backup
      and restore methodology, so that when an error is made, they can revert to a previous version quickly and with relatively little pain.  
      This backup and restore service is often a good 'value added service' for our target user, the professional website developer.

  Other Products
   * There are already numerous products out there (though I've never checked them out) that handle versioning, and content management,
      and high security models, and have numerous other features to cater to these markets.  I've heard that they are usually heavy on
      requirements, not easy to use, (and although they are sometimes
      quite expensive)
do we really need to re-invent that wheel?
   
   Cost(Effort) vs Benefit
   * Taking the (not insignificant) time to add in versioning, and content control, rework the permissions model, modify the interface,
      debug and test these features means that we're putting significant effort into catering to a market that is smaller, but more demanding
      than the one we're already in.  It also means that we're not doing the things we could be doing to make the product even better for our
      original target audience.
   * Adding the code for versioning, and content approval would add even more weight to the code, and more complexity for the average
      end user, thereby taking us even further away from our original target audience.

So, to conclude:
* Multisite:   There is no consensus on the real requirements... and no clear percentage of the user base that really needs it, or even knows
 what they want.  Therefore, the cost/benefit analysis to me shows that it is not worth doing.
* Versioning/Content-control would be a 'cool' feature that would allow a smaller portion of our user base to cater to some larger customers,
  etc, but if we implemented it, we would make the product larger, and more complex, and therefor risk outgrowing a large percentage of
  the user base that this product was designed to cater to.
* I would rather (and by no means am I agreeing to do it at this time) implement a convenient backup/restore mechanism to provide peace
 of mind to the customers.... this would satisfy the majority of clients that think they need versioning and approval control, AND at the same
 time provide functionality that our target audience could certainly use.
* I also think that a backup/restore methodolgy should be an add-on module, but that's a different discussion.
* This discussion didn't even mention multi-language support, which I do think is worth doing in the core.  
* So would CMSMS still be simple if we added the functionality for multi-site,  version-control/content-controll, AND multi-language?  
  Would it still allow you to create a website for the lawyer, or restaurant at the end of your block in under 6 hours?  Would it be worth the
  install, or would you go to something 'lighter', and easier for them to use?

Let the wars begin :)  

Re: Synchronize instances of CMSMS on page level. Possible?

Posted: Thu Aug 06, 2009 1:13 am
by Nullig
Excellent summary of the issues involved, calguy, and I agree completely. CMSMS is what it is precisely because it is a simple tool for web development and content management. When you start adding these levels of complexity, it ceases to be useful for the majority of the target audience.

I know I certainly do not want to have to retrain the 100+ site owners/maintainers I deal with to manage "work flows", "content approvals" and "versioning". No Way.

Keep it simple.

Nullig

Re: Synchronize instances of CMSMS on page level. Possible?

Posted: Thu Aug 06, 2009 2:45 am
by jmcgin51
very nice summary, Calguy.  While I think features like versioning, workflow, etc, would be great enhancements to an already excellent product, you do lay out some compelling reasons to approach them with caution.

Re: Synchronize instances of CMSMS on page level. Possible?

Posted: Thu Aug 06, 2009 7:33 am
by nhaack
Hey Calguy,

thanks a lot for taking the time to sum up the issue so well. I think my question has been answered once and for all ;). I work in a larger agency as a consultant on enterprise CMS and I often try to convice our technology from using CMSMS for smaller projects, but they want staging - or the clients want it :p.

I fully understand the implications of such modifications and the necessary time to invest. It is a complicated issue, this is why enterprise CMS sometimes cost 6 or 7 digit numbers, because such issues are complicated.

I now understand that this would be beyond the original intention of CMSMS. It's better to "keep" the target audience and serve them right instead of investing vast amounts of time to cater the few situations where this would be needed (and thus not investing this time in the core features that more people need). Absolutely makes sense. There just can't be one system for "all users".

Thanks & Best
Nils

Re: Synchronize instances of CMSMS on page level. Possible?

Posted: Fri Aug 07, 2009 4:50 am
by Jeff
Just because we don't want it in the core because it won't keep thing simple, does that mean that people like the OP shouldn't/couldn't sponsor a module to do content staging for people that would like to add it to the system?

Re: Synchronize instances of CMSMS on page level. Possible?

Posted: Fri Aug 07, 2009 1:11 pm
by calguy1000
This has already been discussed at length.  It can't be done 'properly' as a module.

Re: Synchronize instances of CMSMS on page level. Possible?

Posted: Mon Aug 10, 2009 10:12 am
by Pierre M.
Thank you Calguy for these clear explainations.
And the (clumsy?)wording "average spouse" made me laugh ;-)
Nullig wrote: Excellent summary of the issues involved, calguy, and I agree completely.
These could be my words.
jmcgin51 wrote: very nice summary, Calguy.  While I think features like versioning, workflow, etc, would be great enhancements to an already excellent product, you do lay out some compelling reasons to approach them with caution.
These could be my words.
nhaack wrote: thanks a lot for taking the time to sum up the issue so well.
These could be my words.

I very much agree on no multisite and multilang from the beginning. I've quite often discussed/advocated about content versionning but now I understand better it is not so simple and I fully agree on "backup methodology".

Some prose on using "backup methodology" for versionning :
-I think more and more good hosting providers offer this files+db backups and restore accessible to the target audience. 7 daily, 4 weekly and 1 or 2 monthly automated rotating snapshots. It is enough to restore to a sane state after a problem.
-On "almost static" websites made with CMSms I almost always use CMSms as an hidden/embeded content *management* system and I deliver a script with wget integration to *pull* static content and make a time stamped version zip which can be deployed the old way to the webserver (say Apache, FTP, by script too) for web *broadcasting*.

Have fun all with CMSms

Pierre M.