section front page

colak · 2018-01-13 10:08:52

Is there a native way (without plugins) to have a front page for a section and have a link to page 2 where the section’s articles are listed (txp:article_list)? Basically I am looking for a native alternative to glx_if_section_frontpage.

Bloke · 2018-01-13 11:04:50

glx_if_section_frontpage just tests two thing:

1. If we’re NOT on a catgeory page (txp:page_url type="c" /> is empty)
2. If the article ID not set (txp:page_url type="id" /> is empty)

So through judicial use of that tag and some <txp:variable /> magic you should be able to simulate the effect with native tags. Not time to try it right now, sorry.

colak · 2018-01-13 11:36:51

Would this be it?

<txp:if_section name="my_section">
<txp:variable name="isnotcategory" value='<txp:page_url type="c" />' />
<txp:variable name="hasnoid" value='<txp:page_url type="id" />' />
<txp:if_variable name="isnotcategory" value="">
<txp:if_variable name="hasnoid" value="">
is section front page
<txp:else />
is section second page?
</txp:if_variable>
</txp:if_variable>
</txp:if_section>

etc · 2018-01-13 12:16:12

If I get it right, you want some special output on the first page? Not tested, but you can try a negative offset:

<txp:variable name="page" value='<txp:page_url type="pg" />' />

<txp:if_variable name="page" value="1">
    frontpage
<txp:else />
    <txp:article limit="10" offset="-10" />
</txp:if_variable>

<!-- older/newer links and other stuff -->

Bloke · 2018-01-13 15:03:11

My first thought was to try and harness the pg attribute to differentiate “first page” but I couldn’t figure out the logic in the limited time I had.

On reflection, we have <txp:if_article_list> and <txp:if_category> which might be more useful tests than checking the <txp:page_url /> parts (although you’d need to nest the conditionals).

I did have a fleeting thought about whether we could introduce some additional types that would help here, but I’m conscious of the tag becoming a catch-all. Perhaps we need to empower a container tag that can output (or test) a bunch of stuff in the current context. e.g:

Is this the front page?
Is it a landing page?
Are we in a list context for a particular content type?
…

In essence, it’d work like a combination of the if_* tags we have now, perhaps even supersede them one day. Drat, it’s starting to sound like a simpler version of smd_if ;-)

Dragondz · 2018-01-14 07:09:50

Hi,

I have allways used

<txp:if_section name="">

to test homepage, but never used it for pagination stuff then dont know if it works.

Cheers.

jakob · 2018-01-14 11:11:24

Does glx_if_section_front_page give you what you want to achieve?

If so, this tag combo – based on Stef’s suggestion – should give you the same:

<txp:if_article_list>
  <txp:if_category>
    <!-- category list page -->
    <txp:article />
  <txp:else />
    <!-- section front page -->
    <txp:article status="sticky" />
  </txp:if_category>
<txp:else />
  <!-- individual article -->
  <txp:article />
</txp:if_article_list>

That differentiates between the section front page and category list and individual article pages, but I don’t know if you can achieve what you want to without assigning all the “second page” articles to a category (e.g. “section-articles”) and your front page article(s) to status = sticky.

etc’s suggestion sounded altogether neater if it works.

colak · 2018-01-15 16:26:47

Hi guys,

Firstly, thank you all very much for your suggestions.

After a lot of deliberation I have managed to persuade our committee that we did not need a second page to the section after all.

Details: The newsletter page in our main site needed to have links to our latest emails (a list compiled using rah_external in our legacy site with the postmaster plugin). The suggestion was to have the links first and click another link for the form. I argued that fewer clicks is better and all information is now in the same page.

etc · 2018-01-15 20:31:01

Bloke wrote #308649:

On reflection, we have <txp:if_article_list> … which might be more useful tests than checking the <txp:page_url /> parts … I did have a fleeting thought about whether we could introduce some additional types that would help here

I actually like this idea, and it was more than time to simplify the “frontpage” detection. Now, e.g. <txp:if_article_list type="c, month, pg" /> additionally checks if any of category, month or pg is set. This allows for flexible frontpage definitions, is backwards compatible and extensible to URL parameters, please test.

jakob wrote #308653:

etc’s suggestion sounded altogether neater if it works.

It works quite well, if you don’t mind ?pg=2 actually outputting the first page of articles. But with the above-mentioned commit one can distinguish between /section/ and /section/?pg=1 URL. Something like this should work now:

<txp:if_article_list type="author, c, month, pg, q"> <!-- not section frontpage -->
    <txp:article />

    <!-- shift appends pg parameter to all page links, even the first one -->
    <txp:newer shift /> - <txp:older />
<txp:else />
    <txp:article pgonly /> <!-- set up pagination -->
    <txp:article status="sticky" />

    <!-- shift="0" outputs the current page link with pg parameter appended -->
    <txp:older shift="0" />
</txp:if_article_list>

Bloke · 2018-01-16 09:11:03

Nice one, Oleg. Seems as if shift acts like a page offset to add/subtract from the pg param. Would the attribute name offset be more in line with our current tags? Or is that too confusing?

colak · 2018-01-16 10:23:54

the ability to easily separate the front to the rest of the pages in sections would be warmly welcomed from all I think.

Oleg’s suggestion does look very promising!!!!

etc · 2018-01-16 10:25:11

Thanks, Stef. The names are often the less evident part :-) I’m ok with offset (that was actually the birth name of shift), just note that it has two purposes:

offsetting, as you say
appending pg=1

I also still hesitate to make <txp:older shift /> output /landing/?pg=1 (and not /landing/?pg=2 as without shift) on a /landing/ page, making the latter a “zero” page (useful?). Not sure offset reflects all this functionality.

Same with type attribute of <txp:if_article_list />. Generally, type means article, file and so on, is this confusing?

Bloke · 2018-01-16 13:07:50

Mmmm yeah, it is slightly different to offset. Not sure. My gut feeling is that shift isn’t super intuitive to non programmers, but I might be wrong. In most case, people will use it to offset the pg parameter by an amount when building next/prev URLs. The fact you can also use it as a boolean to trigger adding pg=1 is a by-product, imo. In other words, at the moment if you don’t specify an offset value, it forces the page to 1 and adds it to the URL.

Whatever we name it, the parameter will have this ‘dual’ functionality at present. Is it consistent with our other boolean attributes? i.e. does specifying ‘true’ in other tags do something different to specifying a value? If it’s broadly consistent, fine. If it’s inconsistent, then maybe we should use offset for the true addition/subtraction of page number, and a different attribute (showalways?? Mmm, maybe not) to trigger the pg=1 behaviour, if we deem that useful.

I’m not too bothered about type as it’s generic enough that we can get away with it. And we’ve used it in <txp:image_info /> and <txp:page_url /> (among others) slightly differently from just “type context” anyway.

colak · 2018-01-17 13:11:20

Why not use the glx paradigm?

ie.

<txp:if_article_list>
<txp:if_section_frontpage name="section_name">
<txp:article id="##" status="sticky" />
<txp:else />
<txp:article />
</txp:if_section_frontpage>
</txp:if_article_list>

etc · 2018-01-17 22:51:38

colak wrote #308705:

Why not use the glx paradigm?

Then we’d need to create also <txp:if_author_frontpage /> and so on, for consistency. And not win much, this does more or less the same:

<txp:if_section name="section_name">
  <txp:if_article_list type="author, c, month, pg, q">
    <txp:article />
  <txp:else />
    <txp:article status="sticky" />
  </txp:if_article_list>
</txp:if_section>

Textpattern CMS

Textpattern CMS support forum

#1 2018-01-13 10:08:52