10.3 makes terms moderatable so makes this module need to provide an update path

wonder if there is a better way to add the fields instead of scheduler_content_moderation_integration_entity_base_field_info()

Also running into this problem after an update core to 10.3.0, and running drush updb.

Status report shows the "mismatched entity and/or field definitions error":

"Taxonomy term

- the Publish state field needs to be installed.
- the Unpublish state field needs to be installed."

Presumably by installed it means created.

I ran into the same entity update error after updating core to 10.3.0. I was able to fix it by just running the same "add_fields" function called by the 9001 update hook in the .install file:

drush php:eval "_scheduler_content_moderation_integration_add_fields()"

I tried #4 and it cleared the "mismatched entity and/or field definitions error"

Thanks

Quick note for anyone needing to run that command on an Acquia environment, I found that you need to escape the parenthesis when running the command through acli, acli remote:drush [application].[environment] -- php:eval '_scheduler_content_moderation_integration_add_fields\(\)' worked where application is the project code and environment is the CD, dev, stage, or prod.

It's a bit of a bummer to have to run it for every environment up the chain, but at least it unblocks the upgrade without persistent errors.

We really need another release that adds scheduler_content_moderation_integration_update_9004() calling the same _scheduler_content_moderation_integration_add_fields() function. Or is that too messy and we should just rename the 9001 update and move it to the 9004 position. 🤔

Any preferences from the maintainers? I'm happy to create the MR.

Never remove old updates unless you also use hook_update_last_removed(). You can empty them out. But in this instance I would just add a new update calling the same code.

Thanks, @alexpott. Added a merge request with the repeated function. Let me know if I got the naming convention correct. I assumed it should be "update_10301" as the first update required after Drupal 10.3, but maybe that should be "update_10300". 🤷

I can confirm that this update works as intended. The error message in status report belonging to entity and field definition update disappears after that update-hook.

From my point of view this could be RTBC. A new release would be very helpful. :)

I can also confirm that the MR removed the error message for our site.

This worked for us as well.

Looks like this worked for us as well.

I realized this only works if you've already updated to 10.3. If this was released and you applied it to a 10.2 site prior to upgrading you'd be in the same position. Not sure how to address that though...

I'm setting this back to needs work based on @neclimdul's comment.

Ideally, a maintainer would want to apply the additional update to a new release that required 10.3 or greater. Given the module is currently at 2.0.0-beta2, I'm not completely sure what that release should be.

@smustgrave, I noticed you have a 3.0.x branch for Drupal 11 compatibility. Would it make sense to create a beta release for that branch with a requirement for "drupal/core": "^10.3 || ^11", that contains the new update in this MR?

Sorry for the delay but don't get much time for this module.

But yes the 3.0.x never got a release so I'd be open to a 10.3 requirement there.

Hi there, I got the same issue, I checked the solution provided by and it worked perfectly, either adding it in a new release or in 2.x should be done asap.

Best regards.

Dear all,
I am adding a patch as a temporary solution.

Best regards.

smustgrave → closed merge request !63

Patches shouldn't be added as work should be in the MR please. if you need a patch can download from gitlab.

Made 3.0.x require 10.3 and pushed the fix there since this was previous RTBC.

Will plan a 3.0.0-beta1 release once https://www.drupal.org/project/scheduler_content_moderation_integration/... → is complete too.

FYI did a 3.0.0 release just now

Automatically closed - issue fixed for 2 weeks with no activity.