Detecting specific article counts

Bloke · 2025-05-07 08:18:53

Given this, included on every page, to detect if I’m inside a section that only has one article:

<if::article_list>
   <txp:variable name="article_count" trim><items::count text="" /></txp:variable>
</if::article_list>

<!-- Displays [1] -->
[<txp:variable name="article_count" />]

<!-- Displays MULTIPLE -->
<if::variable name="article_count" value="1">SINGLE<txp:else />MULTIPLE</if::variable>

What am I missing? The trim seems to account for getting rid of spaces, so the (default) exact match should work, right?

I need to know in the <head> so I can output a meta canonical tag to point to the actual article if I’m on a list page with a single article (e.g. /about) to avoid SEO duplicate content warnings.

EDIT: This is on 4.9.0-beta.2. Same behaviour in the archive Page on the demo site.

EDIT 2: Ah, okay, it works if I directly assign the value="1" to the variable instead of the <items::count> tag, so this must be a processing order thing. I presume the item count isn’t actually available when it’s first encountered and is injected in a later sweep, but the <if::variable> check is executed immediately so it thinks it’s empty? That doesn’t explain why the value of the variable shows up when I display it, immediately before the <if::variable> test, but maybe that’s injected too during a subsequent parser sweep? If so, how do I get round this? Some sort of [1] processing order hack?

Last edited by Bloke (2025-05-07 08:26:32)

etc · 2025-05-07 09:24:29

Yep, <txp:items_count /> is populated by <txp:article />, so the latter must be processed first: <txp:article[1] />.

Bloke wrote #339666:

That doesn’t explain why the value of the variable shows up when I display it, immediately before the <if::variable> test, but maybe that’s injected too during a subsequent parser sweep?

Yes, <txp:items_count /> postpones itself to the next pass in this case, so your variable outputs the literal <txp:items_count /> first, which becomes 1 on the second pass.

Bloke · 2025-05-07 09:26:33

Cool, thanks. I’ll try the article[1] trick.

This is easy to work around, btw, but it’s a bit of a kludge:

<if::article_list>
   <txp:variable name="article_check" trim>
      <article::custom section='<txp:section />' limit="2" break="|"><article::id /></article::custom>
   </txp:variable>
   <txp:variable name="single_article" trim>
      <if::variable name="article_check" value="|" match="any">no<txp:else/>yes</if::variable>
   </txp:variable>
</if::article_list>

Then I can use <if::variable name="single_article" value="yes"> I'm on a single page</if::variable> anywhere.

Can anyone think of any less resource-intensive ways to get this info?

jakob · 2025-05-07 09:27:42

I can’t remember: does items_count work outside a search context? Otherwise, maybe use the pgonly attribute? Or the article(_custom) tag with offset="1" and txp:evaluate. If sql queries are cached (?), that shouldn’t “cost” too much…

Bloke · 2025-05-07 09:28:55

jakob wrote #339669:

I can’t remember: does items_count work outside a search context?

Yes it does. We deprecated <txp:search_results_count> in favour of it in 4.9.0 because it actually works across the board.

Bloke · 2025-05-07 09:30:22

jakob wrote #339669:

maybe use the pgonly attribute? Or the article(_custom) tag with offset="1" and txp:evaluate

Nice ideas, thank you. The offset trick might be less invasive than my initial hack of having a couple of variables floating around and the conditional.

Last edited by Bloke (2025-05-07 09:30:55)

Bloke · 2025-05-07 09:38:55

etc wrote #339667:

the latter must be processed first: <txp:article[1] />.

That works beautifully on single pages and multiple pages, thank you. I just added that to my default form and it worked. However, on the frontpage that uses a different page template:

Tag error: <items::count text=”“ /> -> Textpattern Warning: secondpass < 2

I’m not using a <txp:article> tag on the home page anywhere. It just contains a bunch of <txp:article_custom> tags to pull in hero articles and the latest N products, into various sections. Do I need to add [1] to all the article_custom tags too?

EDIT: Nope, adding [1] to those doesn’t help. Guess I need to also exclude the counter if the section="" too.

Last edited by Bloke (2025-05-07 09:42:01)

Bloke · 2025-05-07 09:56:13

This kludge works:

<if::section name="">
   <txp:variable name="single_article" value="no" />
<txp:else />
   <txp:variable name="article_count" trim><items::count text="" /></txp:variable>
   <txp:variable name="single_article" trim>
      <if::variable name="article_count" value="1">yes<txp:else />no</if::variable>
   </txp:variable>
</if::section>

It’s probably more elegant to use <txp:evaluate> directly on the <items::count> and save the variable dance, but I always get the test syntax wrong and it takes me ages to scratch my head over it.

jakob · 2025-05-07 10:08:13

Lots of roads lead to Rome … :-)

peterj · 2025-05-12 06:09:38

Bloke wrote #339666:

I need to know in the <head> so I can output a meta canonical tag to point to the actual article if I’m on a list page with a single article (e.g. /about) to avoid SEO duplicate content warnings.

I’m very probably misreading the problem but..

With /about and similar single articles, I usually use the section “articles” (excluded from sitemap and menus) and set its URL pattern to /title. That way its articles are detected as a individual and canonical points to itself.

I think google has stopped worrying so much about duplicate content. “Having duplicate content on your site is not a violation of our spam policies, but it can be a bad user experience and search engines might waste crawling resources on URLs that you don’t even care about” Feb ’25

Bloke · 2025-05-12 11:11:23

peterj wrote #339687:

With /about and similar single articles, I usually use the section “articles” (excluded from sitemap and menus) and set its URL pattern to /title.

Didn’t think of changing the URL scheme for those sections. That’s genius. Saves me a headache. Thank you.

I think google has stopped worrying so much about duplicate content.

Yes, sort of. But they still include it in the webmaster reports and flag it as a soft problem, so I tend to try and eradicate as much as I can.

Textpattern CMS

Textpattern CMS support forum

#1 2025-05-07 08:18:53