Drupal CMS offers a rich user interface and powerful content editing experience. There are a lot of contributed modules that enhance the system and its editing experience. One of the projects I was working with called for concurrent editing implementation. Concurrent editing simply means allowing multiple editors to edit the same content at the same time, without the possibility of conflicts arising due to concurrent actions.
In today’s editorial landscape, content creators can not only access a document countless times to revise and update content but also work with distributed teams. For this reason, concurrent editing has become among the most essential and commonly requested features for any content management solution.
The project (Layout Engine) involved configuring pages and blocks of a mobile application through Drupal.
A single page of a mobile application consists of multiple sections, these sections could contain data as per user’s locations or any other criteria. A page in Drupal was primarily a content type. We used paragraphs to configure blocks which we call widgets. So basically, a banner on the homepage of a mobile application is a widget.
These pages and widgets were configured by our client’s marketing team. Any page on the mobile app could consist of 'N' number of widgets. Due to a large number of widgets present, it was difficult for a single user to be familiar with all of them. Multiple members of the marketing team worked on the app simultaneously, making it difficult to edit the layouts/widgets.
Thus the client needed a system where multiple users could simultaneously edit the layouts and their widgets independently.
Collaborative editing has long existed as a concept outside the content management system (CMS). It is a limitation of Drupal at the moment, and we don’t see any solution for it in Drupal core soon. A big thanks to the members of the community who contribute their code in the form of modules making solutions available to the world in a quick google search.
We explored a couple of modules which fulfilled our requirements to some extent.
| Paragraph Frontend UI
This module provides quick editing of widgets on the view page itself.
A user won’t have to go to the edit page and then search for the widget to update and then save the whole node. He can do it quickly on the view screen. We believed this would allow multiple users to quickly edit the widgets and will solve the issues. But, it turned out that the module throws a deadlock error when multiple users are updating different paragraphs of the same node. Therefore, we discarded the possibility of using the Paragraph Frontend UI module.
The next module we explored was the Paragraph Edit module. It provides a separate page to edit the paragraphs through the contextual links. It does not break when multiple users attempt to edit different paragraphs simultaneously. But the issue with this approach was that it supported separate editing only. So if a user had to create a new paragraph/widget, he/she had to go to the edit node form. The tricky part here is, if an editor is on the node edit form while some other editor made changes through the quick link, the current form will contain the old data. In this case, when a user saves the node, it will revert those changes to the previous version. We did not want that either.
| Conflict
It does not have any additional configuration attached to it. I am adding two screenshots below to show how it works. This is what the second user will see when the first user has already saved the node and content is in the database. To know more visit - https://www.drupal.org/project/conflict
Once the user clicks on the 'resolve conflicts' button, it shows two versions of each field, something like in the following screenshot. Users have to manually update the field accordingly and need to save the content again.
This module is a good solution under the following instances:
If the node form has a simple structure and the user can afford to update the content manually. In a complex architecture where we use paragraphs to provide flexibility to the editors, this will create a lot of confusion.
It only works for two users as you can see in the screenshot above, it shows what is the difference in the server. If a third user is editing the content at the same time, it will override the changes of the second user.
| Content Lock (anti-concurrent editing)
As the name suggests this module locks the content for the first editor who started to edit the content. Any other editor will see the message and all the fields will be disabled for him/her.
Features of Content Lock (anti-concurrent editing):
The lock will break when the user saves the content. The other user will see the message and will know who is editing the content at the moment.
If a user doesn’t save the content, it has a submodule called content_lock_timeout where we can set a time for the content to hold the lock. It breaks the lock on cron run as well as when the second user comes to the edit node.
It has an option to manually break the lock as well, so a user with the permission to break the lock can also free the content from the editor.
The content lock was used until we had a proper solution for concurrent editing.
After countless discussions with the marketing team, we decided to provide a solution to overcome the concurrent editing problem. We decoupled all the widget creation as a separate node and referred those nodes into the Layouts. This way, everybody had control on their own widgets and they did not need to wait for the content lock to end.
If you happen to have a better solution for concurrent editing, we would love to hear about it!