Contrib.social

3rd party should be allowed to add config dependencies

Open on Drupal.org →
Created on 29 November 2018, about 6 years ago
Updated 8 June 2023, over 1 year ago

Problem/Motivation

Scenario: A module 'mymodule', adds a 3rd-party settings to a 'article' node_type config entity:

$article_type = NodeType::load('article');
$article_type->setThirdPartySetting('mymodule', 'role', 'moderator');
$article_type->save();

This ends up in node.type.article as:

id: article
...
third_party_settings:
  mymodule:
    role: moderator
...

As 'moderator' is a reference to other config entity, I'm expecting that this config entity would be added as dependency of node.type.article, for instance:

dependencies:
  config:
     - user.role.moderator
     - ...
   module:
     - ...

But right now there's no API that allows 3rd-party modules to add dependencies to a config entity when 3rd-party settings are being added.

Proposed resolution

Add a 4th optional parameter to setThirdPartySetting():

  /**
   * Sets the value of a third-party setting.
   *
   * @param string $module
   *   The module providing the third-party setting.
   * @param string $key
   *   The setting name.
   * @param mixed $value
   *   The setting value.
   * @param array $dependencies
   *   (optional) Dependencies to be added to the config entity.
   *
   * @return $this
   */
  public function setThirdPartySetting($module, $key, $value, array $dependencies = []);

As, when the such a dependency, added by 3rd party, is being deleted. I have no idea ATM how we should add a 3rd-party response to de the dependency deletion.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

✨ Feature request
Status

Active

Version

11.0 🔥

Component
Configuration entity  →

Last updated about 3 hours ago

Created by

🇷🇴Romania claudiu.cristea Arad 🇷🇴

Live updates comments and jobs are added and updated live.
  • API addition

    Enhances an existing API or introduces a new subsystem. Depending on the size and impact, possibly backportable to earlier major versions.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment almost 2 years ago →
    🇬🇧United Kingdom joachim

    > Yes, as I see, in most cases using own configuration entity is better than using third party settings.

    That's not always possible.

    For example, I'm working on a new branch of Computed Field module, and when a computed field config is deleted, its display settings are left in the view display config entity because the dependencies can't be altered.

    This also suggests that 3rd parties need to be allowed to clean up config that depends on them when they are removed.

  • Comment over 1 year ago →
    🇬🇧United Kingdom joachim

    This is also affecting https://www.drupal.org/project/list_predefined_options → -- see 🐛 Field storage needs to depend on the list options plugin it uses Fixed .

    There, we have plugins which define the options for field. Third party settings handle a dependency on list_predefined_options module, but they don't get the dependency on the module that provides the list options plugin.

    There's a quick and dirty workaround -- save dummy data into third party settings, keyed by the module that's providing the plugin.

    Can we change this to a bug though? It doesn't seem to be an outlandish use case that a third-party setting module would itself have dependencies.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024