ExpressionEngine CMS
Open, Free, Amazing

Thread

This is an archived forum and the content is probably no longer relevant, but is provided here for posterity.

The active forums are here.

entries tag parsed after plugin tag

December 15, 2011 11:47am

Subscribe [5]
  • #1 / Dec 15, 2011 11:47am

    MetalArend

    9 posts

    Situation:

    {exp:channel:entries channel="X"}
      {if 'value' != '{exp:ownplugin:action attr_1="{channelX_tag}” attr_2=“key”}’}
      ok
      {/if}
    {/exp:channel:entries}

    Problem:
    When showing this template, the ownplugin is always giving back the wrong result. After some troubleshooting, the problem seems to be that it is trying to use the exact value “{channelX_tag}”, where I would expect it to first parse that tag, and replace the {channelX_tag} with a “real” value, then parse the plugin with that value, and then parse the complex if statement…

    When I use the ownplugin outside the if statement, all works well.
    When I put the {channelX_tag} somewhere else in the template, it gets parsed before the plugin, and thus then all works well too.
    But in the case above, it is just completely ignoring the {channelX_tag}.
    Parsing inward or outward is not working, as expected, as the only plugin is my own plugin. Could it be that it is ignoring everything from the plugin to parse, as it is a “{” inside some “’”?

    Could it be that the tag is embedded too deep? And is there a solution for that?
    Can I maybe use some code in my plugin constructor to check for possible redundand tags?

    I’m curious, and hoping that some of you may know a genious way to get out of this trouble! 😉

  • #2 / Dec 16, 2011 10:18am

    e-man

    1816 posts

    Bit confused here, what exactly is

    'value'

    ?

  • #3 / Dec 16, 2011 11:27am

    MetalArend

    9 posts

    Let’s say I give two attributes to the plugin, like attr_1 and attr_2, and the plugin gives me back atrr_1 + attr_2. If this sum is not equal to ‘value’, then show ok. But ‘value’ may be whatever one can come up with…

    When I ‘exit()’ the constructor of the plugin with the value from attr_2, it shows me the exact value ‘key’. The same happens with attr_1, as it exits with the value ‘{channelX_tag}’, not with the actual value from that tag.

  • #4 / Dec 16, 2011 5:35pm

    e-man

    1816 posts

    Problem is that the plugin data is parsed after the conditional so the conditional has nothing to evaluate, as you’ve already gathered. There’s a great presentation by @low on parse order here: http://www.slideshare.net/lodewijkschutte/parse-order-pro and a good pdf listing EE’s parse order in detail. can be found here http://gotolow/parse-order

    Care to explain in a bit more detail what exactly you’re trying to achieve, they’re may be a way around it without the plugin and/or conditional.

  • #5 / Dec 17, 2011 10:12am

    MetalArend

    9 posts

    Took a look at low’s parse order information before posting here - still this situation seems kinda strange to me.

    The thing is that the plugin actually gets parsed, ‘cause else there wouldn’t be any exit() message? And that exit from the plugin constructor I do get… Or is it just that the plugin gets parsed, even when it’s still not necessary anymore, as the conditional was already parsed before it?

    I’m mostly surprised that the tag inside the plugin does not get parsed at all. If I’m using the plugin outside the conditional, I get a value, as the channel:entries tag gets parsed before the plugin. In the conditional however, the channel:entries tag is completely ignored, leaving the actual tag as the data going into the plugin. If I set ‘value’ in the conditional to a hard-coded value I get from the plugin, it’s also giving me back the success result from the conditional.

    Even after looking through all the information about parse order, it seems to me that the channel:entries tag gets not parsed at all. Could it be that three levels deep is just too much for the parser?

    —-

    About the plugin: I’m trying to get around the strange thing that one can not loop through channel:entries in another channel:entries tag, without using embeds. So I wrote a plugin to search for a search_value in a certain search_field, and return me a return_field - like, I ask for the value from the return_field ‘title’ where the search_value is ‘x’ for the search_field ‘entry_id’. It’s actually quite a simple thing, but gets you a lot of extra freedom. Plugin is also working like a charm, just it will never find the entry_id ‘{member_id}’, which is expected behavior, I assume 😉

  • #6 / Dec 18, 2011 7:59am

    e-man

    1816 posts

    I see. It’s never a good idea to nest channel:entries loops anyway. Maybe have a look at related entries to achieve your goal?
    http://ellislab.com/expressionengine/user-guide/modules/channel/relationships.html

  • #7 / Dec 18, 2011 8:55am

    MetalArend

    9 posts

    Not even trying to, as I understood that it indeed isn’t working that way - shame it is, but hey, those probably are the limitations of the system. I was glad to notice that using a plugin with the channel entries api was doing the trick, ‘till I tried to nest tags into it. And although the relationships documentation is some interesting reading, I’m still curious as to why the channel:entries tag isn’t rendering in the situation described above.

  • #8 / Jan 13, 2012 8:36am

    Tom Jaeger

    497 posts

    Is there any chance you have another instance of the same tag in used in the template?

    {exp:ownplugin:action attr_1=”{channelX_tag}” attr_2=“key”}

    When you mention (in the original post) that

    When showing this template, the ownplugin is always giving back the wrong result

    {if ‘value’ != ‘{exp:ownplugin:action attr_1=”{channelX_tag}” attr_2=“key”}’}
      ok
      {/if}

    Are you always receiving the “ok”?

    In the template parser there is a temporary type of “caching” that take place if a tag occurs more then once.  When nesting it’s not uncommon for the “caching” to actually return a random string (caching reference) instead of the intended data.  Which in this case could cause the if statement to always resolve one way or the other.

  • #9 / Jan 13, 2012 8:54am

    MetalArend

    9 posts

    I tested that, by adding a dirty php exit to my plugin, with the value that it would get from “$this->EE->TMPL->fetch_param( ‘attr_1’ )”. That way I was sure to force EE not to parse the tag when I tried to print it from within the template.

    I then tested if removing those three lines in the code would still give me an exit, and it didn’t. So no problem with the caching by forgetting I possibly had called it somewhere else in the code - allthough it’s an interesting thing to keep in mind for possible other problems in the future.

    So putting it in a little overview:
    changing “{channelX_tag}” to a fixed value - works
    calling the plugin without the if around it - works
    calling the “{channelX_tag}” outside the plugin, but inside an if - works
    calling the plugin with a “{channelX_tag}” inside the variable inside an if tag - ignores parsing the channelX_tag

    Has anybody an idea where the if statements are getting parsed in the php code?

    (Also checked Low’s parse order pdf, and as I seem to understand this *should* work…)

  • #10 / Jan 13, 2012 8:58am

    moonbeetle

    81 posts

    If the presence of the {if…} condition is causing troubles in the parsing order

    {exp:ownplugin:action attr_1=”{channelX_tag}” attr_2=“key” value="SOMEVALUE"}

    Then I would pass both values to tghe plugin, do the matching in the plugin code and let the plugin spit out whatever I need. In fact and depending on the situation I might go as far as fetching the data in the plugin too and use extra attributes to make my plugin code more generic.

     

  • #11 / Jan 13, 2012 9:03am

    MetalArend

    9 posts

    Nice workaround! I’m trying it right now - and thanks again for the great feedback.

    However I’m still hoping to find out whether this actually is a bug, or the reason why it isn’t…

.(JavaScript must be enabled to view this email address)

ExpressionEngine News!

#eecms, #events, #releases