6
So yeah. Parse order. I take it you've seen this pdf. If not, take a look, study it well.
What you need is for the opening tag to be in order before you hit stage 5: the parsing of module/plugin tags. In order to do that, you can only use simple conditionals in combination with early parsed global variables and preload replace variables. Native early parsed ...
5
It turns out that the answer was to add a "random" paramater to the plugin tag, in combination with parse="inward".
From EllisLab: "The random is sort of a hidden trick that is handy in very specific circumstances. Without it, duplicate plugins get replaced by some placeholder text so that the plugin is only run once- and then the content flips into where ...
4
This is a parse order issue - your Channel Entries tag is being parsed before your custom plugin tag, so you're actually passing misc{exp:cookie:retrieve name="exp_lang"} as the channel parameter.
What you need to do is turn your plugin into a tag pair, so it works like this:
{exp:cookie:retrieve name="exp_lang" parse="inward"}
{exp:channel:entries ...
4
To be on the safe side, I'd check for numerical values only, like 201308. Something like this:
{if {event_dates:start_date format="%Y%m"} == {event_dates:end_date format="%Y%m"}}
same month
{if:else}
not same month
{/if}
When debugging the advanced conditionals, try to remove them and add them one at a time to see which actual one is causing the ...
3
You didn't say which version of EECMS you're using. Some versions have parsing issues on conditionals with single quotation marks. Or, maybe, your version of Matrix have one of this issues.
So, first of all, try to replace them.
{if "{placement}" == "sidebar"}
{exp:mx_jumper:put name="standard_image_width"}226{/exp:mx_jumper:put}
{exp:mx_jumper:put ...
3
The first thing I would ask is do you really need a fieldgroup for each product channel? Multiple channels can share the same fieldgroup and you can use publish layouts to hide the fields that are not relevant to a particular product. Using the same fieldgroup will also force you to generalise the fields you use which can be a good thing for rationalising ...
3
Welp, after even more testing an hair pulling I sorted it out. I forgot to set parse_tags="yes" on the exp:stash:set... d'oh!
Model
{!-- SINGLE VARIBLES --}
{exp:stash:set
parse_tags="yes"
trim="yes"
}
{stash:share_image_url}
{exp:ce_img:pair
src="{cf_featured_image:url}"
width="800"
height="450"
crop="yes"
...
3
Turns out the problem wasn't a parse issue after all. Playa disables categories by default so by placing a blank disable="" parameter on the {cf_feed_videos} tag it overrides this and re-enables categories for the related entries.
3
Stash 2.4.3 corrected a long-standing inconsistency with embeds set to process at the start of template parsing. At the other stages of parsing (inline and end) embeds are parsed by default - that is to say, parse="yes" is the default parameter value if not specified, and 2.4.3 added this as the default for start too.
To make your embed behave as it did ...
3
Good news, it should be a quick fix. All you need is to prefix your Playa variables with var_prefix parameter to differentiate the namespace from the Channel Entry variables, although you might have to use the full module tag:
{exp:playa:children field="item_colors" var_prefix="pl"}
"{pl:title}": "{title}",
{/exp:playa:children}
3
put exp:channel:entries inside embeded template
{embed="site/channel" my_plugin_ids="{exp:plugin entry_id="{segment_3}"}
site/channel
{exp:channel:entries channel='{embed:my_plugin_ids}' …
-or-
put exp:channel:entries inside your plugin tag's
{exp:plugin entry_id="{segment_3}" parse="inward"}
{exp:channel:entries channel='{my_plugin_ids}' …
{/...
3
The quotes around {fn_zone} mean it's an advanced conditional which may be the problem.
Can you do:
{if fn_zone == ""}
...
{/if}
Or you may have to use the if:else plugin:
{exp:ifelse parse="inward"}
{if "{fn_zone}"!=""}
{redirect="/store"}
{if:else}
{exp:stash:destroy name="delivery_day"}
{/if}
{/exp:ifelse}
3
The :set tags are not wrong, per se, as you are using the shorthand syntax. However, due to parse order, your 'get' tags are parsing before your 'set' tags since the sets are within the channel entries module tag.
Stephen's answer does fix things, because it moves the channel loop within the set module tags. (However, that is not always convenient.) You ...
3
Do this right way - do not follow the dark side.
Put all your php code into plugin. Your code is not good even from optimization way - not good solution to loop the channel entry. Just make function which will return list of
$item['some_key']|$item['some_key']|$item['some_key']|$item['some_key']
In this case you will do only one request of channel:entry. ...
2
Embed templates don't parse in the way you're expecting them to. And PHP will be irrelevant here to.
What's happening is EE parses the parent template first - completely, so in your example it will parse the exp:channel:entries tag, then the exp:shine_pdf tag. These will be complete and fully parsed. Finished.
Then EE will parse the embedded templates in ...
2
This Stack Overflow post has an answer from Low that should work for you.
Here's how: make sure early parsing is enabled for that variable, and then use the variable syntax instead of the tag syntax:
{exp:channel:entries channel="groups" entry_id="{lv-home-groups}"}
code here
{/exp:channel:entries}
2
You problem is you're trying to do a complex conditional within the tag parameters, that's not possible.
Here's a good article regarding parsing conditionals within tags:
http://johndwells.com/blog/expressionengine-parse-order-advanced-conditionals-as-tag-parameters
As you state, the problem is simple conditionals versus complex conditionals.
The problem ...
2
Depth isn't an issue with embeds and neither is URLs, so if the embed works from template A, it will work from Template B. So it isn't any parameter issue (unless you use embed variables in the parameters - see 2 below).
Three factors that are most likely:
The embed in Template B is within a conditional which is not being met.
You're passing embed ...
2
Is {lv_sidebar_featured_members} set to 'early parsed'? If it is, the problem could be that it contains a channel entries tag and you are nesting it inside another channel entries tag.
2
Try {exp:low_variables:parse var="lv_sidebar_featured_members"} instead of {lv_sidebar_featured_members}
2
Using embeds to ensure they are parsed after advanced conditional eventually worked for me.
2
I saw you already find a solution, but I think you should know the reason your code wasn't working.
Your conditional will never work... Ooops! Please, forgive me. Your conditional will always work because "product1" != "product2".
This code will always evaluate:
{if segment_3!="product1" OR segment_3!="product2"}
<img src="/images/styles/madeinusa....
2
I'm not sure why you're using an embed for this, you're not passing anything to it so I'd use a snippet for sure.
Also may as well use set_list, open the tags above the exp:channel call
{exp:stash:set_list name="resources" parse_tags="yes"}
{exp:channel:entries channel="white_paper|c_study|video|webinar|data_sheet" limit="8"}
{snippet:get_data}
{/...
2
OK, So I had to wrap the entire call in a {exp:stash:parse process='end'} tag and then call the values with just {stash:market_ids}.
Now seems to be working.
2
Have you tried adding parse_conditionals="yes" to the set parameters? Alternatively, reversing the wrapping to put the conditional on the outside of the set tags?
2
I haven't tested this (it's a bit tricky to setup!) but try promoting your Stash tags to the top level of the nesting hierarchy like this... Also with exp:stash:parse you should omit the exp part when you get variables (I think you can get away without parse="inward" with this method too).
{exp:stash:set name="groups" trim="yes" parse_tags="yes"}
{exp:...
2
Yes, that is because the conditional is an advanced one, and will be parsed after plugin tags (ie Stash) (ref LOW's parse order PDF).
If the conditional was a simple one, this could work, but that depends on what {fn_zone} is. Only segment, embed, global variables are parsed as simple, and you have to write the left hand part of the conditional witout curly ...
2
Using an early parsed var (or a Snippet for that matter) like that doesn't work. To illustrate, using the var you geva as an example, and using it like this:
{exp:low_events:entries entry_id="not {lv_exclude_id}"}
...
{/exp:low_events:entries}
...will result in this code when we come to the stage where tags are parsed:
{exp:low_events:entries entry_id=...
2
The easiest solution would be to use Mo Variables which provides an early parsed {logged_in_member_id} which will allow you to use it as a dynamic value in your URL path.
{exp:rest url="/api/get-default-profile-image/{logged_in_member_id}/" format="json" parse="inward"}
{default_profile_image}
{/exp:rest}
2
If it's two plugin tags that you are needing to nest, see changing parse order for nested tags using the parse="inward" parameter.
Only top voted, non community-wiki answers of a minimum length are eligible
