I'm using this module to generate node titles that either include a link to the content or do not based on another field. Both the linked node title and the non-linked node title (the "Then" and "Or" fields, respectively) require replacement variables. Only the replacement variable for the "Then" ("Then output this...") was working. The "Or" field ("Otherwise, output this...") was simply rendering the field name (e.g., "[field_title]").
Taking a look at the code, I found the logic leading to this behavior was relatively simple to correct (though I'm not sure if it has any unintended consequences elsewhere in the module...it appears to be working fine for me):
On line 214 of views_conditional_handler.inc, I changed the elseif to if.
I'm categorizing this as a feature request rather than a bug, as I'm not sure if the author intended to allow replacement variables in both conditions or not.
| Comment | File | Size | Author |
|---|---|---|---|
| #25 | views_conditional-2036829-25.patch | 2.06 KB | ofry |
| #18 | views_conditional-2036829-18.patch | 2.08 KB | gilsbert |
| #12 | what-is-fixed-by-the-patch.jpg | 54.87 KB | gilsbert |
| #8 | views_conditional-date_stamp_fix-2036829-8.patch | 1.41 KB | JustBlackBird |
| #2 | views_conditional-date_stamp_fix-2036829-2.patch | 1.41 KB | MChittenden |
Comments
Comment #1
MChittenden commentedGood catch. Fixed in the next version but here's a patch to hold you until then.
Comment #2
MChittenden commentedWhoa. Sorry. Here's one that actually works.
Comment #3
ikaros123 commentedI noticed something in this patch ...
variable $then is called twice in the if-else statements
@@ -221,7 +221,7 @@ class ViewsConditionalHandler extends views_handler_field {
if (strpos($then, 'DATE_STAMP') !== FALSE) {
$then = str_replace('DATE_STAMP', format_date(REQUEST_TIME), $then);
}
- elseif (strpos($then, 'DATE_STAMP') !== FALSE) {
+ if (strpos($then, 'DATE_STAMP') !== FALSE) { ----> should this be $or ?
$or = str_replace('DATE_STAMP', format_date(REQUEST_TIME), $or);
}
Comment #4
Renee S commentedComment #5
Renee S commentedComment #6
Renee S commentedThe patch worked for me, btw :)
Comment #7
gilsbert commentedPatch on #2 worked perfectly.
Thank you very much.
Comment #8
JustBlackBird commentedPatch from #2 works for me.
But @liniko123 is right. it seems that the patch from #2 has a bug.
So the correct one is attached.
Comment #9
gilsbert commentedPatch #8 is working.
Can it be added to the oficial release?
Comment #10
gilsbert commentedHi, patch #8 works!
Please commit it.
Comment #11
pepsimxm commentedHi, I've tried patches #2 and #8 and neither are working for me. I'm trying to compare two integers using the 'This value' field. Any help would be much appreciated :)
Comment #12
gilsbert commentedHi @pepsimxm.
I believe the issue's scenario is different from what you reported.
This issue is about a bug not allowing us to use replacement variables inside the option "Otherwise, output this...".
Check the image below.
The red square is marking the option where this issue happened and where it is fixed by the patch #8.
You will see that after patch #8 I'm able to use replacement variables on both options "Then output this..." and "Otherwise, output this..." (before patch #8 it was working only for "Then output this...").
Perhaps I did not understood what you reported.
As far I can understand you are trying to do something like "[field_1] == [field_2]" or "[field_1] == 29" directly on "This value" option.
I believe this is not the correct use of the options.
For instance if I want to compare "field_1" with the integer value "29" I can use the following options:
If this field ==> select "field_1" in the list
Is ==> select "Equal to" in the list
This value ==> fill with the value 29 (no quotes)
Then output this ==> fill with text to output when true
Otherwise output this ==> fill with text to output when false
If I need to compare "field_1" with "field_2" it would be the same with one difference:
This value ==> fill with [field_2]
Anyway if you are trying to use a replacement variable at "This value" option and it is not working then it is a new issue not covered by the patch #8.
Well I hope you find my answer helpful.
Regards,
Gilsberty
Comment #13
pepsimxm commentedHi Gilsberty, thanks for the quick response.
Ok, In understand. The reason why I thought this thread may work for this issue was that it has been closed as a duplicate of 'Replacements in 'This value' field' https://drupal.org/node/2069013. I'll post my question in there now.
Comment #14
gilsbert commentedHi @pepsimxm.
I tested and confirmed the bug.
I believe I'm able to write a patch for it based on patch #8.
Please let me try.
Regards,
Gilsberty
Comment #15
gilsbert commentedComment #16
JustBlackBird commented@gilsbert, I do not think that it is a good idea to mix all problems in the one issue.
Comment #17
gilsbert commentedHi @JustBlackBird.
I understand we should not write one patch for two different issues.
But the original issue and what @pepsimxm reported at #11 are so linked each other that a patch only for #11 would require patch #8 to be applied first. Also the lines to be changed are continuous and I thought - only for this specific case - that only one patch would be better.
I know it all appears different from what I wrote at #12 but that time I had hope that @pepsimxm was not using the options correctly which is not the case unfortunately.
The patch is almost finished.
Let me post it here and check it please.
Regards,
Gilsberty
Comment #18
gilsbert commentedHere we go.
The patch #18 is equal patch #8 in essence.
I added the treatment for replacement variables on the option "this value".
The date stamp fix is not changed so I hope nobody will find new issues from it.
Please let me know if the patch is working for you.
Regards,
Gilsberty
Comment #19
gilsbert commentedComment #20
pepsimxm commentedHi Gilsbert - I've applied patch #18 and it's working for me... and square brackets around the replacement patterns work too.
Thanks a lot for your help!
Comment #21
gilsbert commentedHi.
Thank you very much for testing it.
I would like to thanks @MChittenden and @JustBlackBird because they did an amazing job with the previous patches.
Honestly speaking my contribution was very little.
I'm marking the issue as RTBC hoping the patch may be applied in a future release.
Regards,
Gilsberty
Comment #22
lunazoid commentedExcellent, the patch in #18 is just what I needed!
Comment #23
Todd Young commentedpatch #18 works GREAT, can we get this rolled into a new release? Would be very convenient! This module should be WAY more popular than the numbers would indicate...
Comment #24
sgdev commentedI can confirm that patch #18 works for us too. Should certainly see about getting this in a new release.
Comment #25
ofry commentedI'm rerolled patch #18.
Comment #26
ofry commentedCommitted, doing next release (7.x-1.2)
Comment #27
ofry commented