Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.In #2001196: Add a postExecute() step to action plugins timplunkett writes:
In theory, you could write a config entity that uses multiple action plugins, like Rules does.
If you have both PromoteNode and StickyNode, both want to try to save the node.
How do we not save it twice?
So how about passing an additional parameter to execute() that controls this behavior?
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | 2030291-postpone-entity-save-in-actions-1.patch | 17.42 KB | bojanz |
Comments
Comment #1
bojanz CreditAttribution: bojanz commentedHere's an example patch that allows us to investigate whether we want to do this.
$needs_save is an awkward variable name. Rules uses $immediate. Perhaps just $save? Or $save_immediately?
Or $postpone_save defaulting to FALSE?
Of course, the parameter doesn't make much sense for actions that don't save entities (or do only that, like "save comment"), or delete entities, but they can just ignore it, I don't see a better way of accomplishing this.
Comment #2
dawehnerInstead of having this a requirement in all of the plugins it seems to be better to have a central place which executes actions or at least one responsible place which executes actions. Rules will certainly provide an alternative way to execute actions, but at least this wrapper should maybe care about settings.
Actions are kind of independent from entities, but I think it would be fine to have some kind of special case how entities are handled.
Comment #11
andypostComment #17
andypostas there's intent #3282744: SAVED_DELETED is not used in D10, D9, or D8 and should be removed
and core adopting new attributes via #3252386: Use PHP attributes instead of doctrine annotations
actions could use kinda "execution context" to get and require data, also result of execution can change context to require "post action" from executor
Comment #18
andypostProbably execution could throw exception when entity changed or saving failed, also now to deal with validation - is enity require validation before saving
probably this state should be present in entity object
Comment #19
quietone CreditAttribution: quietone at PreviousNext commentedAction module is approved for removal. See #3266458: [Policy] Deprecate Action (UI) module in D10 and move to contrib in D11
This is now Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.
It will be moved to the contributed Action project when the Drupal 11 branch is open.
Comment #20
quietone CreditAttribution: quietone at PreviousNext commentedI was on 'autopilot' and the above comment is wrong. It is the Action UI that is being removed. Restoring status.
Sorry for the noise.
Comment #22
andypostthe module moved to contrib project