Voting starts in March for the Drupal Association Board election.
This issue is part of. It holds the architectural & technical plan as well as respective discussions.
This is a summary of the overall plan, mostly based on our discussions in Szeged. We'll make sure to keep it updated it based on any new developments.
Given all changes in Core, porting Rules to 8.x is not a trivial tasks and requires updating of the existing concepts to leverage the new core APIs instead of their D7 counterparts. As lots of those APIs changed fundamentally (New action & condition APIs, Entity property info -> Typed Data, Exportables entities -> Config entities with CMI,..), huge parts of Rules have to be re-factored and updated accordingly.
Forking action and condition systems
Given the release of Drupal 8 is nearing, it is critical to get Rules 8.x out of the door as soon as possible. In order to be able to move on as fast as possible, we decided to basically fork the Drupal core action and condition systems for now, i.e. we’ll override the services with Rules equivalences. That way we can easily work in one repository and quickly do necessary improvements to the action & condition systems. Once we’ve got Rules 8.x working with Drupal 8, we’ll know more on what exactly is needed for the core implementations be useful for Rules, whether there are BC breaks and see whether we can get the improvements into Drupal core or not.
In case this does not work and the Rules and core action & condition systems cannot operate on the same set of provided actions / conditions, Rules will have to provide separate, i.e. duplicated action and condition systems again. Unfortunately, this is not unlikely to happen if we fail to include the improved versions in Drupal 8. E.g. the differences on how you provide actions are significant when you’ve got support for token replacements provided by the engine (Rules or core actions) or not - as in the latter case the action will have to take care of token replacements.
Action / condition context and configuration
We decided to merge configuration and context metadata of conditions and actions in a single “context” array, similar to the “parameters” array in Rules’ Drupal 7 actions. This solves ordering questions and works along with what Rules has been doing in Drupal 7. Action and configuration plugins can be provided with configuration forms in core now, what makes sense to us in particular for stuff like boolean options - however it is not yet exactly clear how the configuration form will relate to the Rules generated form.
One idea that I came up was letting the plugin have full control over its configuration form (if it wants to), while it can embed regular Rules UI elements via respective API calls. Generally, the required context of a plugin will be defined similarly as one defines field definitions for an entity, so defining custom related widgets/formatters will probably be possible in a similar way. Lastly, the so usual approach of having Rules auto-generate the whole form and doing only alterations will still remain possible.
The API for contextual conditions in core has no real usage in practice yet. It’s a very slim layer around typed data definitions, which will have to prove its usefulness and/or might require some refactoring for being able to solve real-world use cases.
Typed data support for tokens
For Rules everything that is selectable via its data selector (=all available typed data), will have to be available as token replacements as well. Instead of integrating all typed data tokens directly with the core token API, we decided to use/provide a separate token replacement API service which will use the regular data selection API to navigate through the data, while it invokes the token system for rendering the last part to a textual token. That way we do not conflict potentially differently provided tokens in the system (as it is the case with entity tokens), while we are able to leverage the token system for textually formatting data.
Xano has been up for doing the necessary improvements in core, but it has yet to be determined whether this will reach community consensus. (See and related issues). Otherwise this will be provided as separate API in contrib.
For the selection of global context and global (site-related) tokens, we need a way for modules to define/add globally available data. Instead of providing a data type with a “global marker”, we’ve been discussing doing a separate, small plugin type which allows one to easily register globally available data (e.g. like og context).
Allow the re-use of underlying API additions
While a lot of the underlying APIs of Rules 7.x were easily re-usable otherwise as part of the Drupal 7 entity module, there are more API components of Rules that are useful outside of Rules. This comprises stuff like the Rules data selection widget, Widget and Formatter plugins on the typed data level, but potentially also stuff like general Context mapping components (API with or without a respective UI) as it would be needed for Blocks&Layouts or Panels in D8 as well. As for actions and conditions, all those components will be developed driven by the Rules use cases only so we can save time for now, while making sure the components are decoupled to allow for potential re-use. Whereever these components end up being distributed/packaged will be determined later on as well, for now they will be developed in a single repository.
One idea that came up during the discussion, is relying on Symfony events for providing Rules events. That could be done in a way modules can implement Symfony events without having to depend on Rules, while they provide the additional metadata needed by Rules as well. Next, this would allow us to easily expose existing Symfony events - even of 3rd party libraries - as Rules events.
This could work something along the following:
- Symfony events are based on an event base class, which provides access to related event variables. This class, can serve as plugin class to Rules if modules put it into the right folder and add the right annotation(s) providing all necessary metadata.
- Additional Rules specific event related code (settings forms, event dispatcher) would have to be provided by implementing optional interfaces, or maybe by related classes/plugins also.
- For adding symfony events, we would have to add in necessary metadata only, e.g. by support reading related yaml files.
A tough issue is how to provide configuration schema for a Rules configuration as it depends on which action / condition plugins are used to configure it. That’s a problem we share with Views though - so there should be a solution for that in core.
Given the amount of work that is required for the port, it seems unlikely that the port can be completed anytime soon without any funding. Therefore, we’ve discussed funding possibilities and started estimating the amount of work necessary. fago, and klausi would be up for working on it, while dasjo would help out mostly on the coordination & management side of things. Inspired by the success of the VDC initiative, we’d also love to get new contributors on board, potentially sponsored by their companies to help making Rules in Drupal 8 a success.
We’ll do some more planning and provide additional information once we have figured the details, but for now the plan is to first talk to potential corporate sponsors and try crowd based funding in second step.
During the port we’d plan to have at least bi-weekly meetings on IRC/hangout and public status updates.
The RulesLogger class will be converted to a service.
Configuration entities will serve as storage only, while the main API does not rely on them in any way. The Rules API & UI needs to be re-usable independently on how the resulting config is stored.
We decided to tag the ported code as 8.x-3.x unless some other semantic versioning guidelines are released in meanwhile.