o Build a system to support content versioning.
o Allow for compare and restore revisions.
I suggest that you ad an undo button to the Backend of Joomla that can step back changes made
This has been implemented in Joomla 3.2.
IMHO there is no right and wrong default. Any default value could be wrong given a use case.
On size constrained or lower end hosting packages enabling content versioning at all would be a problem.
On other sites, what is the best default value to use for the number of versions to keep? 10? 100? It depends on your process. If you're creating a site and using versioning to make sure you don't screw up your carefully arranged layout by accident 5 might be low and 10 might be enough. If you're required by quality control or legal procedures to keep every single published version 100 is too low. In the end of the day, how long is a piece of string?
The current default isn't too bad considering the typical use case we see out there (small web site). The biggest problem, again IMHO, is that the option isn't advertised in the back-end itself. A simple "fix" would be the addition of a Post-Installation Message, a feature added in Joomla! 3.2 exactly for this reason. PIM also allows you to have an button which can automatically enable the feature with a sane default (let's say 10). If you're not happy with it the PIM has already told you where to go and change it. If you don't want to enable it you can simply dismiss the PIM.
I support Dave's comment. I requested the feature and have used it successfully. I typically set my sites for 10 versions because it saves even small changes which may be accidental.
I think this feature is great! However, I am wondering why it is "off" by default and needs to be manually enabled? Because it is off by default, many Joomla site admins will not take the time to enable it. I understand there may be a database size concern with storing a large of versions. Why not enable the content versioning feature by default, but have a low limit to the # of versions that are stored (3 or 5)?
Many thanks to the core team for having this integrated in STS releases.
Couldn't this feature/thread be marked as "DONE", or "CLOSED" ?
It already has been spammed too much...
This feature is actually already developed by Mark Dexter and will be included in Joomla! 3.2.
To be adopted as an enterprise CMS, it should be part of the core.
I tried it when it first came out. It certainly has potential. Support is good. It has some rough edges but could be just what we need.
Alexander Bachmann commented
Have you tried the GENOVA Version Control extension? It's pretty new.
Ramón Martins Sodoma da Fonseca commented
I would add a feature to this "versioning"
o Allow to create automatic replacement content based on language
o Allow to create automatic content replacement according to target audience (different "views" of the "same" content for managers (graphs), stakeholders (text + graphs), advisors (policies), reviewers (full text and data), people with disabilities(images, presentation, tabbed, navigated, narrated, video, for example). Something that can be partially done with ACL, but it's currently very cumbersome. There could be a content plugin within the content (as well as modules) so that the template renders different views of the content to different target audiences and languages.
FLEXIcontent CCK has this implemented and combined with publish permission and workflow
I agree that this would be a nice addition. :-D
David, I read the whole thread and I only saw one person saying it shouldn't be implemented, one who said it shouldn't but what he described that should be included IS content versioning, 16 people saying it should be included (but maybe not enabled by default, for performance reasons) and you. So, can you please explain to me what made you deduce that Joomla! professionals argue against it or that Joomla! is for amateurs only? I see quite the contrary going on here. Are we reading the same comments?
David Hedrick Skarjune commented
Hard to believe Joomla professionals argue against this--other systems scale just fine with version control. It's simply a requirement for ECM per the OASIS Content Management Interoperability Services (CMIS) standard. For practical reasons, it's needed for any editorial workflow. So, Joomla is for amateurs only?
Ryan Scott commented
SO many websites with 50 or so pages don't need this, fair enough. But Joomla is also used on sites with over 2000 pages, with multiple authors, so, it would be great to see it one day in the core. Drupal, Wordpress, typo etc all have it. (Keep it backend ;)
Versioning , such as workflow, must be part of the core of Joomla so that content, calendar, menu, module, Docman, etc, can use it, and that we have a single management interface.
I support this wholeheartedly & it needs to be for front & backend usage. After all, this is available for Wordpress by default & is also available for Drupal.
Local govt clients usually demand this (for audit purposes & cause they're scared of cocking things up!) & altho there are VC components, they currently tend not to work on the front end.
I believe that an ability to track changes in an article is vital. I suggest that content management tools should emphasize the ability to trace what happens from one point of stability (restore point) to another.
We need author as well as date/timestamp of changes combined with an ability to restore a particular version (restore point) as well as an ability to purge all versions from one restore point to another. Some form or automated retention management for older restore points would be a "nice to have" but not as vital.
Alan Sparkes commented
once you have versioning you can do real previews - something joomla sorely needs - hence we wrapped it up with this double whammy:) http://bit.ly/o0XOAS
Randy Carey commented
While most of my clients do not require content versioning, when it is needed, it is embarrassing to admit the CMS does not have it. A commercial-grade CMS really should have versioning. This is truly a feature that should be available to be turned on where it is needed.
I do not support this idea,it's not necessary for everyone.
Redundant database is sometimes a disturbing air.