Some Thoughts About How AI Could Reshape CMS Platforms

Last Friday, Dries posted an insightful post, How AI could reshape CMS platforms. It was quite good. If you haven't read it, stop now, go read it, and come back.

Okay, so you are caught up.

Neither of us have a comment feature on our blogs. This is a bit long for a comment as well, but it is definitely an attempt to apply real world examples of Drupal in production to the concepts he presented.

Dries spends way more time thinking about content management systems than most. He has a high-altitude view of the content management market and the open source world that is well-considered. His views on responsible AI should be picked up by more tech leaders in this time when everyone seems to think that AI is soon going to be doing everything for us. (In short, humans should always review what AI produces.)

His post covers a lot, but I want to take a deeper dive into the two strategic priorities he outlines.

1. Improved version control – AI and human editors will increasingly work in parallel, requiring more sophisticated versioning for both content and configuration. Traditional CMS platforms must evolve to support Git-like branching, precise rollback controls, and configuration tracking, ensuring both content stability and site integrity.
2. AI oversight infrastructure – As AI generates and modifies content at scale, CMS platforms will need structured oversight systems. This includes specialized review queues, audit logs, and governance frameworks.

Improved version control

I've implemented version control strategies for code and content with a variety of clients. If your enterprise content management system isn't using both, it is extremely difficult to coordinate changes between multiple developers or editors.

Feature branch git workflow

Let's start with code. Every development team that has more than one developer needs a way to collaborate. A simplified version of that approach might look something like this:

1. You have a main branch that is continuously deployed to your production environment—often through a process that tests the deployment in a staging or test environment first depending on your hosting setup.
2. Each developer can open feature branches that represent an atomic change to the code that can be merged to the main branch after successful tests.

In this model up to n developers can collaborate on a common code base and not break anyone else's work because they constantly fetch the work of the main branch and either rebase or merge in those changes. (I prefer rebase for a clean history, but there are advantages to merging as well.) 

The only time things get a bit complicated is when two branches affect the same lines of code. When git can't figure out what needs to be merged, a developer has to use a two-way merge technique to choose between current (their branch) and incoming (main branch) and resolve the merge conflicts. Do I want to keep mine, theirs, or both?

In a well-structured Drupal project or site, you typically commit your composer.json, some scaffolding files, and your configuration. This makes it easier to ensure that all the settings and site structures such as content types, media types, vocabularies, block layouts, and views are all consistent and what you expect.

So how might it look for us to do this sort of version control with content?

Workflows and revisions for content (or any other entity)

A few months back, I wrote about Access Control Strategies for Enterprise Websites. (I also presented a session at DrupalCon Portland on this very topic. Watch the video.)

I've set up quite a few workflows that validate and ensure an editor's actions are what we would expect. A typical workflow is to allow content to start as a draft then get published then get archived or unpublished. (Who knew "unpublished" is not a real word? I still use it all the time because it "just makes sense" for editors.)

In more complicated workflows, you can add in moderation states like "in review" or "marked for deletion"—the later being extremely handy in situations where you want editors to be able to unpublish with the intent to delete without trusting them to do the actual deletion because of records retention needs.

Drupal's revision control capabilities are critical to many robust editorial workflows. Without the ability to have default revisions that can be published or unpublished as well as non-default revisions that are always unpublished, you can't really build editorial workflows. 

The ability to revert (or restore) a revision is another powerful feature of the revision system.

Let's say you have an editor named Polly. Polly is working on some draft changes to a page that was previously published. There could be n revisions saved over a span of time. However, Polly notices that there is a typo in the published revision. (Oh no!) They want to fix that, so they revert to the previously published revision, make some edits, and publish those edits. They can then revert their unpublished draft to the front of the line of revisions and continue working on the larger changes that were not quite ready to go live.

While I can assure you that this workflow is hard for many editors to grasp the first time they see it, they really appreciate the ability to work with revisions in a way that is so flexible.

I think the most interesting aspect of a git-like workflow for content would be the idea of branching content and merging those changes into the final version.

What if instead of needing to revert a revision to achieve the above, Polly could just branch the content and pull the changes from the typo edits into their branch.

This workflow could allow for complex changes to be tracked while still allowing for quick emergency changes.

It opens some possibilities for translation workflows as well. Every commit to the published branch could be pulled into a revision that triggered a new translation request. Another way to do the workflow states would be to change a moderation state from "draft" to "ready for translation" so that translation costs are only incurred after drafts are reviewed and get to that ready state. Such a workflow would save on translation costs (human, API, or AI) while ensuring content gets additional translations when needed.

To achieve this sort of git-like workflow, we'd need some changes to the revision system and likely we'd need to move to a concept like Workspaces rather than Workflows.

Workspaces were marked as stable in Drupal 10.3. The basic difference between Workspaces and Workflows are that Workflows relies on on moderation states where revisions move through those states while Workspaces allow the creation of revisions that eventually get saved as the published revision replacing the last published revision.

That probably sounds a bit complex. It is. It's also a possible step towards that git-like workflow. 

What's missing at the moment is the ability to pull from the published revision and compare the changes to accept those changes in a draft workspace. You can pull changes right now, but it doesn't do the comparison to my knowledge. (Someone correct me on Drupal Slack if I'm missing something in my tests.)

Merging complex layouts

One area that I think has a lot of work to figure out is the comparison of revisions. Diff is a contrib module that allows you to compare any two revisions. You can compare those revisions as a visual inline comparison of the rendered content, or as split fields that show you the stored HTML side-by-side, or as unified fields which lets you see the changes stacked on top of each other by line.

It's unlikely that editors are going to feel comfortable reviewing side-by-side HTML. It's just not friendly to someone that is not a developer. However, it's that level of complex rendering of difference that is needed to truly know what is changing. What if the editor chose a heading style that looks the correct size but was in the incorrect order semantically—an accessibility issue that could not be visually represented without code? It's an interesting challenge.

Visual inline comparisons, despite their drawbacks, are likely to be preferred by most content creators. It just feels "right". Maybe that's because it looks like the editing tools they are used to seeing such as when they suggest edits in a Google Doc.

The challenge with visual inline comparisons is that you have to compare the final rendered content. Even for a single content field with CKEditor 5 as the rich text editor, this rendering can be complex. If you have embedded media or embedded entities or just complex filters that transform HTML, those processes can take time to render and are not yet cached because they were just created.

It gets even more complex to rendering visual inline differences with Layout Builder or Paragraphs in the mix because in addition to rendering the fields you are also rendering all of the layout structures for the site. I've seen this take nearly a minute on a very complex layout with paragraphs. (Albeit, that example was several years ago and rendering has improved in some areas of Drupal due to performance increases in both code and PHP 8.3.)

Experience Builder may help us turn a lot of that complex layout logic into a single renderable blob. That may help with rendering performance for previewing changes. I'm excited to see where that will go.

Whew! That was a lot to think through and we haven't even hit the second strategic priority.

AI oversight infrastructure

Most of the revisioning workflow will be an improvement whether AI is in the mix or not. Dries makes a great point that we can't trust AI with making all these complicated decisions. Heck, I would argue that we can't trust most of the humans that have to suss out this level of complexity.

So what does it mean to build oversight into our complex content management systems? 

Have you ever filled out a RACI chart before when kicking off a project? RACI stands for Responsible, Accountable, Consulted, and Informed. You can translate this into editorial workflows where editors (responsible for creating content) are separate from publishers (accountable for publishing content) and reviewers (consulted to review content) are all defined. (Please for the love of all things good and pure, keep me off the informed emails!)

When working with the City of Portland, I had the opportunity to build a system to manage council documents and agendas. It was a pretty cool project that I'm incredibly proud of because it streamlined council meetings and reduced a huge amount of paper waster. (Before the application, they were passing around binders full of paper and signing "backing sheets" that showed each responsible party had reviewed the materials.)

In this system, built with Drupal of course, the workflow was much more complex than the typical editorial workflow. Drafts were created by staff either in a bureau or an elected official's office then they were passed back and forth for revision before being submitted to budget review, legal review, final elected review, council clerk review, and finally approved for an agenda. All of this was done before the final step of publishing everything to public agenda.

That's 10 moderation states and 17 possible transitions (in part due to different permission needs for some transitions). All that to say... Drupal can handle administrative workflow with nothing more than some workflows and some views.

I don't think there is much that has to be hard-coded into Drupal to support double checking AI-generated content. I hate using "just" or "simple", but really it's just adding permissions to your AI user to prevent them from publishing. Simple, right?

Other thoughts of note

I was intrigued by the idea of having an AI reviewer agent review content that an AI creator agent or editor created. I could really see the value of this sort of workflow in things like automated translation or regulatory review.

I am frightened and dismayed that organizations might choose to let AI run the site because it does a "better" job than the humans that were previously creating copy. Just because it performs better does not mean that slop (the spot-on name for AI spam) is a good thing.

A friend demonstrated to me a proof of concept that can take podcasts—usually created by real people passionate about their topic and craft—and let AI create summary podcasts of that content. As a programming idea, it's fun. As a way of creating content that might overtake the original creators, it is insidious at best.

I'm appreciative that Dries' push for responsible AI doesn't allow for regurgitative content. I'm fine with AI making content better. I'm not ready for a world where AI is talking to itself while burning through precious natural resources.

Do you have a project or team that needs some expert help? Do you just want to chat about Drupal CMS and what it might mean to your organization? Connect with me on LinkedIn or reach out to me on Drupal Slack (@joshuami).