Problem/Motivation

When you publish an existing revision as the default one, revision_default field should be set to TRUE.

Not doing so could lead to odd states for instance, after publishing a workspace, menu items seem to get stuck on having pending revisions.

The relevant bit of code here is MenuLinkContentStorage->getMenuLinkIdsWithPendingRevisions() which looks at the menu_link_content_revision table and see’s that the revision_default column is set to 0 for the highest revision ID. That seems to be what is disabling some menu UI functionality.

Steps to reproduce

  • Enable workspaces on a clean install.
  • Switch to stage.
  • Add a basic page and click "Provide a menu link" and then save.
  • Publish the Stage content.
  • Goto admin/structure/menu/manage/main and you should see a warning:

Main navigation contains 1 menu link with pending revisions. Manipulation of a menu tree having links with pending revisions is not supported, but you can re-enable manipulation by getting each menu link to a published state.

Proposed resolution

The crux seems to be on line 617 of ContentEntityStorageBase::doSave() where it checks && $entity->isNewRevision() . We don’t get promoted to the revision_default here since workspaces is publishing an existing revision.

It seems that content_moderation is creating new revisions all the time, so a new "published" revision always gets revision_default set to TRUE.

I think workspaces should do the same, even though we are marking an older revision as default, for all intents and purposes that revision should be seen by the system as a "new default revision".

Remaining tasks

  • Validate
  • Review
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Tim Bozeman created an issue. See original summary.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.1.10 (June 4, 2021) and Drupal 9.2.10 (November 24, 2021) were the last bugfix releases of those minor version series. Drupal 9 bug reports should be targeted for the 9.3.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

amateescu’s picture

I think this makes a lot of sense and it was an oversight that we didn't mark the revisions that are being published to Live as "was default revision". Added test coverage for this.

The last submitted patch, 3: 3252100-3-test-only.patch, failed testing. View results

amateescu’s picture

Status: Needs review » Reviewed & tested by the community

Since I only wrote the test coverage, I hope it's ok to RTBC the fix :)

The last submitted patch, 3: 3252100-3-test-only.patch, failed testing. View results

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 3: 3252100-3.patch, failed testing. View results

Tim Bozeman’s picture

Status: Needs work » Reviewed & tested by the community

Random fail? BlockFormMessagesTest passes for me locally.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 3: 3252100-3.patch, failed testing. View results

amateescu’s picture

Status: Needs work » Reviewed & tested by the community

Another random fail.

catch’s picture

Status: Reviewed & tested by the community » Needs work
--- a/core/modules/workspaces/src/WorkspacePublisher.php
+++ b/core/modules/workspaces/src/WorkspacePublisher.php

@@ -106,6 +106,8 @@ public function publish() {
             // revisions.
             $entity->setSyncing(TRUE);
             $entity->isDefaultRevision(TRUE);
+            $revision_default_field = $entity->getEntityType()->getRevisionMetadataKey('revision_default');
+            $entity->{$revision_default_field}->value = TRUE;
 

$entity->isDefaultRevision() is already trying to do this so I don't think it's an oversight but rather something that ought to work, but in fact doesn't. To me this looks like working around ContentEntityBase not handling this situation. I can see working around it here, since fixing it in ContentEntityBase might not be straightforward, but think it at least needs a follow-up issue and @todo to try to address the issue directly in ContentEntityBase and an explanation of why we have to set revision default twice in two different ways.

catch’s picture

Had a closer look at ContentEntityBase::doSave() and maybe it's not that bad to fix it there. Uploading just that patch to see whether it will cause a regression elsewhere.

catch’s picture

Status: Needs work » Needs review
FileSize
2.41 KB

Now with the test coverage added here.

Tim Bozeman’s picture

Status: Needs review » Reviewed & tested by the community

That works great. Thanks Catch!

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 13: 3252100-13.patch, failed testing. View results

amateescu’s picture

Status: Needs work » Reviewed & tested by the community

Looks good to me as well! Back to RTBC because that was a random fail.

catch’s picture

Status: Reviewed & tested by the community » Needs review

One more question - now that the fix is in ContentEntityBase, is there a generic revisions test we can squeeze an extra save and assertion into so that we're not relying on only workspaces for test coverage? Drupal\KernelTests\Core\Entity\EntityRevisionsTest seems like the right place.

amateescu’s picture

catch’s picture

Status: Needs review » Reviewed & tested by the community

New test looks great. Back to RTBC for me.

The last submitted patch, 18: 3252100-18-test-only.patch, failed testing. View results

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

This looks sensible and an easy edge case to have missed. The generic entity test looks nice.

Committed and pushed 29856d7482 to 10.0.x and 3f6a61e7eb to 9.5.x and 2c9e2db9c8 to 9.4.x and 9a3a6c1e5e to 9.3.x. Thanks!

  • alexpott committed 29856d7 on 10.0.x
    Issue #3252100 by amateescu, catch, Tim Bozeman: Set revision_default...

  • alexpott committed 3f6a61e on 9.5.x
    Issue #3252100 by amateescu, catch, Tim Bozeman: Set revision_default...

  • alexpott committed 2c9e2db on 9.4.x
    Issue #3252100 by amateescu, catch, Tim Bozeman: Set revision_default...

  • alexpott committed 9a3a6c1 on 9.3.x
    Issue #3252100 by amateescu, catch, Tim Bozeman: Set revision_default...

Status: Fixed » Closed (fixed)

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