Provide a condition plugin system and unify before incompatible contrib APIs (CTools + Rules)
The implementation adds a condition system below \Drupal\Core\Condition, whereas general aspects factored out into \Drupal\Core\Executable. This can serve as common base for conditions and action plugins. This does not include "processors" yet, which are plugins that process data before it is passed to individual executables - think of token running token replacements. This is in particular necessary for actions, so it would be better flushed separately. Action API refactoring will happen at #1846172: Replace the actions API.
- Make sure configuration related methods end-up in its own interface. This methods already exists for blocks, so it's out of cope for this issue. Related: #1764380: Base class for management of Plugin 'settings'
- Allow grouping of provided conditions for UI purposes, e.g. to allow selecting them from a select with opt-groups. Should be done plugin-generic.
- Add a way for specifying access to plugins, such that available plugins can be filtered out based upon user access. Should be done plugin-generic.
- #1846172: Replace the actions API
- #1921540: Create a User Role Condition
- #1921544: Create a Current Path Condition
- #1921546: Create a PHP Filter Condition
- #1921550: Create a Language check Condition
- #1921568: Create a generic Add Condition FormInterface component
- #1921572: Create a generic Edit Condition FormInterface component
User interface changes
None. Conditions come with the possibility to provide a simple configuration form for their configuration options, which is to be embedded by the caller. Some usage of that can be seen at #1912452: Condition Group User Interface.
Well, it adds a new condition API :-) No changes to existing APIs.
Original report by EclipseGC
Blocks have a notion of visibility right now that we need to continue supporting, however the existing solution is completely ignorant of any sort of context, and needs to largely be rebuilt. As a replacement for this, a Condition Plugin type needs to be created, along with supporting condition plugins. The first pass of this could utilize data-source-less plugins that can rely on things like the request object (for example, determining which page your on to allow for blocks to appear on blog/* or something similar).
CTools' Access plugins are a virtually identical to what we want here. Rules & Context modules have a very similar analog. All 3 of these patterns are virtually interchangeable, and core has many use cases for this same tool. Blocks & Layouts absolutely needs this as well.