prevent multiple simultaneous page editors

[eluser]MaxPar[/eluser]
I'm sure that this question has been answered multiple times, but I was unable to find it in the forums.

I developed a custom CMS system, and I need to manage what happens when multiple people try to edit the page at once. I wouldn't want one person to make a bunch of edits and submit them, and then have another person unintentionally overwrite all their hard work.

I think the easiest thing to do is probably just to allow only one person to edit a page at a time, but I'm not exactly sure how to go about doing this- and I know it's been done before, so I thought it would be wise to ask.

My current best guess is that I should keep track of all the pages that are being edited (in a database, with three columns: page name, time started editing and user cookie info). Every time someone wants to edit a page, I check to make sure it isn't already open in the database.

Any thoughts? Is there already a library that would help with this?

[eluser]jedd[/eluser]
[quote author="MaxPar" date="1236607109"]
My current best guess is that I should keep track of all the pages that are being edited (in a database, with three columns: page name, time started editing and user cookie info). Every time someone wants to edit a page, I check to make sure it isn't already open in the database.[/quote]

There are obvious problems with this one - the call to check if the page is locked and if not to edit it needs to be atomic. Doable, but something that requires some care.

The big problem is working out when someone's buggered off mid-edit, leaving your page locked - and some automatic, periodic mechanism to reset that flag so the page can be edited again.

If you look at how most CMS's do it, they force the problem back onto the user - whenever a user saves changes to the page, the state of the page is checked to see if it was modified since that user started the edit. If it was, then the delta view of the pages is shown, and the user has to clean it up. This is not necessarily the best approach, but presumably the easiest (because most CMS's adopt it).

[eluser]janogarcia[/eluser]
I'd implement a locks table as you suggest for managing file locking/unlocking (locks, page_locks, edit_locks, whatever name you prefer...). Keeping track of basic lock information: content_id, timestamp, user_id.

For example, DokuWiki locks the piece of content being edited so other users won't be able to edit the same content at the same time.

There's one interesting DokuWiki feature that you should take into consideration: To avoid accidental permanent locks, DokuWiki will lock the page for 15 minutes, after that a JavaScript popup will warn you that the page will be unlocked unless you press the Preview button (wich resets the lock timestamp). You could implement this functionality in a more elegant way: perhaps a modal window with a "Keep editing the page" button.

Some CMS use more advanced and less restrictive collaborative editing worklflows, as MediaWiki does with its handling of editing conflicts wich permits simultaneous/parallel editing:

Handle edit conflicts (page being saved by a user while still being edited by another one, then saved again). MediaWiki will merge changes automatically if possible and otherwise require the user to do a manual merge.

http://www.mediawiki.org/wiki/Manual:Med...ature_list

I'm not aware of any CI library that handles this task. I'm sure you will be better off with one custom tailored to your project. It shouldn't bee too difficult. It is just one new feature/pattern to learn.

Good luck.

[eluser]xwero[/eluser]
Nowadays the revision approach seems to be popular too. Just store every change of the page and the last revision will always be the one that is shown on the site. Google documents shows if another user wants to change the page the user is working on.

As Jedd writes locking the page isn't the problem but unlocking the page as soon as the user isn't on the changing page anymore is. There is no easy way to do this.

You can unlock if the user clicks on save and is redirected to the overview page. If the user stays on the update page after sending the form, the page needs to be locked until the user goes to another page. This you can do by tracking the user.
The biggest problem is when the user closes/crashes the browser/OS when on the update page. For this you need to check if the user is still online.

[eluser]janogarcia[/eluser]

The big problem is working out when someone’s buggered off mid-edit, leaving your page locked - and some automatic, periodic mechanism to reset that flag so the page can be edited again.

With the "DokuWiki approach" you wouldn't need a cron script to check your locks table. You would simply need to check two conditions to know if some piece of content is locked: "Is the content_id in the locks tables?" AND "Was its timestamp generated less than 15 minutes ago?"

What you should decide is whether this basic collaborative editing management meets your project requirements.

[eluser]jedd[/eluser]
Yup, I'm liking that approach of doing a pop-up for a user that's had the page > x minutes.

I wonder how you'd degrade that elegantly sans JS though.

Probably fall back to the 'here's the page diffs, you're the human, so you work it out' approach