Part 1 | Part 2 | Part 3 | Part 4

Table of Contents

One of the seemingly intractable difficulties in content management systems is the notion of supporting collaborative editing in a peer-to-peer fashion. Indeed, from an infrastructural standpoint, enabling shared editing in a context where server-side CMSs rule the day can be particularly challenging. All of this may soon change, however, with the combination of Yjs, an open-source real-time collaboration framework, and Gutenberg, the new editor for WordPress. With the potential future outlined by Yjs and collaborative editing in WordPress, we can open the door to other thrilling potentialities such as shared layout building or even collaborative drawing in the CMS context.

On an episode of the Tag1 Team Talks show, your correspondent (Preston So, Editor in Chief at Tag1 and author of Decoupled Drupal in Practice) chatted with Kevin Jahns (creator of Yjs and Real-Time Collaboration Systems Lead at Tag1) and Michael Meyers (Managing Director at Tag1) about how WordPress is enabling shared editing in Gutenberg. In this multi-part blog series, we summarize some of the concepts we discussed. In this third installment of the series, we examine how shared editing could become a reality in Drupal and the unique challenges of implementing shared editing in the CMS context.

Shared editing in Drupal?

If you haven’t already, I recommend checking out the first and second installments of this blog series on shared editing with Gutenberg, because those blog posts outline some of the motivations for collaborative content creation in CMSs and some of the difficulties the intiative faced in supporting shared editing. In addition, over the course of those blog posts we inspected how key features like peer-to-peer collaboration and offline editing need to be part and parcel of any out-of-the-box implementation of collaborative editing in content management systems.

How collaborative editing could become a reality in Drupal

Drupal may have a similar background to WordPress’s, but its shared editing story is comparatively immature. Nevertheless, there are contributed working implementations of shared editing in Drupal, including ProseMirror, a shared editing tool that we covered in a previous Tag1 Team Talks episode. Tag1 Consulting recently evaluated ProseMirror along with a host of other solutions that would enable such use cases in Drupal, including a complete integration with Drupal’s roles and permissions system.

Tag1 recently produced an implementation of shared editing in Drupal for a top Fortune 50 client that leverages a client–server model without peer-to-peer capabilities. In addition, this Tag1 client needed to edit code collaboratively in addition to content, a use case enabled by CodeMirror, complete with code hints that provide next steps for editors. Michael cites this as yet another fascinating example of how Yjs can enable effective collaborative editing in a variety of settings. Fortunately, even Drupal sites are now implementing shared editing across the ecosystem, lending even more weight to the notion of collaborative content creation eventually becoming table stakes in content management.

Yjs across ecosystems

Many existing editors such as ProseMirror now integrate gracefully with Yjs. Fortunately, the y-webrtc plugin in the Yjs ecosystem is a relatively lightweight and straightforward add-on that could be part of the Drupal and WordPress ecosystems in the form of plugins as well. Once communication can be successfully established between peers with these plugins, we can enable collaboration on any shared editor that Yjs supports, including ProseMirror, Quill, and others. This idea will doubtlessly be interesting to people who use different content editors, because this feature can be easily enabled in the CMS.

Challenges of building collaborative editing

As Kevin attests from experience, implementing shared editing is particularly challenging. Someone who builds collaboration with JavaScript may require a different server algorithm in JavaScript to handle communication between client and server. Consider, for instance, the case of implementing text collaboration that leverages operational transformation (OT), a topic covered in a previous Tag1 Team Talks episode. OT is a particularly challenging algorithm to implement, and this same algorithm needs to be made available in the client-side context on rich text editors as well, which is a difficult proposition. In other words, it becomes double the work to support OT in any universal manner.

Most of the time, especially given the advent in recent years of universal JavaScript (also known as isomorphic JavaScript), architects would replicate the same client-side implementation of OT on a server environment. This sharing of code makes testing easier, because you can reuse the same libraries. You can ensure that the encoding of operations is precisely the same as what you would use in the server context. There are a host of issues with any universal approach, and WebSockets have not historically been well-supported in well-worn content management systems like Drupal and WordPress.

Other alternatives for shared editing

One of the important considerations in Gutenberg’s implementation of collaborative editing was determining whether there are any other compelling alternative solutions available. Kevin states during our Tag1 Team Talks episode that CKEditor 5 is an exceptionally well-built tool for editing and seamlessly communicates with CKEditor’s back-end solution, CKSource, to make any content become collaborative. CKEditor, in fact, leveraged the ideas behind collaborative editing much earlier, albeit with a centralized server approach. Unfortunately, however, one of the most significant issues inherent to CKEditor is that you can only use their proprietary CKSource server environment in order to enable shared editing. Nevertheless, CKSource washes away many of the concerns around shared editing such as scalability.

Worse still, CKEditor and CKSource are not viable solutions for content management systems like Drupal and WordPress, because every Drupal or WordPress implementation would need to set up CKSource and pay for a subscription. Kevin also highlights the issue of data ownership and asks whether collaborators can truly own their content if it is always sent to a separate central server. If the server goes offline and the content is lost, there is no way to restore the content, particularly from a local version.

As an example, many companies employ intranets to host content. Consider, for example, a company that routinely works with important government documents and secret information, all of which is kept secure through various means. Now, if you want this content to be collaboratively edited, but the content is comprised of highly privileged information, you need to host it either on a third-party server or pay a platform to host it on-premise. This makes maintainability, security, and software upgrades a potentially intractable challenge to solve.

Michael also cites the fact that CKSource was implemented first and foremost for CKEditor, and without CKEditor as a text editor available by default in a content management system, like it is in Drupal, there is no way to couple shared editing with CKSource for these open-source projects. Because Yjs is not only network-agnostic but also editor-agnostic, the same technology can enable the transformation of any aspect of your application into something collaborative. Whereas Yjs supports collaborative use cases beyond text such as layout building and drafting, CKSource makes this much more difficult.

Nonetheless, Kevin states during our show that CKSource and CKEditor, together, have led the market and offer the most robust end-to-end solution for collaborative text editing specific to those systems leveraging CKEditor. This exemplifies one of the key advantages of Yjs; not only can Yjs enable collaboration beyond text with use cases like drawing or even three-dimensional modeling, its agnosticism also means that integrations with a rich variety of editors is not only possible but easy to implement.

Conclusion

The concept of collaborative editing is nothing new to content editors around the world, but it is certainly a new idea for content management systems like Drupal and WordPress, which have never had such a feature available in the form of shared editing. Nonetheless, the motivations are clear, particularly in this modern age when offline editing and decentralized applications are in vogue. Thanks to the open-source real-time collaboration framework Yjs, however, Drupal and WordPress may soon have new approaches available to support shared editing out of the box. With the help of Yjs’ creator Kevin Jahns, Tag1 has enabled collaborative editing to become a reality in Gutenberg, one of the most important projects ever to emerge on the WordPress landscape.

In this third installment of this multi-part blog series on shared editing in Gutenberg, we examined some of the challenges that face a similar approach in Drupal. Nonetheless, Drupal and WordPress, along with Yjs, both benefit from rich ecosystems that could enable the sort of exciting innovation that comes with the prospect of shared editing. In the next and final installment of this series, we discuss the future of collaborative editing in Gutenberg, the reaction of the Gutenberg team, and how you yourself can get involved.

Special thanks to Kevin Jahns and Michael Meyers for their feedback during the writing process.

For more Yjs content, see Yjs - Add real-time collaboration to any application.

Photo by CoWomen on Unsplash