Thread

Have you tried to use a a single template with main content and sidebar with the {exp:mx_jumper:out_global} tag? Just to check if and how it works.

I’ll try that, just did a little test:

//in single-entry
{exp:string:set name="foo"}{channel_short_name}{/exp:string:set}

//in sidebar
{exp:string:output}
{if {foo} != 'hardlopen-afvallen'}
  EE says no match </br>
  Contents of foo: {foo}
{/if}
{/exp:string:output}

Output:

EE says no match
Contents of foo: hardlopen-sporten

Edit: tested it with MX jumper also, output was the same. Here’s the code I used:

{exp:mx_jumper:out_global}

{exp:channel:entries url_title="{segment_1}"}
  {exp:mx_jumper:put name="foo2"}{channel_short_name}{/exp:mx_jumper:put} 
{/exp:channel:entries}

{if {foo2} != 'hardlopen-afvallen'}
  EE says no match </br>
  Contents of foo2: {foo2}
{/if}

{/exp:mx_jumper:out_global}

I have made the same things (popular post in a sidebar in the same channel of the main content) some months ago. I’ll try to find the code and report to you.

I have made the same things (popular post in a sidebar in the same channel of the main content) some months ago. I’ll try to find the code and report to you.

Did you also use the domain.com/single-entry structure? I have no channels in my single entry URLs, that’s why I’m having difficulty getting access to the channel_short_name in a usable way (normally I’d use a segment variable to get the channel name).

I think I may just have to do a custom query to the DB to get the channel name. It’s a dirty solution, but it’ll work.

Hi guys—I don’t have the time today to go further on this with you, but let me ask one question, because I can’t quite be sure from what you’ve posted.

Are you using the String output in an embedded template, for the sidebar?

I think that’s particularly necessary for what you want to do, and as you suspect, because of parse order.

You need to have evaluated everything for the original channel:entries to get the value ready to set for your foo String variable. The purpose of using the embed is that the embed will be parsed after that full parse of the embedding (initial) page.

Since I see foo presented as {foo} in your test printout, I think it has not been set at the time of that printout - nothing to substitute yet.

All this might be the same with the MX approach, if it will work in the circumstance, but I am speaking of String here. Ty and others mention using String for such a sidebar content, though I didn’t find a direct example.

Hoping it helps,
Clive

Are you using the String output in an embedded template, for the sidebar?

Yes, the string is set in the single articles template.
And the string output is placed in the sidebar template.

Since I see foo presented as {foo} in your test printout, I think it has not been set at the time of that printout - nothing to substitute yet.

What do you mean? Where do you see that? When I use {foo} in the content area of the sidebar it does show the right channel name. That’s not the problem. The problem is when I compare {foo} to “hardlopen-afvallen” (which is the channel name in static text format). That comparison evaluates to false. I suspect that’s why {foo} doesn’t work in channel=”{foo}” context.

I can’t do a var_dump on {foo} to check if the string length is right (since it’s an EE variable), but I suspect it isn’t and that it has the same parsing order problem as my original approach.

Hi Jan Paul,

I think Clive’s initial analysis of the var_dump issue is correct.

I think I need it yes, I’m not 100% sure there’s no other way… But the channel isn’t in the URL for single entries, so I can’t dynamically get it from there. I have this URL structure: domain.com/entry-title.

What I’m trying to accomplish is a listing of articles sorted by # of views (in a sidebar next to my articles). The articles listed should only be from the channel that the article belongs to.

Here’s such an article: http://www.nuafvallen.nl/zichtbare-buikspieren. The listings will be displayed in the “Populaire Onderwerpen” sidebar.

Leaving aside the 3rd party addons you are discussing can you not just use something like this:

Sidebar on main template

{exp:channel:entries url_title="{segment_1}" disable="member_data|pagination|custom_fields|categories|category_fields"}
{embed="includes/sidebar_entries" channel="{channel_short_name}"}
{/exp:channel:entries}

includes/sidebar_entries

<ul>
{exp:channel:entries channel="{embed:channel}" other_parameters…}
<li>{title}</li>
{/exp:channel:entries}
</ul>

Cheers

Greg

Greg, gentle thanks; that was certainly the voice of reason, as far as getting actual page results 😉

We were, though, in a second tight little spin about the add-on plugins, and I felt to dig out an answer on that if possible, because it is certainly very convenient both to use and to concept, that EE have some actual variables available (not constants during execution).

The fact that these variables also let you to set them out of order, simply matches the needs of EE’s parsing rules with something that makes a lot of work much easier. Wherever it will operate…

So, what’s the answer, fellows? There are probably two answers to be sufficient: the tags parse=“inward”, and random. The third answer is that you can’t use every ability everywhere. These rules seem to hold similarly for both Ty’s String and Max’s Mx_Jumper.

Here are notes:

- There wasn’t any problem in the setting of the variables, and I think that’s not so tricky, so you can stick with what you have there.

- The first actual difficulty is that most of the abilities of these variables plugins don’t work at all, within the _parameters_ of an exp:entries tag. Maybe they work within other tags’ parameters; I’d guess not.

- this means that you are required to use the most external output form of either plugin; string:output, or mx_jumper:output. You need to place it around the entire exp:entries block to set a parameter there, as you were doing, Jan Paul.

- what you can’t have success in, as far as I could find, is any variant of embedding plugin tags within the exp:entries parameters, and regardless of any quoting.

- The tricks of it operate for either plugin, though I got the ideas from looking at Ty’s notes and code for String.

  == you _must_ use a parse=“inward” parameter for the variable-plugin output tags. This is actually obscure, as parse=“inward” is documented only for use within plugin nesting. It will save the day if you use it on the outside-nested output tags; it will not help if you try it on any variation of putting an output tag entirely within the exp:entries parameters, so far as I could try that.

  == In essence, we are successful at getting the variables output to parse before exp:entries so they’re ready when needed. If we don’t do this, the variable turns up with no value, an empty string. Notice that we do have to mark nesting in this way, even though the tags already look physically nested. This is one of the ways EE parsing naturally is a little different from procedural programming languages.

  == I would recommend, without having looked into it fully, also using the random parameter for the vars_plugin parameters. You can read Ty’s explanation how it allows his plugin to operate in the presence of caching, and again I suspect the same would be true for Max’s, though he will have to do the determination. Having random present doesn’t hurt, and then it will be there if you change caching later and need it.

What does working code look like? I’m running both plugins together, and getting the same correct results from each this way, which is also a nice way of seeing that they don’t interfere with each other.

Setting the variable, in the main template:

{exp:channel:entries etc.}

  {exp:string:set name="foo"}{channel_short_name}{/exp:string:set}
  {exp:mx_jumper:put name="foo2"}{channel_short_name}{/exp:mx_jumper:put}

  ...etc….
 
{/exp:channel:entries}

Using the variable to set the channel, in an embed template:

{!-- with the String add-on --}

{exp:string:output name="foo" parse="inward" random}
  {exp:channel:entries channel="{foo}" dynamic="no" ...etc…. }

    Channel is {channel_short_name} {!-- test only --}
    {title}: {body} {!-- your ordinary entries code etc. --}

  {/exp:channel:entries}
{/exp:string:output} 


{!-- with the Mx_Jumper add-on --}

{exp:mx_jumper:out_global parse="inward" random}
  {exp:channel:entries channel="{foo2}" dynamic="no" ...etc…. }

    Channel is {channel_short_name} {!-- test only --}
    {title}: {body} {!-- your ordinary entries code etc. --}

  {/exp:channel:entries}
{/exp:mx_jumper:out_global}

I’m going to message Ty and Max on this forum conversation, as I suspect they’ll want to consider if anything needs to be updated, or if what we have here is just the way it can be. Max at least needs to take a look at the later part of his documentation and examples, as it’s a bit mixed up at present.

Regards to each here, and I hope this gets you able to use the add-on you purchased as well as Greg’s strictly embed solution, Jan Paul. Giusi, welcome.

C.

[edit] p.s. Jan Paul, it’s actually dynamic=“no” these days, just to be on the safe side.

Thanks Greg, got it working with your solution. I’ll try your solution a bit later on narration.

Edit, your solution works too narration 😊. I’ll use that since it doesn’t require any DB queries.

Thanks everyone for the help, much appriciated!

Here’s the final code I used:

//in the main template
{exp:string:set name="c_channel"}{channel_short_name}{/exp:string:set}

//in the .sidebar include
{exp:string:output parse="inward"}
  {exp:channel:entries channel="{c_channel}" dynamic="no" limit="10" orderby="view_count_one"}
{/exp:string:output}

Thanks for the assist, narration and guisi, Jan Paul, we’ll close the thread once you have a chance to post your solution.

Sounds good, Jan Paul, and I’m glad you’re up and running with something so clean in the end.

I heard from Ty Wangsness yesterday evening, and he says he went through a search much as we did here, originally to get his plugin working for the uses he had for it.

That’s easy to understand, and the benefit comes in discovering the patterns where such a helpful addition to EE’s bag of tricks will work. It’s something I wanted to see a bit better myself, and we’ve documented a good one here.

Regards to each,
Clive

Great stuff everybody 😊 Closing this one out. Feel free to start a new thread Jan Paul is you have any more questions