Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By danaktivix on
Allo
Just about to implement a site that will need to make sure only one person edits a node at a time. There's the checkout module (which I could have a go at updating):
But nothing else I know of...
It doesn't seem to be a feature of 5.1 - just thought I'd see if anyone else knows whether it is there. (I can't check without running on two machines, since Drupal knows if I'm using two instances on one machine...)
Any thoughts?
Dan
Comments
Should be in the core
I can't believe Drupal is a collaborative editing system that allows one set of changes to wipe out another. Either provide locking or provide merging (basically RCS vs. CVS model). Locking is easiest and would suit non-programmers, me thinks.
This should be in the core.
Since forever
Um yes. You haven't seen it before now?
"This page cannot be saved because another user has modified it"
If you want to test different sessions - try using two different browsers, just to keep your cookies separate. There are more complex solutions too, but that's what I do when tweaking the admin and previewing what an anon user would see..
.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards
Too late
> "This page cannot be saved because another user has modified it"
I admit I have not seen that before. But you're telling me the system will allow the user to spend time making edits, and finally when they try to submit the changes the system will deny if someone else submitted changes? What is the user supposed to do at that point? Abandon their work? Or is there some kind of "merge" facility that I also don't know about?
If they are simply denied, I don't see this as a good solution. If a user is going to spend half a day making changes to a page then others should be prevented from editing.
We've been using drupal lightly as an internal information resource, but it isn't robust enough for true collaborative content management. It doesn't even have the basic lock/merge functionality addressed properly, but there are host of higher level issues that come along after that. I guess we are expected to find some set of modules that might sort of work and maybe provide some glue PHP code. . .
As an example: How can my HR department prepare a book that has multiple pages and sub-pages, and easily work on a new version? They need to keep all pages unpublished while they work on them (fine, they can manually choose the checkbox on each page), but after review (if I can manage to implement the workflow module properly) they need to release the new version of the book. I guess they have to go find all the pages they made edits to and publish them individually. Cumbersome.
They need to work with the "book" as a "unit". They should be able to see versions of the book, not individual pages. They should be able to roll back to previous versions of the book. They should be able to lock the whole book if they want, or individual pages. They should be able to set a date when an upcoming version of the book becomes published.
These are all the issues we solved in software engineering using version control systems (if they are implemented properly). I'm not sure why the drupal designers tossed all that knowledge out the window when designing a CMS.
big ask.
This is an interesting (and large) set of feature requests you are making.
Perhaps some day someone who wants this sort of behaviour enough will invest the required development time and resources into doing something similar. Put a bounty (or several) on it.
As it is, many websites and website contributors would probably find the extra required 'request lock' and 'release lock' buttons cumbersome, so this is not part of core. I imagine it could be added.
It the stateless HTTP protocol, there are severe problems with auto-locking.
Merging can often be done to code, but is much harder with freetext. If two people try to save page edits at the same time, somebody is going to have to lose. Suggested current fix there is to take a copy of your edited text, open the new changed page and paste by hand. There is no online 'diff/merge' screen that I know of. If you think you need it, bounty for it.
I think it's wrong to suggest that historical work on version control systems was deliberately removed from Drupal just to spite you. It's more that the many many issues involved in re-creating a usable such system were not seen as needed.
You may not be aware that historical methodologies used for 'version control' on flat files (the ones you claim to have solved) simply cannot be translated directly to database fields.
Drupal now has a 'revisions' table abstracting the data from the base storage. I already find this cumbersome but understandable. It fits the requirements of the developers who needed to add it.
If you wish to incorporate all the 'features' of source control into the maintainence of individual pages and of CVS-like lockable, versionable, branches of releases of 'books' and 'chapters' for individual editors... that's a big ask.
I would suggest you instruct your sub-editors to not spend half a day typing pages directly into a single web form field without ever pressing 'preview'. Instead, consider composing such large pages offline first.
.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards