The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Let's add support for basic event settings, such that often needed event filters can be applied to events. That's more efficient than running conditions later on + enables new use-cases for embedding event configuration there as needed for fluxkraft.
Use cases:
- React on node presave and filter on type == page
- React on commerce order checkout and filter on the default bundle
- React on twitter stream with search "drupal" (fluxkraft)
Development is done in the "event_settings" branch.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | d7_rules_event_settings.interdiff.txt | 23.17 KB | fago |
| #9 | d7_rules_event_settings.patch | 50.93 KB | fago |
| #3 | d7_event_settings.patch | 45.21 KB | fago |
| #2 | d7_event_settings.patch | 43.94 KB | fago |
| #1 | d7_event_settings.patch | 19.22 KB | fago |
Comments
Comment #1
fagoHere is a first not yet complete patch.
Comment #2
fagoHere is a first complete patch. It should be fully working, but misses some test cases for the new functionality.
API changes:
This API changes only affect module that come with their own variant of a rules reaction rule plugin, or another sort of triggerable plugin. I'm not aware of any module having something like that, nor could I think of a good reason for doing so right now, so I don't think that API change should be a big deal.
Comment #3
fagoOk, added a test case.
Comment #4
fubhy commentedThere is still a bug here... The rules_empty_events variable is now written with the computed event set name and not the event base name which causes our fluxkraft event sets to always end up in the empty events array because event name != base event name.
Comment #5
fubhy commentedOr do I have to fire the event with the computed event set name now? I guess I have to... Hmm... Then it makes sense I guess
Comment #6
fubhy commentedI still think it's note QUITE right though... But I'll let you figure that out ;P
Comment #7
fubhy commentedWhen creating a new Rule with an Event that exposes settings the event does NOT get added to the rule after hitting save. However, it always works to configure and save an event on a rule that already exists.
Comment #8
fagoExactly. However, with the current patch we end up with a cache-lookup for each configurable event. So let's better follow the approach of #1555634: Improve performance of event cache by moving to a whitelist and add a cache item that maintains an index of configured-event-set-names.
Comment #9
fagook, updated the patch to account for the problems. Also renamed event settings handler to event handler so we can use it for further event related functionality (dispatcher) also. Also added docs and fixed invocation order to match what we do with entity hooks.
Execution works as it is now, but should be optimised using #1555634: Improve performance of event cache by moving to a whitelist.
Comment #10
fagothis fits the requirements of #2023519: Add support for task handlers and event dispatchers. and generally seems do its job just fine, thus committed.
Comment #11
fagoChange notice created: https://drupal.org/node/2024257