Replace the current actions API by a better one, which provides reasonable UX and fulfills the needs for Rules. Having two incompatible action APIs is bad for Drupal and its ecosystem - so this needs a fix.
Next, blocks&layouts needs a conditions API: #1743686: Condition Plugin System - we want to have conditions and actions with a similar DX and UX. Also, we want a conditions API that Rules can build upon to avoid having two incompatible APIs again.
1. Add a new actions API (done!)
2. Add a conditions API that works the same way (done!)
3. Convert core to leverage the new API (remove old action usages and that node operation stuff) (done!)
4. Remove action.module
4. Rename the action.module to action_ui.module
What's wrong with actions.module?
- The current way of configuring actions is very unintuitive. It does not make sense for users to switch to another interface for configuring an action, then go back to whereever to use it. Instead, the primary action configuration should happen on the fly in a multi-step form or so. (Yes, there is a use-case for having pre-configured actions, but that's far not the most common one.)
- Actions need multiple parameters as input. Having just one which is identified solely by an "action type" does not suffice, nor does a magic but undefined $context array for further input help. I need to be able to know when I can execute an action, for which I need to have a complete description of the required inputs.
- Then, another thing the current action system does is tracking the number of recursive calls and caring about recursion. I don't think that's something the action system should take care of. It should provide me with an action that I can execute - whether this creates a recursive loop is up to the calling code; usually (think VBO) it won't. Recursions may occur in the regular trigger/rules use-case, but then it's caused by the triggering logic so the check should be there.
So in the end, I see nothing valuable in the existing actions API left. Let's better re-design it from scratch with the tools we already have: Plugins + TypedData definitions for describing inputs (=action parameters).
The new API
Imo, the focus for core should be on providing an action API that can be configured on the fly - i.e. I select the action, optionally get a configuration form, press submit - it's executed. There is no storage or separate screen for pre-configuration actions required.
Based upon that basic API an UI + storage can be added to build a screen for pre-configuring actions. But I do not even think we need a screen for "pre-configured actions in core?
We already haved typed data definitions in core, which allow use to describe the needed data similar to what Rules does already in Drupal 7. By doing, so we exactly know what the required action parameters are, so we can determine action plugins that are executable given a certain input (e.g. a node).
Moreover, to fulfill the needs of Rules we need to have that kind of data definition for any input - i.e. any string input needs to be defined as parameter. Thus, action parameter configuration is totally decoupled from forms, forms are just the UI on top of the API. That makes it easy to re-use an action from code also.
Relationship to Conditions
Code-wise a condition is very similar to an action, so we can share most of the code. The difference between actions and conditions really is that conditions impose more restrictions upon the actual implementation: It must return a boolean, and it may not alter the input variables (conditions are not expected to issue changes). As conditions impose restrictions upon actions, we can extend conditions from actions, i.e. have ConditionInterface extends ActionInterface. Likewise we can probably extend some of the required classes or use them directly, while for developers the condition API appears to be a separate one that just works the same way as actions. E.g.
-> have \Drupal\Core\Action\ActionManager
-> have \Drupal\Core\Condition\ConditionManager
So the condition core component would have a dependency on the action component.
Using the new API
As said, actions would be based upon the plugin system, so they are instantiated via a respective plugin manager service. For configuring action methods should be used, e.g. like this:
->setArgument('text', 'new title')
More things required by Rules
Unfortunately there is even more we need to have to make the API usable by Rules also. It mostly boils down to features needed for configuring parameters: The ability to select the argument from an available data input (e.g. to configure 'node'), optionally via a data selector ('node:referenced-node') and the ability to have DataProcessors which process the argument value before it is passed on to the action. The core use-case here would be the Tokens, i.e. have tokens replaced before the inputted text is passed on to the action. Rules can add more data processor plugins then.
To keep things reasonable simple in core I think we should make sure that the API for this is in place, but only provide a simple and focussed UI for it in core; e.g. we do not need to have Rules' data selector (for selection node:author:referenced-node:title) in core, a simple select for choosing the "Node" to go with suffices. Rules, then should be able to override this for its own usage by a more sophisticated UI - this should be rather easy by using dependency injection, e.g. we just need to allow Rules to inject it's own ParameterFormManager later on.
User interface changes
The action pre-configuration screen would go away. The remaining 1% use-case of pre-configuring actions instead of configuring them on the fly could be handled by Rules.
The actions API would completely change.