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
