Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2019-03-28 12:21:47

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,788
Website

Vary article limit based on section

I’m either not being devious enough or I need to figure out a new way of rendering this page.

On the home page there are a series of flex grids – one per section – called thus:

<txp:section_list
    sections="list, of, section, to, show"
    break="section"
    breakclass="duo"
    form="frontpage-duo" />

The frontpage-duo Form is fairly standard as follows:

<h1 class="sectionhead"><txp::section_title /></h1>
<txp:meta_description format="" wraptag="p" class="section-blurb" escape="tidy,textile" />
<div class="grid">
   <txp:article_custom section='<txp:section />' limit="4">
      <div class="hero_inline">
         <txp:output_form form="article" />
      </div>
   </txp:article_custom>
</div>

All spiffing. But the client wants the FAQ section to only have 3 articles in it, and to manually inject the 4th article in the grid from somewhere else. Don’t ask why! I’m rapidly coming round to the idea that it’d be simpler to move the article into the /faq section and add a redirect to catch all old links, as I can’t fathom a Textpattern way to do it neatly without duplicating the Form.

But just out of morbid curiosity, is it possible?

At first I thought “easy: <txp:if_section>” but of course that tests the URL context and isn’t cognisant of the section inside the <txp:section_list> tag (or if it does, I couldn’t get it to work).

Then I thought “easy: <txp:if_article_section>” but that can’t be used outside of article context, and the only place it can be used inside article context to, say, set a variable for the limit and test the faq section, is inside the <txp:article_custom> tag. By that time, we’ve already encountered the limit attribute so it’s too late.

Even using <txp:hide process="2"> won’t work, because the parser won’t process the inner content before it hits the variable as it can’t enter the article_custom without knowing all the attributes:

<h1 class="sectionhead"><txp::section_title /></h1>
<txp:meta_description format="" wraptag="p" class="section-blurb" escape="tidy,textile" />
<div class="grid">
   <txp:article_custom section='<txp:section />' limit='<txp:hide process="2"><txp:variable name="duo-limit" /></txp:hide>'>
      <txp:variable name="duo-limit"><txp:if_article_section name="faq">3<txp:else />4</txp:if_article_section></txp:variable>
      <div class="hero_inline">
         <txp:output_form form="article" />
      </div>
   </txp:article_custom>
</div>

One other avenue open to me is to just always process 4 and set up a loop counter in the <txp:article_custom> container. Then do an <if_article_section> in there and if the counter is 3, skip outputting anything and instead output a fixed article from another section via its ID.

Whichever way I slice it, things seem messy, so I’m probably going to move the article and use the redirect. So please don’t waste any major time on this. But if this kind of thing is possible to achieve, I’d be very interested to know how to approach it, generally speaking.

Thank you!


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#2 2019-03-28 13:10:55

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 3,562
Website

Re: Vary article limit based on section

And doing almost what you did but with a helper variable to store the current section of the loop?

<txp:variable name="loop-section"><txp:section /></txp:variable>
<txp:variable name="duo-limit"><txp:if_variable name="loop-section" value="faq">3<txp:else />4</txp:if_variable></txp:variable>
<h1 class="sectionhead"><txp::section_title /></h1>
<txp:meta_description format="" wraptag="p" class="section-blurb" escape="tidy,textile" />
<div class="grid">
   <txp:article_custom section='<txp:section />' limit='<txp:variable name="duo-limit" />'>
      <div class="hero_inline">
         <txp:output_form form="article" />
      </div>
   </txp:article_custom>
   <txp:if_variable name="loop-section" value="faq">
       <!-- your extra article item -->
   </txp:if_variable>
</div>

TXP Builders – finely-crafted code, design and txp

Online

#3 2019-03-28 13:16:26

etc
Developer
Registered: 2010-11-11
Posts: 3,362
Website

Re: Vary article limit based on section

A variant: use variables as limit values:

<txp:variable name="of-limit" value="3" />
<txp:variable name="of-more" value="extra content" />

<txp:section_list  sections="list, of, section, to, show">
...
... limit='<txp:variable name=''<txp:section />-limit'' default="4" />'...
...
<txp:variable name='<txp:section />-more' />
</txp:section_list>

Edit: though introducing some this_section attribute to if_section wouldn’t hurt. FWIW, <txp:if_category category name="faq" /> looks for $thiscategory first inside category loops.

Offline

#4 2019-03-28 13:44:44

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 3,562
Website

Re: Vary article limit based on section

Nice solution too.

I was wondering about the use of default attribute too but couldn’t remember whether it exists. We should add it to the tags docs.


TXP Builders – finely-crafted code, design and txp

Online

#5 2019-03-28 14:15:56

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,788
Website

Re: Vary article limit based on section

Ahhh, how did I forget about the ‘set the section name prior to loop’ trick. Thank you. So obvious now, yes that’ll work fine.

Also, that variable trick of yours, Oleg, is clever. Thank you.

Somewhere, either in the forum or as an issue on GitHub (maybe one copied from Google Code that I can’t find?) there was a conversation and use cases brought up by maniqui about defaulting to ‘this section’ if the <txp:if_section> tag was used inside a <txp:section_list> container/form. Check tag context first and then test the URL context, exactly like <txp:if_category> can, unless you explicitly override it to get the URL context first.

I can’t remember why we didn’t do it. Perhaps over backwards compatibility concerns? Maybe as you say, now would be a suitable time to do it if it can be done?

On a related note, I’d really like to put together a tag test suite so we can run it to produce “now” HTML output and store it somewhere. Then, when we introduce tag changes we can run it against bleeding edge dev and check the output still matches what we expect. Should be a fairly robust regression tester for front-end tags.

We can add tests to it over time to catch more and more edge cases and check we’re not introducing front-end b/c errors. When we add a new test case, we can just re-run the tests against the previous released Txp to obtain the “golden master” HTML for future comparison.

Last edited by Bloke (2019-03-28 14:16:57)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#6 2019-03-29 12:04:22

etc
Developer
Registered: 2010-11-11
Posts: 3,362
Website

Re: Vary article limit based on section

Bloke wrote #317369:

Somewhere, either in the forum or as an issue on GitHub (maybe one copied from Google Code that I can’t find?) there was a conversation and use cases brought up by maniqui about defaulting to ‘this section’ if the <txp:if_section> tag was used inside a <txp:section_list> container/form. Check tag context first and then test the URL context, exactly like <txp:if_category> can, unless you explicitly override it to get the URL context first.

By default, <txp:if_category /> looks for URL context, but you can override it with category attribute. Now <txp:if_section /> has section attribute to this end:

<txp:if_section section='<txp:section />' name="faq" />
<!-- or simply -->
<txp:if_section section name="faq" />

On a related note, I’d really like to put together a tag test suite so we can run it to produce “now” HTML output and store it somewhere. Then, when we introduce tag changes we can run it against bleeding edge dev and check the output still matches what we expect.

That would be ace, but, given the number of tags/attributes combinations, some kind of automation is needed.

Offline

Board footer

Powered by FluxBB