Thread

Have you tried using another embed?

{if embed:entry_id == ""}
    No entry id passed
    {if embed:current_section == "multimedia"}
        current_section IS multimedia
    {if:else}
        current_section IS NOT multimedia
    {/if}
{/if} 
{if embed:entry_id != ""}
    entry id passed: {embed:entry_id}
{embed="site/new_template" entry_id="{embed:entry_id}" current_section="{embed:current_section}"}
{/if}

A separate template (site/new_template):

{exp:weblog:entries entry_id="{embed:entry_id}" dynamic="off" status="not closed" disable="categories|comments|member_data|pagination|trackbacks" show_future_entries="yes"}
        {reverse_related_entries weblog="eyecatchboxes"}
            <dl class="eyecatchbox">
                <dt>{title}</dt>
                <dd>{eyecatchbox_body}</dd>
            </dl>
            {if no_reverse_related_entries}            
                {if embed:current_section == "multimedia"}
                    current_section IS multimedia
                {if:else}
                    current_section IS NOT multimedia
                {/if}
            {/if}
        {/reverse_related_entries}
    {/exp:weblog:entries}

Hello Rob,

Thanks for stopping by.

First, I don’t know if that was clear enough but the last code sample is working as it is.

Embeds could indeed be a possible solution for the code structured the other way around (last example of the multiple test case). I didn’t test yet but I will.

The problem is that we are already in an embed here and that I don’t like going several levels deep with embeds if I don’t really have to, for performance reasons and for preserving my sanity while debugging (See Solspace’s performance guidelines and avoiding multi-dimensional nesting of embeds).

I’d suggest simplifying the template down even further to the bare minimum.  This definitely looks like a parse order issue.

Hello Brandon,

I’d suggest simplifying the template down even further to the bare minimum.

Well, that’s just what I did with the various test cases. I am afraid I can’t simplify it further than this. Again, this code (last one I wrote above) is working properly as it is.

This definitely looks like a parse order issue.

I hear you. I cannot see what else could cause the exact same code to work / not work only if you change the order in which it’s executed (by swapping things around) and by switching between simple and complex conditionals.

What I would like to have here is a thorough explanation in order for me to be able to avoid those parsing issues in the future. I’ve been staring at this page about parse order for a while now and have not been able to make sense of what happens here. Then again, I might be a bit thick and stubborn ... maybe I should forget about it and move along.

I just like to understand things as fully as I can, I guess

Again, thanks for your help with this.

This is a simplified version of the code I use. Things start to get really weird here ;o)

* When both entry_id and current_section are passed, everything is fine. I ran tests with and without a reverse related entry and everything is ok.
* When nothing is passed, even the first level conditional does not seem to be working. No output whatsoever.
* When an entry_id is passed but not current_section the code inside the weblog:entries loop doesn’t return anything

I didn’t bother testing with advanced conditionals at this stage.

Again, sorry for the late reply. I hope that will help you guys narrowing that down.

Hi g-rom,

In trying to understand exactly why this might be happening, can you clarify something you wrote earlier? When you are talking about the entry_id and/or current_section variables being passed, do you mean that you are calling this embed from multiple places and the embed tag may or may not be passing these variables depending on the context it is being used it? In other words, each time you are calling this template as an embed are you setting entry_id and current_section variables explicitly?

Cheers

Greg

Hi Greg,

Yes, that’s exactly what I do. On detail pages, an entry_id is passed (the embed is inside an exp:weblog:entries loop), while no entry_id is passed on list pages. Depending on the section we are in, the default text to be displayed may vary. Sometimes a current_section parameter is passed and sometimes not.

In other words, each time you are calling this template as an embed are you setting entry_id and current_section variables explicitly?

So to answer your question, nope. These variables are not set explicitly each time the embedded template is called. Does that mean I have to use qualifiers instead at the first level: {if entry_id} and {if !entry_id}? Will test that and see if I can switch the two branches more freely or not.

Thanks for looking into this.

Hi g_rom,

Okay, let us know whether that solves the issue. Don’t forget that the format for the conditionals would be:

{if entry_id != '' AND othervar != ''}
{embed="group/template" parent_id="{entry_id}" parent_section="{othervar}"}
{/if}

{if entry_id != '' AND othervar == ''}
{embed="group/template" parent_id="{entry_id}" parent_section=""}
{/if}

Additionally, I’d recommend that you change the names of the variables that you pass to embeds to be different from default EE ones, just to remove any confusion.

Cheers

Greg

Hi Greg,

So. Let me see if I got that one:

1. replace the code in the father template with conditionals covering all cases and making sure BOTH variables are always passed
2. change variables names to be different from default EE ones

Will test this and report back to let you know whether I can switch things around in the code now.

Hello Greg,

Just modified the code of the father templates to always send both variables to the embed > no luck. If I switch branches of the first conditional around, the problem still occurs. Really, this shouldn’t change anything IMHO.

Here are the various files I use (commented).

I really tend to think this is a bug in with template parsing ... or there is something I do not quite understand with parsing order and the various types of conditionals.

g-rom, have you seen http://expressionengine.com/wiki/Parse_Order/ ?

Hello Sue,

Yes, I have been staring at that very page for a few days ... and, for the life of me, I do not see how it relates to what is happening here. Parse order shouldn’t really be influenced by the order in which simple conditionals are listed in the code. In this case, code order has an influence, although only simple conditionals are concerned (at the first level).

I am afraid the only piece of advice to give you at this point is to do some serious reduction testing: reduce your template, drastically. Start from a clean slate, if you will, a minimalistic template, put in a few conditionals and start adding to it until it breaks.

Thanks for stopping by Ingmar,

Well I just did that in this thread, but I will try a more systematic approach maybe.

My question is why does code sample one works, while code sample two doesn’t. The only difference is the switched code order between the two first level {if} (simple conditionals). Please note that both parameters are not systematically passed, depending on the father template calling this embedded one.

Sample one (Works):

{if embed:entry_id == ""}
    No entry id passed
    {if embed:current_section == "multimedia"}
        current_section IS multimedia
    {if:else}
        current_section IS NOT multimedia
    {/if}
{/if}
{if embed:entry_id != ""}
    entry id passed: {embed:entry_id}
    {exp:weblog:entries entry_id="{embed:entry_id}" dynamic="off" status="not closed" disable="categories|comments|member_data|pagination|trackbacks" show_future_entries="yes"}
        {reverse_related_entries weblog="eyecatchboxes"}
            <dl class="eyecatchbox">
                <dt>{title}</dt>
                <dd>{eyecatchbox_body}</dd>
            </dl>
            {if no_reverse_related_entries}            
                {if embed:current_section == "multimedia"}
                    current_section IS multimedia
                {if:else}
                    current_section IS NOT multimedia
                {/if}
            {/if}
        {/reverse_related_entries}
    {/exp:weblog:entries}
{/if}

Sample two (Does not work)

{if embed:entry_id != ""}
    entry id passed: {embed:entry_id}
    {exp:weblog:entries entry_id="{embed:entry_id}" dynamic="off" status="not closed" disable="categories|comments|member_data|pagination|trackbacks" show_future_entries="yes"}
        {reverse_related_entries weblog="eyecatchboxes"}
            <dl class="eyecatchbox">
                <dt>{title}</dt>
                <dd>{eyecatchbox_body}</dd>
            </dl>
            {if no_reverse_related_entries}            
                {if embed:current_section == "multimedia"}
                    current_section IS multimedia
                {if:else}
                    current_section IS NOT multimedia
                {/if}
            {/if}
        {/reverse_related_entries}
    {/exp:weblog:entries}
{/if} 
{if embed:entry_id == ""}
    No entry id passed
    {if embed:current_section == "multimedia"}
        current_section IS multimedia
    {if:else}
        current_section IS NOT multimedia
    {/if}
{/if}

To me, these two codes should work without problem? I’ll try to reduce things as much as I can tomorrow.

I am somewhat stumped myself, g-rom, I wouldn’t suggest this reduction test if I thought there was some other possibility :(

Hello Ingmar,

I’ve done my homework.
Here we go for the reduced template case study.

If I am not using exp:weblog:entries loop, everything works flawlessly, with advanced conditionals or not and whatever the code order

{if embed:entry_id == ""}
    {if embed:current_section == "multimedia"}
        in multimedia
    {if:else}
        not in multimedia
    {/if}
{/if}

{if embed:entry_id != ""}
    {title}
    {if embed:current_section == "multimedia"}
        in multimedia
    {if:else}
        not in multimedia
    {/if}    
{/if}

You can switch things around, staring with the second condition, no problem.

If you are using a exp:weblog:entries loop anywhere in either branches, you can only use simple conditionals inside the exp:weblog:entries loop. That’s logical, given the fact that parse order is as follows:

1. simple conditionals
2. main parsing
3. advanced conditionals

{if embed:entry_id == ""}
    {if embed:current_section == "multimedia"}
        in multimedia
    {if:else}
        not in multimedia
    {/if}
{/if}

{if embed:entry_id != ""}

    {exp:weblog:entries entry_id="{embed:entry_id}" dynamic="off" status="not closed"}
    
         {title}
        {if embed:current_section == "multimedia"}
            in multimedia
        {/if}
        {if embed:current_section != "multimedia"}
            not in multimedia
        {/if}
    
    {/exp:weblog:entries}
    
{/if}

Again, here, you can switch first level branches around in your code, no problem.

When you start playing with relationships (here reverse_related_entries) and special conditionals like {if no_reverse_related_entries}, things get very senstitive with code order. The only way I could make this work is by:

1. Switching back to advanced condtionals inside the “special conditional” {if no_reverse_related_entries}
2. Putting the branch with the exp:weblog:entries loop at the end of my code (the other way around does not work at all).

{if embed:entry_id == ""}
    {if embed:current_section == "multimedia"}
        in multimedia
    {if:else}
        not in multimedia
    {/if}
{/if}

{if embed:entry_id != ""}

    {exp:weblog:entries entry_id="{embed:entry_id}" dynamic="off" status="not closed"}
        
        {reverse_related_entries}
            there are related entries
             {if no_related_entries}
                 no related entries
                {if embed:current_section == "multimedia"}
                    in multimedia
                {if:else}
                    not in multimedia
                {/if}
            {/if}
        {/reverse_related_entries}
    
    {/exp:weblog:entries}
    
{/if}

I still cannot find a logical explanation to this behaviour / source code order dependency. I would definitely appreciate if someone can come up with a logical explanation to this. I am stumped.

Anyway, I’ve got this working ... so I think you can close this thread, unless the challenge appeals to one of you ;o)

Many many thanks to all of you for looking into this.