Problem/Motivation

Right now, we disable the 'Create a new revision' checkbox because revisions are enforced when using moderation. The publishing default checkbox also doesn't make sense when an entity type is being moderated, the moderation state field controls the publishing status.

Reported by @berdir on slack.

Proposed resolution

For clarity, why not hide the publishing checkbox while we're already altering bundle forms.

Remaining tasks

User interface changes

API changes

Data model changes

Comments

Sam152 created an issue. See original summary.

sam152’s picture

Issue summary: View changes
berdir’s picture

Instead of hiding, maybe als disable with a comment that points to the workflow settings form?

alison’s picture

Strongly agree with @Berdir -- simply b/c if it's hidden, I'll be confused about where the setting is / what I'm supposed to do / etc. Also b/c if you aren't using a workflow, hiding would mean that the ctype settings form is different, and I think having the form be consistent is a good thing!

Thank you for the issue!

alison’s picture

scott_euser’s picture

Just by enabling Content Moderation, the published option at `/admin/structure/types/manage/page` immediately does not work even if 'page' is not selected as a content type. Is that the intention?

List of workflows after enabling Content Moderation:
Content moderation installed

Default settings of Content Moderation (ie, no node type selected):
Content moderation default settings

scott_euser’s picture

Status: Active » Needs review
StatusFileSize
new4.55 KB

Here is a first start on this, but I am guessing the condition should be checking if a moderation handler is selected for the current node type (assuming my comment #6 is a bug) rather than just checking if Content Moderation is enabled. If it is not a bug, should we just be checking if any moderation handler is enabled in case a contrib module provides one?

seanb’s picture

Status: Needs review » Needs work
Issue tags: +Needs tests
+++ b/core/modules/node/src/NodeTypeForm.php
@@ -23,14 +24,22 @@ class NodeTypeForm extends BundleEntityFormBase {
+   * The module handler.
+   *
+   * @var \Drupal\Core\Extension\ModuleHandlerInterface
+   */
+  protected $moduleHandler;
...
+  public function __construct(EntityManagerInterface $entity_manager, ModuleHandlerInterface $module_handler) {

@@ -144,17 +154,24 @@ public function form(array $form, FormStateInterface $form_state) {
+    // Check that the Published option is not managed by content moderation.
+    if (!$this->moduleHandler->moduleExists('content_moderation')) {

Can we do this via a form alter in content moderation?

We should probably also add a test for this.

sam152’s picture

Hey @scott_euser, I think the bug you are describing was fixed in #2946750: Node revisions forced even if bundle not under moderation workflow, but is pending a review. Would be great if you have time to give it a look.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

sam152’s picture

Yeah, we already have an implementation which alters bundle forms and delegates them to the moderation handlers, so I think we should put this in NodeModerationHandler.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

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

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

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

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

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

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now 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.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.