Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
When there is an existing moderated, published node with a forward revision, and you disable workbench moderation for that node type, then the latest revision is still shown in the node edit form (good) but when you save changes, the default revision of the content is not updated (bad). This prevents you from updated the published revision of that content, unless you use the "revert" functionality on the "revisions" tab.
To duplicate on a fresh install:
- Enable moderation for the "article" content type
- Create and publish an article
- Edit the article and save the changes as a draft, creating a forward revision
- Disable moderation for the "article" content type
- Visit the article page
- The default revision has not changed (good)
- The edit tab is labeled "Edit draft"
- The "Latest revision" tab is visible
- Visit the "Latest revision" tab - you get a 403 access denied
- Visit the edit tab
- The latest revision is displayed in the edit form
- Edit, then click "Save and publish"
- You are taken to the view page
- The content is not updated (default revision is the same) <-- this is the only part that should change
- A new revision has been created (seen in the revisions tab)
- Go back to the edit form... and your latest changes are still there
Comment | File | Size | Author |
---|---|---|---|
#21 | can_edit_but_not-2646244-21.patch | 2.53 KB | becw |
Comments
Comment #2
becw CreditAttribution: becw at Palantir.net for Acquia commentedThis is a followup to #2645608: Can't edit existing content after enabling Workbench Moderation; we're fixing these things kind of piecemeal, so maybe when writing the tests for this we can make them broader and catch more of this? For example, what happens to content if the state it is in gets deleted or is no longer available on the content type?
Comment #3
becw CreditAttribution: becw at Palantir.net for Acquia commentedHere is a messy test to that shows this issue.
Comment #5
Crell CreditAttribution: Crell at Palantir.net for Acquia commentedComment #6
Crell CreditAttribution: Crell at Palantir.net for Acquia commentedComment #10
Crell CreditAttribution: Crell at Palantir.net for Acquia commentedComment #11
becw CreditAttribution: becw at Palantir.net for Acquia commentedThis happens because of the way core handles default revisions. When an entity is loaded by
SqlContentEntityStorage
,isDefaultRevision
gets set depending on whether the revision ID matches the revision ID in the base table. This value is used when saving the next revision--nowhere in the normal entity save process does core touch this value.In core, this means that when you create a new revision of a content entity, whether or not the new revision becomes the default revision is always determined by whether the previous revision was the default revision.
Core DOES explicitly set the default revision when you create a new revision using the "revert" button in the revision list.
So, I'm not sure if this is something we should even change. I suspect that when Workbench Moderation is disabled, the default revision will be displayed in the edit form--meaning that if you have forward revisions, they will be available in the revisions list but otherwise inaccessible. If anything, maybe disabling moderation on a content type should make the content type behave the same as if moderation were uninstalled.
Comment #12
Crell CreditAttribution: Crell at Palantir.net for Acquia commentedWell, per #2627012: Delete moderation_state fields when uninstalling workbench_moderation on uninstall we should delete the field content. I do not think we should delete field content just for disabling the moderation checkbox, though. That seems like a great way to lose data. :-)
If you're suggesting that we just don't touch that bundle at all, that makes sense. However, in that case we should probably leave some kind of language on the configuration form that disabling moderation may leave any existing forward revisions orphaned, but they're still accessible from the revisions tab. (Or something.)
Comment #13
becw CreditAttribution: becw at Palantir.net for Acquia commentedYes, that.
Comment #16
becw CreditAttribution: becw at Palantir.net for Acquia commentedHere's a patch that disables our revision loading on the edit form when moderation isn't enabled for a content entity bundle. It includes the messy test from #3.
Comment #21
becw CreditAttribution: becw at Palantir.net for Acquia commentedTurns out, that test doesn't demonstrate the issue anyway: it edits and re-saves the latest revision, but the solution we're working toward with this issue is to work with the way core manages the forward revision/default revision with respect to the node edit form.
Comment #22
becw CreditAttribution: becw at Palantir.net for Acquia commentedComment #23
dawehnerI'm confused about that code. This if would appear when workbench moderation is enabled, don't we want to detect that its disabled?
Comment #24
becw CreditAttribution: becw at Palantir.net for Acquia commented@dawhehner: that code sets it up so that the extra message on the config form only appears if moderation is already enabled, and the user unchecks the "enable" box--since this behavior appears when moderation has been enabled and then gets disabled.
Comment #25
dawehnerAAAh gotcha! Nevermind then.
Comment #26
Crell CreditAttribution: Crell at Palantir.net for Acquia commentedMerged. Thanks, Bec!