I only really started using Rules with version 2 and it has made a huge difference to my development. Massive thanks!
When setting a data value (text) I am unable to include a rule variable (also text) in direct input mode. I was originally trying to do this to build up a large string from fields while looping through a list of nodes. For the sake of understandability I've reduced this to the simplest possible case. The rule export is below and requires Devel module.
Note: I can perform direct assignment of one variable to another using data selection. It's just direct input mode where I'm failing.
Please can someone tell me whether I should be able to do this and, if so, what I'm doing wrong?
Edit: Saw how busy the Rules issue queue was so have cross-posted to Drupal Answers...
http://drupal.stackexchange.com/questions/29373/how-to-include-a-rule-va...
{ "rules_example_text_inclusion" : {
"LABEL" : "Example text inclusion",
"PLUGIN" : "reaction rule",
"REQUIRES" : [ "rules", "devel" ],
"ON" : [ "node_view" ],
"DO" : [
{ "variable_add" : {
"USING" : { "type" : "text", "value" : "*This is the value of text_variable_1*" },
"PROVIDE" : { "variable_added" : { "text_variable_1" : "Text variable 1" } }
}
},
{ "variable_add" : {
"USING" : {
"type" : "text",
"value" : "*This is the initial value of text variable 2*"
},
"PROVIDE" : { "variable_added" : { "text_variable_2" : "Text variable 2" } }
}
},
{ "data_set" : {
"data" : [ "text-variable-2" ],
"value" : "Overwriting the value of text_variable_2:\r\n[text-variable-1]\r\n[text_variable_1]\r\n"
}
},
{ "devel_debug" : { "value" : [ "text-variable-2" ] } }
]
}
}
Comment | File | Size | Author |
---|---|---|---|
#30 | 1547160-30-rules-variables-direct-input.patch | 4.55 KB | mitchell |
#30 | 1547160-9--30-interdiff.txt | 1.23 KB | mitchell |
#17 | patch denied.jpg | 64.12 KB | IWasBornToWin |
#9 | 1547160-9-rules-variables-direct-input.patch | 4.09 KB | milesw |
#6 | 1547160-4-rules-variables-direct-input.patch | 4.26 KB | milesw |
Comments
Comment #1
milesw CreditAttribution: milesw commentedWow, I've just spent the day trying to figure this out. None of the variable tokens I use in Direct Input mode get translated, even though they're all text values. Using the Data Selector they work just fine.
Still not sure if it's a bug or by design. Glad I'm not the only one scratching my head.
These issues make me think it could be a bug...
#1415370: Variables as tokens in direct input mode
#1499386: Token unavailable for action provided variables.
#1183676: improve support for arbitrary data structures
#1262904: Why are Replacement Patterns for Direct Input much more restricted than Data Selectors?
Comment #2
milesw CreditAttribution: milesw commentedAlright, dug into the Rules code today and here's what I found:
Why? See the RulesTokenEvaluator class. Tokens without a semicolon are completely ignored. So [variable-name] will never be translated as a token. This is not actually Rules, it's the core token system. See token_scan().
Comment #3
crantok CreditAttribution: crantok commentedWow, thanks for all the research Miles!
I was wondering where this issue should go. It sounds from the other issues you highlighted, specifically
#1415370: Variables as tokens in direct input mode
that extending the availability of tokens available in direct input mode has already been requested (although that issue is marked as a bug report).
Looking at the other related issues you found, it's obvious that this behaviour affects a lot of different uses of variables. I tried putting
drupal rules does not support text variables in Direct Input mode
in to Google but did not get anything obviously relevant apart from this post. A short term solution to avoid more people posting to the Rules issue queue on related topics would seem to be adding a note to the UI in Direct input mode to say, "Note: Not all variables available to data selection mode are available in Direct input mode."
Miles, what do you think? And, if you think it's a good idea, are you in to the Rules code enough to patch this easily?
Comment #4
milesw CreditAttribution: milesw commented@crantok: I gave it a shot and have a decent patch here. Since you've outlined the use case so well, I'd rather post the patch here than in the other issues.
This patch adds functionality to RulesTokenEvaluator to look for variable tokens inside direct input text.
- Non-variable tokens (real tokens) work exactly as before.
- Variables can be specified using [variable_name] or [variable-name].
- Variable tokens cannot contain colons, meaning you cannot directly access sub-properties of custom non-entity structures. So [my_object_variable:my_text_property] will not work. Instead, you should first create a new rules variable from that sub-property.
- Variables must be of type text or a derivative of text (integer, decimal, uri).
- The "Replacement patterns" now includes a list of variables suitable for embedding in text.
If this works out, we should add some notes in the online documentation (which is linked under Replacement patterns).
It would be great to have some Rules developers take a look at this since I'm new to The Rules Way.
Comment #5
milesw CreditAttribution: milesw commentedRemoving duplicate post. Crappy wireless fail...
Comment #6
milesw CreditAttribution: milesw commentedWeird, patch and issue settings got lost. Trying again...
Comment #7
crantok CreditAttribution: crantok commentedGreat! I'll try that out.
Comment #8
crantok CreditAttribution: crantok commentedI tried applying the patch but
git status
showed no changes :( This is the tail of the output...Comment #9
milesw CreditAttribution: milesw commentedMy bad, editor wasn't set to trim whitespace. Here is a properly trimmed patch.
Comment #10
crantok CreditAttribution: crantok commentedWahoo! That totally worked for me.
(BTW, patch didn't apply the first time because I applied it to the wrong repo (blush) )
Comment #11
milesw CreditAttribution: milesw commentedGlad to hear it :)
Comment #12
crantok CreditAttribution: crantok commentedSurprised that this has not got more attention.
The patch clearly solves the problem for the test case above, and solves the same problem for the larger use case I was aiming at originally (building up an email body string incrementally). I was wondering whether to mark as "Reviewed and tested by the community" but I don't feel that I've got sufficient knowledge of Rules module to do that.
I followed the "View details" link for the patch and see that its testing is marked as "Postponed". Any idea if this is normal?
Comment #13
milesw CreditAttribution: milesw commentedI'd say it definitely needs to be reviewed by maintainers, but they're a busy bunch. I did run all tests locally and everything was passing.
Comment #14
IWasBornToWin CreditAttribution: IWasBornToWin commentedI'm unable to apply patch from #9 to rules 7.x 2.1 or dev. Am I doing something wrong? Also, in the patch it shows changes to
--- a/modules/system.eval.inc
+++ b/modules/system.eval.inc
I don't see this anywhere within any rules directory?
Am I missing something? I'm no expert on patches, at all :)
Thanks
Comment #15
mitchell CreditAttribution: mitchell commented> If this works out, we should add some notes in the online documentation.
Yes, definitely. I made some changes to the Data selection docs to add a section for Direct input. This should make it easier to apply the updates started in #4, #12, OP, and #1415370: Variables as tokens in direct input mode.
> Surprised that this has not got more attention. The patch clearly solves the problem for the test case above... I was wondering whether to mark as "Reviewed and tested by the community"...
After two or three reviews, that's a good thing to do. But the code maintainers will still need to be sure that the solution is sound and won't break anything else before they'll commit it. The best thing to do as a reviewer is to provide information for them that proves it works as described and doesn't break anything else for you. And then, of course, help with the docs.
Marked #1415370: Variables as tokens in direct input mode as a duplicate.
IWasBornToWin: here you go, http://drupal.org/patch/apply
Comment #16
IWasBornToWin CreditAttribution: IWasBornToWin commentedThanks for the quick reply. Perhaps I misled you. While I am no expert I do know how to apply patches. I use Net beans. The patch will not take. I tried with the regular and dev version of rules.
Comment #17
IWasBornToWin CreditAttribution: IWasBornToWin commentedSee screenshot.
Comment #18
milesw CreditAttribution: milesw commentedThe patch is against Rules 7.x-2.x-dev. It still applies cleanly for me. Are you using 6.x maybe? There's no "modules" subdirectory in that version.
Comment #19
IWasBornToWin CreditAttribution: IWasBornToWin commentedI tried it with dev but it still wouldn't apply. And I tried it prior to modules (7.x. 1) but for anyone else reading this. I changed it manually in 7.x.1 and it works great.
Comment #20
coreyp_1 CreditAttribution: coreyp_1 commentedI am also reporting that #9 correctly fixes this problem.
I'm marking it "reviewed & tested" since 3 people (myself included) have now reported its success.
Comment #21
pluess CreditAttribution: pluess commentedI successfull applyed this patch to 7.x-2.x-dev. Text variables are replaced as it's expected now. All other token replacements are working fine as well.
Comment #22
IWasBornToWin CreditAttribution: IWasBornToWin commentedCan this patch be committed please? Great work!
Comment #23
andypost+1 to commit, really useful
Comment #24
fluffy CreditAttribution: fluffy commentedPatched 2.1 version with #9, works perfectly.
Comment #25
fagoThanks for that patch. Finally a review.. :
hm, it's odd that token_scan() does not work for tokens without colons. Still, it's strange to have two different approaches for finding tokens: one by looking for all tokens and one by looking for variables.
Let's make our own token_scan variant and use only that instead. It can be a method of the RulesTokenEvaluator.
This should lookup the 'token type' key of the data type, _rules_system_token_map_type() already supports that. Let's just expose Rules' token integration that adds support for those data types, as we've done in d6 and add the mappings to the respective Rules data types. We should better prefix the token types with 'rules_' though, thus do 'rules_text', 'rules_duration', ..
Let's include all helper ins the class and use "protected" for making helpers private. The token_scan() replacement can be public I think though.
Comment #26
mitchell CreditAttribution: mitchell commented@milesw: is this still on your radar? @fago: maybe you could commit this with todos and #25 could be made into a followup, just in case milesw can't get to these improvements soon.
--
I made some updates to the Data selection docs page in anticipation of this issue. Marked #1183676: improve support for arbitrary data structures as a duplicate of this issue and raised priority.
Comment #27
milesw CreditAttribution: milesw commented@fago, thanks for the review! And @mitchell, thanks for the reminder. I won't have a chance to work on this for a few more weeks. If anyone else is eager and wants to jump in, feel free.
Comment #28
franxo CreditAttribution: franxo commentedI can't apply the patch correctly :(
+1 to commit
Comment #29
onelittleant CreditAttribution: onelittleant commentedPatch in #9 applied no problem to 7.x-2.2 and solved some headaches.
+1 to commit, or the variant in #25
Comment #30
mitchell CreditAttribution: mitchell commentedThis updated patch includes TODOs for #25 to be done in #1774630: Make our own token_scan() variant. IMHO, this is an appropriate course.
@milesw: I don't mean to cut you off, but I know users are running your patch in production and some documented features depend on it. I'd love to see you continue this in the follow up issue, should klausi and fago agree with this approach.
EDIT: See the 3rd and 4th files.
Comment #31
fagoPlease do not RTBC your own patches.
Comment #32
Fabianx CreditAttribution: Fabianx commentedWorks like a charm!
Comment #33
fagouhm, let's do it properly *now*. I'll take a look at it.
Comment #34
Chipie CreditAttribution: Chipie commentedThank you. The Patch in #30 works great.
Comment #35
fagoturns out we have two issues and patches for the same problem. see #812058: add token support for non-entities
Comment #36
milesw CreditAttribution: milesw commentedI like the approach used over there, which makes all variables within a rule available as [rule:variable_name]. No need for custom token_scan().
Comment #37
fagoAfter giving this more thought I think we should follow what I've outlined at http://drupal.org/node/812058#comment-6536478. Also, let's better use a single issue so I'm closing this one. Please add further comments to the other one.
Comment #37.0
fagoAdding notice of cross-posting.
Comment #38
Kcannick CreditAttribution: Kcannick commentedDoes patch in #9 still work or has it been committed to dev. I am currently running
Drupal 7.26
Rules 2.6
Token 1.5
Comment #39
Kcannick CreditAttribution: Kcannick commentedIncase anyone else happens to come across this post experiencing the same problem I had.... Tokens will work in direct input mode but I had to add an action to fetch the entity by ID before I could use any of its tokens.
Comment #40
subhojit777I can confirm #30 patch is working (the 4.61 KB one), although the patch does not applies cleanly.
Comment #41
roynilanjan CreditAttribution: roynilanjan commentedAlthough the #30 patch has applied to version *7.x-2.9* but no replacement patterns are found on direct input mode.
Please have a look the export,
In action hard-coded nid have been placed without any replacement-pattern
Comment #42
roynilanjan CreditAttribution: roynilanjan commentedComment #43
roynilanjan CreditAttribution: roynilanjan commentedMore observation https://www.drupal.org/node/2459475
Comment #44
fagoThis should work already, see #812058: add token support for non-entities. For any follow-up items, please open a new issue.