Follow-up for #2001190: Use derivatives for action plugins
+class SaveComment extends ActionBase {
+ public function execute($comment) {
+ $comment->save();
+ Cache::invalidateTags(array('content' => TRUE));
+ }
+}
Sounds like we want a postExecute() method that would run after all of the passed entities have been processed (for invalidating tags or doing any other cleanup).
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 2001196-actions-add-post-execute-6.patch | 8.14 KB | bojanz |
| #6 | interdiff.txt | 6.19 KB | bojanz |
| #5 | 2001196-actions-add-post-execute-5.patch | 2.26 KB | bojanz |
Comments
Comment #1
andypostSuppose save() should be configurable with argument at least
cache invalidation should be moved to separate method at least but better to leave this for entity class
Comment #2
tim.plunkettComment #3
tim.plunkettSo I'm not 100% sure how this would work.
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?
Or is that out of the scope of this issue?
Comment #4
bojanz commented#3 sounds out of scope. Opened #2030291: Allow actions to postpone saving the modified entity and posted a patch for discussion.
Comment #5
bojanz commentedThis patch adds an empty postExecute() method to a plugin base class, calls it from executeMultiple(), converts the SaveComment action to use it.
Should postExecute also be added to the ActionInterface?
Comment #6
bojanz commentedHere is an updated patch that adds the postExecute to all node actions, and removes the cache clear from the views form handler.
I believe that is a more logical way to do it, the views form handler shouldn't be responsible for clearing caches since the action might be executed some other way too (rules, vbo's field, etc). It also removes some of the special casing in NodeBulkForm, bringing us closer to just making the BulkForm field generic and available to all entity types.
If this issue gets in first, we will probably want to modify postExecute() in [##2030291] to accept the $needs_save parameter too.
Comment #8
dawehnerThere could be just a base class for all node plugins.
Comment #9
bojanz commentedTrue. Where to place the postExecute type of logic though? An ActionManager per entity type?
Comment #10
dawehnerWhat about just a NodeActionBase or something like this?
Comment #16
andypostLooks this could be closed, cache invalidation now lives in entities itself
Comment #26
quietone 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 #27
quietone 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 #29
quietone commentedBut move to base system. This is not about the UI.