Using this patch

  1. Upgrade core from 8.3.3 or later to 8.4.0, then apply the patch.
  2. Run drush updb.
  3. Export your sites configuration (if applicable).
  4. Remove the patch and dial back the content_moderation schema version using: drush ev "drupal_set_installed_schema_version('content_moderation', 8401);"

Some of your sites code and configuration will need some updates to work with the changes made to content moderation:

For sites with lots of views that need to convert from a base table to the revision table because of the change record above, manually converting the configuration can follow roughly the following steps:

  1. Change base_table key from the base to the revision table.
  2. Change the base_field key from the ID column to the revision ID column.
  3. Replace all instances of table: OLD_BASE with table: NEW_BASE (for revisionable fields).
  4. Changes instances of relationship: latest_revision__ENTITY_TYPE to relationship: none.
  5. Once converted add an additional "latest revision" filter to the view.
  6. Remove the latest_revision__ENTITY_TYPE from the "relationships" section.
Members fund testing for the Drupal project. Drupal Association Learn more

Comments

Sam152 created an issue. See original summary.

Sam152’s picture

Issue summary: View changes
Sam152’s picture

Issue summary: View changes
Sam152’s picture

Status: Active » Needs review
FileSize
670.41 KB

A first pass of this.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

xjm’s picture

Issue tags: +8.4.0 release notes

I think we should at least mention this upgrade path in the release notes.

Sam152’s picture

Title: Unofficial content_moderation 8.3.5 to 8.4.0 upgrade path » Unofficial content_moderation 8.3.7 to 8.4.0 upgrade path
jibran’s picture

I updated a site to 8.4.x and saw some errors. I think we should document on d.o how to fix it manually.

Sam152’s picture

Version: 8.5.x-dev » 8.4.x-dev
xjm’s picture

@jibran, can you be more specific?

jibran’s picture

+++ b/core/modules/content_moderation/content_moderation.install
@@ -0,0 +1,29 @@
+    $workflow->set('type_settings.states', $states);
+    $workflow->set('type_settings.transitions', $workflow->get('transitions'));

As seen in the upgrade path that we have to set the states and transitions names after the upgrade.

Sam152’s picture

That shouldn't be necessary, not sure what is going on but I can add some more to the test case.

Sam152’s picture

Reroll plus adding to the test to prove we don't need to update labels.

jibran’s picture

Thanks, for the update. FWIW, I was talking about machine name.

Sam152’s picture

Those shouldn't have changed either?

jibran’s picture

Ok, let me clarify. After updating to rc1 states were missing the labels and I have to re-add all the transitions.

Sam152’s picture

I see, so you're saying without the patch, if you want to fix it manually, there should be documentation for that?

jibran’s picture

Yes.

Sam152’s picture

Issue summary: View changes
Sam152’s picture

Issue summary: View changes
Sam152’s picture

Issue summary: View changes
Sam152’s picture

Issue summary: View changes
Sam152’s picture

Issue summary: View changes
Sam152’s picture

Issue summary: View changes
rferguson’s picture

Hey, I'm trying to use this patch to go from 8.3.7 to 8.4, and I'm having trouble applying the patch. So far I've tried placing the patch in the drupal root directory and using patch -p0 < 2896630-13.patch or -p1 with no success. It just says "can't find file to patch at input line 5". It looks like there is no .install file in 8.3.7 for content moderation to start with, not sure if that makes any difference? I've also tried using git apply but it fails silently, and there shouldn't be much different between that and the patch command?

Any help is much appreciated!

Sam152’s picture

Hi @rferguson, this patch applies on top of 8.4.0. You should upgrade your site, as you would normally to this version, then apply the patch before running "updb".

rferguson’s picture

Issue summary: View changes
Sam152’s picture

Thank you for clarifying the issue summary.

rferguson’s picture

One more thing you can maybe help with. The above worked, however for the longest time now I've been having this other issue, possibly it seems related to a previous patch I didn't apply.

On the status page I see this:

ENTITY/FIELD DEFINITIONS
Mismatched entity and/or field definitions
The following changes were detected in the entity type and field definitions.
Content moderation state

The Content moderation state entity type needs to be updated.

Then running drush entity-updates I get this output:
The following updates are pending:

content_moderation_state entity type :
The Content moderation state entity type needs to be updated.
Do you wish to run all pending updates? (y/n): y
Drupal\Core\Entity\EntityStorageException: Exception thrown while performing a schema update. SQLSTATE[42000]: Syntax [error]
error or access violation: 1071 Specified key was too long; max key length is 767 bytes: ALTER TABLE
{content_moderation_state_field_data} ADD UNIQUE KEY `content_moderation_state__lookup` (`content_entity_type_id`,
`content_entity_id`, `content_entity_revision_id`, `workflow`, `langcode`); Array
(
)
in Drupal\Core\Entity\Sql\SqlContentEntityStorage->wrapSchemaException() (line 1513 of
/vagrant/src/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
Failed: Drupal\Core\Entity\EntityStorageException: !message in [error]
Drupal\Core\Entity\Sql\SqlContentEntityStorage->wrapSchemaException() (line 1513 of
/vagrant/src/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
Cache rebuild complete. [ok]
Finished performing updates. [ok]

I'm wondering if there's something quick I can do to fix this? Is it just a matter of changing the column size in the db?

Sam152’s picture

Here is some context on your issue: https://www.drupal.org/node/2890189#comment-12148013

If you used this patch to come from a version 8.3.3 or earlier, and you didn't use the above upgrade path, the "content_entity_type_id" column in the "content_moderation_state_field_data" and "content_moderation_state_field_revision" table will be too long and should be adjusted to "32". I believe updating the tables manually will leave you in an invalid state however because the entity storage schema is persisted in other places, so there will still be a mismatch.

I would look at running the update steps in #2890189: Unofficial content_moderation 8.3.2 to 8.3.3 upgrade path. That patch will no longer apply, but each of the three update hooks should still be valid if you can get them to run.

Resetting your content_moderation schema version to "8401" (as in 8.4 HEAD) and then renaming them to be 8402, 8403 and 8404 respectively should do the trick.

Sam152’s picture

Status: Needs review » Closed (outdated)

The last production site I am responsible for moved to 8.4 today with this patch. I don't have anything further to add to these, so unless anyone else runs into issues I think these can be closed.

rOprOprOp’s picture

I Applied patch as suggested yet I keep getting these warnings:

Warning: array_keys() expects parameter 1 to be array, null given in Drupal\workflows\Plugin\WorkflowTypeBase->getTransitions() (line 258 of core/modules/workflows/src/Plugin/WorkflowTypeBase.php).
Warning: array_map(): Argument #2 should be an array in Drupal\workflows\Plugin\WorkflowTypeBase->getTransitions() (line 261 of core/modules/workflows/src/Plugin/WorkflowTypeBase.php).
Warning: array_combine() expects parameter 1 to be array, null given in Drupal\workflows\Plugin\WorkflowTypeBase->getTransitions() (line 261 of core/modules/workflows/src/Plugin/WorkflowTypeBase.php).
Warning: Invalid argument supplied for foreach() in Drupal\content_moderation\Permissions->transitionPermissions() (line 27 of core/modules/content_moderation/src/Permissions.php).

updated to 8.4.4 after patching

Sam152’s picture

Did you run updb and follow the other steps in the issue summary? You also need to confirm your schema version was at "8401" before running updb and applying the patch.

Sam152’s picture

Can I ask if following the steps in #33 worked?

rOprOprOp’s picture

@Sam152
I am not sure actually. I did (try to) follow the steps and I did run updb. But it is possible that I messed up since I had trouble in my git setup with branch differences and configuration diffenrences. ...I know..

The question is how can I either revert applied updates or check/revert my schemaversion without getting really messy, since updates have been added after the patch updates.
Or maybe the question is, can I manually fix the above issues?

Sorry for bothering you with my clumbsy questions.

Sam152’s picture

Happy to help in any way I can! Schema version is per module, so you can dial the content_moderation one back or forward without impacting anything else. No update hooks have been created for content moderation after the patch was created, so it should be safe.

rOprOprOp’s picture

Ah..ok. Not too familiar with the update version system..
Cool I'll give it a try.

Stephen Ollman’s picture

Getting error after applying the patch and running update.php

An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /update.php/start?id=2740&op=do_nojs&op=do
StatusText: Internal Server Error
ResponseText:

Nothing is saved to the watchdog table.

Running via drush gives:

Error: Class 'NestedArray' not found in
/home/devboxco/public_html/asada/core/modules/content_moderation/content_moderation.install, line 28

$states = NestedArray::mergeDeep($workflow->get('states'), $workflow->get('type_settings.states'));
Stephen Ollman’s picture

My bad... I missed the new code at the top.

use Drupal\Component\Utility\NestedArray;
rOprOprOp’s picture

mhh...still having trouble with this.

All my workflow transitions are gone and I cannot recreate them.

When I run update_8402 I get:

Invalid argument supplied for foreach() NestedArray.php:327

but I guess that's because there are null transitions,

Trying to add a new transition results in:

TypeError: Argument 1 passed to Drupal\workflows\Plugin\WorkflowTypeBase::getNextWeight() must be of the type array, null given

Also trying to import the older config file fails, because the entity allready exist, yet I cannot delete it because it's being used by some of my nodes.

So I am not sure what to do.

Sam152’s picture

Similar issues were reported in #2937527: "Argument 1 passed to Drupal\workflows\Plugin\WorkflowTypeBase::getNextWeight() must be of the type array, null given" when adding a workflow transition. I provided some steps to try and resolve this:

Transitions as "null" looks a bit strange. I would try update that to empty sequence, represented in yaml as "{ }" and then go and reconfigure your transitions from the UI.

If your importing your config from a folder, you can edit the file. If you are using drush, on some versions you can use "drush config-edit", if you have no other options you can run this from a bootstrap using "drush ev" or something else:

\Drupal::configFactory()->getEditable('workflows.workflow.editorial')->set('type_settings.transitions', [])->save();

Make sure this is all being tested offline and you have backups of all of your data.

Sam152’s picture

Queueing up another test run for this, given that's twice someone has run into this issue.

Sam152’s picture

Status: Closed (outdated) » Needs review
rOprOprOp’s picture

Thank you sam for that reference!

I think I've managed to get everything back in order. I have my state transitions and no errors.

I did, like Stephen https://www.drupal.org/project/drupal/issues/2937527#comment-12433588
just manually edit the blob from a backup.
I compared it with the new string and found that (besides all transition) that the uuid was NULL
a:10:{s:4:"uuid";N;s:8:"langcode";s:2:"en";...

So all I did was replace the uuid in the old file with 'N' and then pasted that into the updated database. That gave me only the default transitions back, and all of the state-labels where empty.
After that I ran the 8401 update, this restored all the labels and transitions. Hooray!

The only thing that worries me is, should the workflow not have an uuid?

Sam152’s picture

Modifying data directly in a backup seems kind of risky but glad you got it to a workable state. As far as the UUID, I suppose you could install a fresh copy and compare it with what you have, I'm not sure what the state of that blob should be in off the top of my head.

rOprOprOp’s picture

I agree, it is not the most elegant or safest way to fix things. And I suppose not having that id is not ok.
It is not a recommended solution,

Het is vallen en opstaan :-)

Sam152’s picture

Status: Needs review » Closed (outdated)
tamarpe’s picture

Applied the patch and it works well! thank you :)