“... so that you can easily use Content Moderation on one (or some) of your migrated content types”. This would have been the longer version of this post's headline (if it hadn't been for the SEO restrictions regarding headlines' length). And it's precisely then, once you try to turn on content moderation on some of your your site's content types, that you realize that... ups... Drupal 8 exports content with a wrong langcode legacy! You have problems, I have solutions! Here's the “embarrassingly” simple way to fix translations migrated to Drupal 8 so that you can go ahead and enjoy Content Moderation's functionality:
"The website encountered an unexpected error. Please try again later."
And instantly all that relief and surprise you might have experienced realizing how smooth the whole migration process from Drupal 7 to Drupal 8 is goes down the drain!
It would have been just to good to be true, to just use the migration “trio” (Migrate Drupal, Migrate and Migrate Drupal UI) and simply transfer your whole site from Drupal 7 to Drupal 8. All this with no discouraging events along the way meant to spoil your good mood, right? Now it's this particular error message that blows your self-confidence as a Drupal programmer!
What could have possibly happened? Why is it that it's just when you enable your Content Moderation module on some of your content types and try to save them that you're being “punished” with this error?
Now let me do my best and point out to you both the “culprit”, the one triggering this annoying message, and the quick (yet effective) fix that you can implement:
First of all: What's Causing This Error Message?
Now let's try and retrace our error's steps, shall we?
We'll start our “investigation” in the Recent log messages, where the /admin/reports/dblog will reveal to you the “culprit” itself: “Invalid translation language specified”.
It looks like your migrated content is set with a certain legacy langcode (different from your Drupal 8 site's default language).
Don't just take my word for granted! Instead, go ahead and put the spotlight right onto the “culprit” in your own code, so you can see it for yourself: rely on Devel module's dpm()function for that!
So, if you head over to devel/php ( Drupal\node\Entity\Node) and scan over your language settings you should be able to spot precisely the “cluster” of code lines “sheltering” your error's cause:
$node = Node::load(<My NID>);
dpm($node->language()->getId());
It's here that you will spot that problem-causing langcode! It's nothing but an unwanted “legacy” passed over to your Drupal 8 site from the Drupal 7 version that you migrated it from.
And it's precisely this langcode legacy that prevents you from saving nodes with the Content Moderation module turned on.
And Here's How You Fix Translations Migrated to Drupal 8
You simply change the language to the default one on your Drupal 8 website!
How do you do that? By writing down this code here in your Drupal\node\Entity\Node:
$node = Node::load(<My NID>);
$langcode = \Drupal::languageManager()->getDefaultLanguage()->getId();
$node->set('langcode', $langcode);
$node->save();
dpm($node->language()->getId());
A minute of your time, not more, a few short lines of code and you're back on the right track!
Now you can go ahead and save your nodes that have the Content Moderation on.
What next? Well, if it's not just one node or “just a few” of them, but a whole “load” of nodes, with Content Moderation enabled, that you need to save, then this is the way to streamline the whole process (feel free to use this method either at devel/php or wherever it's more convenient for you):
Drupal\node\Entity\Node;
$langcode = \Drupal::languageManager()->getDefaultLanguage()->getId();
$result = db_query("SELECT nid FROM node WHERE langcode = 'und' LIMIT 100");
foreach ($result as $record) {
$node = Node::load($record->nid);
$node->set('langcode', $langcode);
$node->save();
}
As you can see in this example, the “trouble maker” langcode legacy is “und” and there's a query limit of 100 nodes that has been set.
Note: In case it's an “overwhelming” load of nodes that you're dealing with, you get to either rely on batch operations or write a hook_cron for streamlining the saving process even more.
Why Would You Be Using the Content Moderation Module In The First Place?
Now since I've put together this use case scenario assuming that you would enable the Content Moderation module for some content type on your Drupal 8 site, how about pointing out its key advantages? Outlining the reasons why I imagined you more than tempted to leverage its functionality:
- it enables you to go beyond the (only) 2 restrictive “published” and “unpublished” statuses available for your content: it introduces some sort of “intermediary” status, too
- practically you get to have one live version of your website for your users and a separate working copy, as well; one that your team (according to their roles and permissions) can review, revise and create on top of it while your site visitors navigate on that currently live version of your site
- moreover, it enables you to define your team's own reviewing and revising workflow, to set up “to do” lists for them, to track each change and review made to that working copy and to approve, in the same workflow, whether a certain completed revision should go live (replacing the current live site) or not just yet
And this is how you fix it: by simply replacing the language with the site's default one (which may or may not be English in your own case)! This is how you fix translations migrated to Drupal 8, which otherwise would give you headaches the very moment that you enable content moderation for them and try to get them saved!