1

I found similar questions, but the “answers” were alternatives that won’t work here. If I missed an answer, please let me know! Thanks!

I have been having trouble wrapping my head around how parse order might be interacting with the tags here. Hopefully someone can help. The template is actually much more complicated and uses many more custom fields, but this is a basic example I still cannot get to work properly without resorting to a bunch of embeds duplicating code. I want to keep these bits contained in one template if at all possible. Note I am using Dynamo, but also tried with regular exp:channel:entries tags to rule out Dynamo as the problem.

The expectation is all entries in the channel are returned for managers, and other users only see a subset depending on a custom field specifying member groups to allow access to.

For users from managers user groups included in {manager_groups}, this yields “No results ()”, and for other users, this yields something like “No results (IS_EMPTY|24)”.

{exp:switchee variable="{logged_in_group_id}" parse="inward"}
  {case value="{lv_manager_groups}" trim="1"}
    {!-- don’t add any permission filtering for managers --}
    {exp:stash:groups}{/exp:stash:groups}
  {/case}
  {case default="Yes"}
    {exp:stash:groups}IS_EMPTY|{logged_in_group_id}{/exp:stash:groups}
  {/case}
{/exp:switchee}

{exp:dynamo:entries
  channel="resources"
  show_pages="no"
  dynamic_parameters="search:allowed_groups"
  paginate="custom"
  limit="5"
  search_id="{segment_4}"
  search:allowed_groups="{exp:stash:get name='groups'}"
  parse="inward"
}
  {if no_results}
    <p>No results ({exp:stash:get name='groups'})</p>
  {/if}
  {exp:stash:set name="no_pagination_html" trim="yes"}
    {if absolute_results <= 5}
      <p><strong>({exp:stash:get name='groups'}) Viewing:</strong> {exp:stash:filter_name} (1-{total_results})</p>
    {/if}
  {/exp:stash:set}
  {paginate}
    <p><strong>Viewing:</strong> {exp:stash:filter_name} ({abp_entry_from}-{abp_entry_to} of {abp_total_entries})</p>
    <p>
      {if abp_has_previous}<a href="{abp_previous_link}">{/if}&laquo; Prev{if abp_has_previous}</a>{/if} &nbsp;
      {abp_pages}{if abp_is_current}{abp_num}{if:else}<a href="{abp_link}">{abp_num}</a>{/if} {/abp_pages}
      &nbsp; {if abp_has_next}<a href="{abp_next_link}">{/if}Next &raquo;{if abp_has_next}</a>{/if}
    </p>
  {/paginate}
  {if count == "1"}
    {abp_pagination_html}
    {exp:stash:no_pagination_html}
  {/if}
  <p>{title}</p>
  {if count == total_results}
    {abp_pagination_html}
    {exp:stash:no_pagination_html}
  {/if}
{/exp:dynamo:entries}

I tried wrapping the entire dynamo:entries tag pair in

{exp:stash:parse process="end" parse_depth="20"}
  {exp:dynamo:entries …}…{/exp:dynamo:entries}
{/exp:stash:parse}

but this results in nothing being output at all. Also tried removing or changing value of parse_depth parameter, but same result.

I also tried a slightly different structure, which is the way I would do it ideally, since I will have more parameters than just group ID. This method yields all results regardless of user type.

{exp:stash:perms}
  {exp:switchee variable="{logged_in_group_id}" parse="inward"}
    {case value="{lv_manager_groups}" trim="1"}
      {!-- don’t add any permission filtering for managers --}
    {/case}
    {case default="Yes"}
      search:allowed_groups="IS_EMPTY|{logged_in_group_id}"
    {/case}
  {/exp:switchee}
{/exp:stash:perms}

{exp:dynamo:entries
  channel="resources"
  show_pages="no"
  dynamic_parameters="search:allowed_groups"
  paginate="custom"
  limit="5"
  search_id="{segment_4}"
  {exp:stash:get name='perms'}
  parse="inward"
}

What seems to be going on here is in both cases the Stash variable is not being parsed before the entries are pulled. In the first case, the filter is trying to matching something that doesn’t exist, resulting in no entries. And in the second case, the entire filter name is in a variable that doesn’t get parsed, so the entries are pulled with the filter entirely ignored, resulting in all entries.

Is there any way I can use a Stash variable as a parameter for an entries loop?

1 Answer 1

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:switchee variable="{logged_in_group_id}" parse="inward"}
      {case value="{lv_manager_groups}" trim="1"}
        {!-- don’t add any permission filtering for managers --}
      {/case}
      {case default="Yes"}
        IS_EMPTY|{logged_in_group_id}
      {/case}
    {/exp:switchee}
{/exp:stash:set}

{exp:stash:parse process="end"}
  {exp:dynamo:entries
    channel="resources"
    show_pages="no"
    dynamic_parameters="search:allowed_groups"
    paginate="custom"
    limit="5"
    search_id="{segment_4}"
    search:allowed_groups="{stash:groups}"
  }
    ...
  {/exp:dynamo:entries}
{/exp:stash:parse}

An alternative would be to move the setting block into a Stash embed with process="start" to make absolutely sure it gets parsed before you call it.

3
  • So this is interesting. It seems the key here is the removal of exp: from Stash tags inside a exp:stash:parse tag pair. My original second example of how I ideally wanted it works just fine with the parse tag wrapper and removing the exp:. I don’t see this mentioned anywhere in the docs. exp:stash:x and stash:x output same thing inside parse tags, it just must be parse order that differs. Anyway, thank you so much ! Dec 23, 2013 at 22:31
  • Oh and forgot to mention I needed the parse_tags="yes" also. Dec 23, 2013 at 22:35
  • Using exp: at the start of anything in EE means you are making a fresh call to a plugin or module. Omitting it means it is a simple variable that belongs to one of the parent tags (or to the global variables array). On this case the variable belongs to the exp:stash:parse tag and gets replaced as part of that tag's processing, whereas using exp: at the start would delay its replacement until after the dynamo tag, which in this case is too late. Incidentally if Stash were a plugin instead of a module this may have worked ok with parse=inward, since the parse orders are reversed. Dec 24, 2013 at 17:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.