Problem/Motivation

All configuration entities have a status property and the base class provides \Drupal\Core\Config\Entity\ConfigEntityBase::enable(), \Drupal\Core\Config\Entity\ConfigEntityBase::disable(), \Drupal\Core\Config\Entity\ConfigEntityBase::setStatus() and \Drupal\Core\Config\Entity\ConfigEntityBase::status().

Views supports disabling but user roles does not.

Proposed resolution

Decide what to do. It does not seem right that all configuration entities support disabling. For some configuration entity types like Views it makes sense. For some, like Filter formats is it an essential security feature. For others like user roles introducing support would cause quite a few headaches.

Questions:

  • How can we prevent users from calling the API and expected something to change when it does not?
  • What configuration entities should support disabling and how do we indicate this on the API level?
Entity type Status? Entity key
block Supports being enabled/disabled Yes
block_content_type No support No
comment_type No support No
contact_form No support No
editor They are paired up with filter formats - tested in EditorFilterIntegrationTest::testTextFormatIntegration() No
field_config No support - adding support would raise dragons. No
field_storage_config No support - adding support would raise dragons. No
filter_format Supports being enabled/disabled. This is due to security and preventing filter format delete. Yes
image_style No support No
configurable_language No support No
language_content_settings No support No
node_type No support No
rdf_mapping No support No
responsive_image_style No support No
rest_resource_config Support in \Drupal\rest\Routing\ResourceRoutes::alterRoutes() No
search_page Yep lots of usages of ->status() in SearchPageAccessControlHandler::checkAccess() for example. Yes
shortcut_set No support No
action No support No
menu No support No
taxonomy_vocabulary No support No
tour No support No
user_role No support - given this is permission and security related I think we should avoid this complexity. No
workflow Tentative support in BundleModerationConfigurationForm::form() - also workflows with no status are disabled automatically - adding a state enables the workflow. No
view Supports being enabled/disabled Yes
date_format No support No
entity_form_display Looks like there is support in EntityDisplayRepository::getDisplayModeOptionsByBundle() Yes
entity_form_mode No support No
entity_view_display Looks like there is support in EntityDisplayRepository::getDisplayModeOptionsByBundle() and comment_entity_view_display_presave() Yes
entity_view_mode No support No
base_field_override No support - adding support would raise dragons. No

The documentation on \Drupal\Core\Config\Entity\ConfigEntityInterface::status() is interesting:

  /**
   * Returns whether the configuration entity is enabled.
   *
   * Status implementations for configuration entities should follow these
   * general rules:
   *   - Status does not affect the loading of entities. I.e. Disabling
   *     configuration entities should only have UI/access implications.
   *   - It should only take effect when a 'status' key is explicitly declared
   *     in the entity_keys info of a configuration entity's annotation data.
   *   - Each entity implementation (entity/controller) is responsible for
   *     checking and managing the status.
   *
   * @return bool
   *   Whether the entity is enabled or not.
   */
  public function status();

The current approach is to deprecate the methods on ConfigEntityBase/ConfigEntityInterface and implement a Trait and an Interface for the config entities that support a status.

Remaining tasks

Open a follow up to decide on workflow and status.

User interface changes

None.

API changes

Deprecate \Drupal\Core\Config\Entity\ConfigEntityInterface::enable(), ::disable(), ::setStatus() and ::status().
Introduce new \Drupal\Core\Config\Entity\StatusTrait and \Drupal\Core\Config\Entity\StatusInterface for config entities that support status to use.

Data model changes

None

CommentFileSizeAuthor
#15 2872149-15.patch18.52 KBalexpott
#15 13-15-interdiff.txt1.34 KBalexpott
#13 2872149-13.patch18.15 KBalexpott
#13 9-13-interdiff.txt11.88 KBalexpott
#9 2872149-9.patch8.92 KBalexpott
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

alexpott created an issue. See original summary.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott at Chapter Three commented
Issue summary: View changes
alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott at Chapter Three commented
Issue summary: View changes

I'm pretty sure we should

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott at Chapter Three commented
Issue summary: View changes

I'm pretty sure we should... ... not get into disabled fields. Also disabled roles sounds problematic because security.

Also \Drupal\Core\Config\Entity\ConfigEntityListBuilder::getDefaultOperations() is interesting it does:
if ($this->entityType->hasKey('status')) {
And if this is true it adds enable and disable operations.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott at Chapter Three commented
Issue summary: View changes

Updated table to include which config entities have an entity key of status.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott at Chapter Three commented
Issue summary: View changes
alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott at Chapter Three commented
Issue summary: View changes
alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott at Chapter Three commented
Issue summary: View changes

The documentation on \Drupal\Core\Config\Entity\ConfigEntityInterface::status() is interesting - see issue summary.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott at Chapter Three commented
Status: Active » Needs review
FileSize
2872149-9.patch8.92 KB

Here's an idea of how to deprecate the methods so that support for status is opt-in rather than implicit and not complete or meaningful.

Status: Needs review » Needs work

The last submitted patch, 9: 2872149-9.patch, failed testing.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott at Chapter Three commented
Issue summary: View changes

Completing the table.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott at Chapter Three commented

Looking at configuration entities and how the override status... what's up Webform... 'open' is not a bool :(

  /**
   * The webform status.
   *
   * @var bool
   */
  protected $status = WebformInterface::STATUS_OPEN;

  /**
   * Webform status open.
   */
  const STATUS_OPEN = 'open';
alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott at Chapter Three commented
Status: Needs work » Needs review
FileSize
9-13-interdiff.txt11.88 KB
2872149-13.patch18.15 KB

I was trying to deprecate setStatus in #9 too in favour of using the more expressive ->disable() and ->enable() but that just forces out-of-scope changes. Patch adds an interface for things implementing StatusTrait and fixes the problems with EntityDisplayBase using a NULL default value for a Boolean property.

Status: Needs review » Needs work

The last submitted patch, 13: 2872149-13.patch, failed testing.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott at Chapter Three commented
Status: Needs work » Needs review
FileSize
13-15-interdiff.txt1.34 KB
2872149-15.patch18.52 KB

Ughs... #13 work on PHP7 but traits and inheritance has had some fixes for PHP7. So we can only move the property to the trait in Drupal 9.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott at Chapter Three commented
Issue summary: View changes
dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner as a volunteer and at Chapter Three commented 
  1. +++ b/core/lib/Drupal/Core/Config/Entity/ConfigEntityInterface.php
@@ -16,6 +16,11 @@
+   *
+   * @deprecated in 8.4.0 and will removed in 9.0.0. Use
+   *   \Drupal\Core\Config\Entity\StatusInterface and
+   *   \Drupal\Core\Config\Entity\StatusTrait instead, see
+   *   https://www.drupal.org/node/2872193.
    */
   public function enable();

@@ -23,6 +28,11 @@ public function enable();
+   *
+   * @deprecated in 8.4.0 and will removed in 9.0.0. Use
+   *   \Drupal\Core\Config\Entity\StatusInterface and
+   *   \Drupal\Core\Config\Entity\StatusTrait instead, see
+   *   https://www.drupal.org/node/2872193.
    */

@@ -33,6 +43,11 @@ public function disable();
    * @return $this
+   *
+   * @deprecated in 8.4.0 and will removed in 9.0.0. Use
+   *   \Drupal\Core\Config\Entity\StatusInterface and
+   *   \Drupal\Core\Config\Entity\StatusTrait instead, see
+   *   https://www.drupal.org/node/2872193.
    */
   public function setStatus($status);

@@ -60,6 +75,11 @@ public function setSyncing($status);
+   *
+   * @deprecated in 8.4.0 and will removed in 9.0.0. Use
+   *   \Drupal\Core\Config\Entity\StatusInterface and
+   *   \Drupal\Core\Config\Entity\StatusTrait instead, see
+   *   https://www.drupal.org/node/2872193.
    */
   public function status();

    We should really explain them that they should check the interface before calling this function. I think this deprecation method is not obvious for them. 

  2. +++ b/core/lib/Drupal/Core/Config/Entity/StatusInterface.php
@@ -0,0 +1,51 @@
+   * Status implementations for configuration entities should follow these
+   * general rules:
+   *   - Status does not affect the loading of entities. I.e. Disabling
+   *     configuration entities should only have UI/access implications.
+   *   - It should only take effect when a 'status' key is explicitly declared
+   *     in the entity_keys info of a configuration entity's annotation data.
+   *   - Each entity implementation (entity/controller) is responsible for
+   *     checking and managing the status.
+   *

    I think we should mention whether we recommend to just hide the piece or whether you need to ensure that the code is not running which is related with this config entity.
    Note: the bit about the status key is far less important than the bit about what the expected behaviour is.

  3. +++ b/core/lib/Drupal/Core/Config/Entity/StatusTrait.php
@@ -0,0 +1,68 @@
+   * @return $this
...
+   * @return $this
...
+   * @return $this

    I'm not longer 100% sure about this idea of chaining: ocramius.github.io/blog/fluent-interfaces-are-evil/

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

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

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

joachim’s picture

joachim CreditAttribution: joachim as a volunteer commented
Status: Needs review » Needs work

Setting to needs work based on #17.

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.

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.