Migrating to Content Moderation with Lightning
Adam Balsam
Mon, 12/04/2020 – 11:38
NOTE: This blog post is about a future release of Lightning. Lightning 2.2.4, with the migration path to Content Moderation, will be released Wednesday, December 6th.
The second of two major migrations this quarter is complete! Lightning 2.2.4 will migrate you off of Workbench Moderation and onto Core Workflows and Content Moderation. (See our blog post about Core Media, our first major migration.)
The migration was a three-headed beast:
The actual migration which included migrating states and transitions into Workflows and migrating the states of individual entities into Content Moderation.
Making sure other Lightning Workflow features continued to work with Content Moderation, including the ability to scheduled state transitions for content.
Feature parity between Workbench Moderation and Content Moderation.
Tryclyde – the three-headed CM migration beastThe actual migration
Content Moderation was not a direct port of Workbench Moderation. It introduced the concept of Workflows which abstracts states and transitions from Content Moderation. As a result, the states and transitions that users had defined in WBM might not easily map to Workflows – especially if different content types have different states available.
To work around this, the migrator generates a hash of all available states per content type; then groups content types with identical hashes into Workflows. As an example, a site with the following content types and states would result in three Workflows as indicated by color:
WMB states/transition mapping to WorkflowsThe second half of the migration was making sure all existing content retained the correct state. Early prototypes used the batch API to process states, but this quickly because unscalable. In the end, we used the Migrate module to:
Store the states of all entities and then remove them from the entities themselves.
Uninstall Workbench Moderation and install Workflows + Content Moderation.
Map the stored states back to their original entities as Content Moderation fields.
Note: This section of Lightning migration was made available as the contrib module WBM2CM. The rest of the migration is Lightning-specific.
Other Lightning Workflow features
Lightning Workflow does more than just provide states. Among other things, it also allows users to schedule state transitions. We have used the Scheduled Updates module for this since its introduction. Unfortunately, Scheduled Updates won’t work with the computed field that is provided by Content Moderation. As a result, we ended up building a scheduler into Lightning Workflow itself.
Scheduled Updates is still appropriate and recommended for more complex scheduling – like for body fields or taxonomy term names. But for the basic content state transitions (i.e., publish this on datetime) you can use native Lightning Workflow.
As an added bonus, we sidestep a nasty translation bug (feature request?) that has been giving us problems with Scheduled Updates.
Feature parity
While Workflows is marked as stable in Core, Content Moderation is still in beta. This is partially because it’s still missing some key features and integrations that Lightning uses. Specifically, Lightning has brought in patches and additional code so that we can have basic integration between Content Moderation ↔ Views and Content Moderation ↔ Quick Edit.
Want to try it out?
Assuming a standard Composer setup, you can update to the latest Lightning with the following. The migration is included in Lightning 2.2.4 and above:
$ composer update acquia/lightning –with-dependencies
Once you have updated your code, you can have Lightning automatically apply all pending updates, including the Content Moderation migration with the following (recommended):
$ /path/to/console/drupal update:lightning –no-interaction
Or you can just enable the WBM2CM module manually and trigger the migration with:
$ drush wbm2cm-migrate
Source: New feed
