Problem/Motivation

We currently have an alter system that allows to control what export plugins are enabled. This is used for example to disable certain fields based on profile field settings. However, this requires a known mapping between field settings and the behaviour of a plugin.

When we try to rework how we handle enabling/disabling fields we find that it becomes very difficult to make this mapping.

Similarly if a plugin has some dependencies on configs or modules it must currently be implemented explicitly in the plugin body or by an additional alter hook.

Steps to reproduce

Proposed resolution

We extend the plugin definition to allow for an optional `dependenices` key which mirrors the `dependencies` of config entities. This allows the plugin to specify a dependency on a module, theme or a config entity.

The plugin manager will check the dependencies of a plugin and disable the plugin if its dependencies are not met. If a plugin depends on a config entity then the status of that config entity must be `TRUE` for it to be considered installed.

The alter hook is preserved and invoked before checking dependencies so that modules may add or remove dependencies for plugins if desired.

Remaining tasks

User interface changes

API changes

Data model changes

Comments

Kingdutch created an issue. See original summary.

kingdutch’s picture

tbsiqueira’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.