Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Almost all of the links that the rules UI provides have a "destination" parameter which allows the UI elements to be easily embedded in the pages of other modules. Unfortunately, when a user adds a condition group, the "Add another condition to this group" and "Edit this condition group" action links inside the fieldset for the condition group are missing that "destination" parameter, which means that after the user is done adding to the condition group, they're dropped back at the rule editing page instead of the page they came from. In a module I'm writing, this is very disorienting for the user because the page they're coming from looks completely different.
The attached patch fixes this oversight and does a little bit of clean-up on the theme_OR() function.
| Comment | File | Size | Author |
|---|---|---|---|
| rules_admin.render.destination.patch | 1.86 KB | guypaddock |
Comments
Comment #1
mitchell commented@GuyPaddock: I think you're the first developer to use Rules's UI API! :-)
If you feel like getting your feet wet with Drupal documentation, #423800: Provide example foreign UI would be a big help. Here is the current handbook page.
Comment #2
fago+1 for fixing the destination thing, but the patch contains quite some tabs, which makes code-style rather bad. Then better not split the l() call up into multiple lines, better just use multiple "$element['#children'] .=" lines, if you want to split up the long line.
Comment #3
guypaddock commented@fago: Do you want me to re-write the patch, or have you already taken care of the style issues?
@mitchell: Am I really the first developer to use the API? It seems pretty extensible.
I'm making a module that called "Rules in Nodes" allows us to embed rules in nodes. Our use case is a mission-based game, where each mission is stored as a node with a content type of "mission", with validation rules embedded within. Each completed mission is stored as a node with a content type of "achievement", with a node reference field for indicating which mission the achievement pertains to. With this in place, we can see if the achievement is "valid" (satisfies the mission) without having to define rules separately (i.e. through the standard rules interface) for every mission.
Comment #4
mitchell commented@GuyPaddock: That sounds very interesting! I agree that it's very powerful, but it's so new, so yes, it is indeed the first UI implemented outside of admin/rules/*. Your description and provided exports/module code from your implementation would be a major help to #423800: Provide example foreign UI. Let's discuss your examples and perhaps others over there. You, me, and fago are the only ones who seem to be developing with/for this.
Comment #5
fago> Do you want me to re-write the patch, or have you already taken care of the style issues?
I've not yet, so please go for it! ;)
Comment #6
fagoany update?
Comment #7
mitchell commentedComment #8
fagoAs this bug-report is rather old, please verify it's still valid in the latest dev version and re-open if so. For now, I'm marking it as closed.