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
Comment | File | Size | Author |
---|---|---|---|
#18 | 3252100-18.patch | 3.8 KB | amateescu |
#18 | 3252100-18-test-only.patch | 1.39 KB | amateescu |
#13 | 3252100-13.patch | 2.41 KB | catch |
#12 | 3252100.patch | 1.29 KB | catch |
#3 | 3252100-3.patch | 1.86 KB | amateescu |
Comments
Comment #3
amateescu CreditAttribution: amateescu for Tag1 Consulting commentedI 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.
Comment #5
amateescu CreditAttribution: amateescu for Tag1 Consulting commentedSince I only wrote the test coverage, I hope it's ok to RTBC the fix :)
Comment #8
Tim Bozeman CreditAttribution: Tim Bozeman at CyberSolution for Tag1 Consulting commentedRandom fail?
BlockFormMessagesTest
passes for me locally.Comment #10
amateescu CreditAttribution: amateescu for Tag1 Consulting commentedAnother random fail.
Comment #11
catch$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.
Comment #12
catchHad 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.
Comment #13
catchNow with the test coverage added here.
Comment #14
Tim Bozeman CreditAttribution: Tim Bozeman at CyberSolution for Tag1 Consulting commentedThat works great. Thanks Catch!
Comment #16
amateescu CreditAttribution: amateescu for Tag1 Consulting commentedLooks good to me as well! Back to RTBC because that was a random fail.
Comment #17
catchOne 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.Comment #18
amateescu CreditAttribution: amateescu for Tag1 Consulting commentedGood point, here it is.
Comment #19
catchNew test looks great. Back to RTBC for me.
Comment #21
alexpottThis 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!