Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2020-10-14 20:27:58

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

Non-listable sections

Do you happen to exclude some ‘technical’ sections from articles/sections lists? For example, a section for users registration probably shouldn’t be output when listing the monthly articles.

If yes, then introducing some listable sections option (in addition to frontpage, searchable and in_rss) could be useful. The non-listable sections would be automatically excluded from article/sections lists, unless listed explicitly (like pageless sections), but still be accessible via their URL (unlike pageless sections).

Overkill?

Offline

#2 2020-10-14 23:08:43

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 2,139
Website

Re: Non-listable sections

etc wrote #326389:

Do you happen to exclude some ‘technical’ sections from articles/sections lists? For example, a section for users registration probably shouldn’t be output when listing the monthly articles.

Sure, one one site I had a “design guidelines” section with a few sample articles, including help items and so on.

Overkill?

Certainly not, in my book.


Where is that emoji for a solar powered submarine when you need it ?

Offline

#3 2020-10-15 08:55:39

gaekwad
Admin
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 3,169

Re: Non-listable sections

etc wrote #326389:

Do you happen to exclude some ‘technical’ sections from articles/sections lists? For example, a section for users registration probably shouldn’t be output when listing the monthly articles.

Yes, definitely – whacky syndication formats, a few hacks and bodges.

Overkill?

Nope.

Offline

#4 2020-10-15 09:04:31

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,775
Website

Re: Non-listable sections

Not overkill at all. If they’re excluded from <txp:section_list> by default unless explicitly stated in the tag’s attribute, that’s brilliant. It means these fab usability enhancements:

  1. Sections other than pageless ones can be used for various purposes other than displayable content.
  2. You can add new sections chock full of content and keep them hidden until you’re ready to show them off.
  3. You can quickly remove site sections from the <txp:section_list> tag by simply toggling a setting instead of hunting in template code to find places where they’re used.

I like it.


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

#5 2020-10-15 09:24:15

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

Re: Non-listable sections

Thanks for your support.

Bloke wrote #326398:

If they’re excluded from <txp:section_list> by default unless explicitly stated in the tag’s attribute

Yep, that’s the idea. For <txp:section_list /> the implementation looks straightforward, but what should we do for <txp:article[_custom] />? We can decide to exclude non-listable sections by default, but what if a section is

  • not listable but on_frontpage?
  • not listable but searchable?

and so on.

Offline

#6 2020-10-15 10:33:25

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,775
Website

Re: Non-listable sections

etc wrote #326399:

[for article tags] We can decide to exclude non-listable sections by default, but what if a section is not listable but on_frontpage? not listable but searchable?

My initial thought was that listable would trump everything. Tags would, by default, exclude content in any non-listable section.

But as I thought it through, that might not always be the case. Can we be smarter here? We need some way to tell the article tags to include listable section content. Now, we could do that with another boolean attribute like listable or we could choose to introduce some kind of ‘flag’ attribute. Maybe something like is="listable, searchable, frontpage" which would consider content only if those flags were all set.

Maybe we could then deprecate the frontpage attribute since the tag capabilities to check for various section flags would be expanded?

That setup is not ideal, as we then get into the and/or chestnut of whether they should all be set, or if only one needs to be set to be considered a match. And that doesn’t help us for valueless atributes. For example, frontpage (which, I presume means frontpage="1" in this case?). How would you specify frontpage="0" in an is attribute? And how would it respond to not?

Also, it implies hierarchy. As you alluded, does designating content as visible on the default page mean it’s visible even if it’s not listable? I can see legitimate uses for that, since ‘clicking through’ to view it will still be possible. The content isn’t unavailable, it’s just hidden from navigation. And there’s no requirement to add a permlink to it, so it could simply remain on the front page and nobody would be any wiser as to which section it was served (although it could, theoretically, be spidered if the URL to the non-navigable content was ever discovered).

I suppose you could be setting up a section for content that is only visible on the default page, so you can have a section that is dedicated to content blocks. Currently I do that in pageless sections, which works by virtue of the fact the default page is effectively contentless anyway. But it does mean I need to set up a section or two and then call content in by using section="frontmatter" or whatever.

If we had a way to designate content in a section as “not navigable” but visible on the frontpage only. In that regard, frontpage should override listable. Hmmmmm.

We’d need to consider some use cases to figure out what the best defaults are and what hierarchy we assign to these flags.

EDIT: Searchable is more tricky. If it’s searchable and not listable, is searchability ignored? Or should we allow content discovery – and potentially leaking the endpoint of the content even though it’s not listable? I say not. Maybe if you select listable=no in the section edit panel, then it is NOT syndicatable and NOT searchable: those radios are forced to off. But you may still choose On Frontpage.

Last edited by Bloke (2020-10-15 10:39:44)


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

#7 2020-10-15 11:37:16

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

Re: Non-listable sections

Bloke wrote #326402:

Maybe if you select listable=no in the section edit panel, then it is NOT syndicatable and NOT searchable: those radios are forced to off.

I would leave all options available, combining them can make sense. We just have to choose the most natural/useful one.

Offline

#8 2020-10-16 07:19:30

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 2,139
Website

Re: Non-listable sections

Coming back to this a little late, my 1¥ worth:

Bloke wrote #326402:

My initial thought was that listable would trump everything. Tags would, by default, exclude content in any non-listable section.

[…]

Maybe if you select listable=no in the section edit panel, then it is NOT syndicatable and NOT searchable: those radios are forced to off. But you may still choose On Frontpage.

That is what I would expect as well – not listable means not included (automagically) on front-page, on search results, in feeds and all “special” list (category, author…).

However, it could eventually be interesting to be able to include content from a non-listable section on the front page (or other ?) through manually constructed lists. I am not sure of a concrete example though.


Where is that emoji for a solar powered submarine when you need it ?

Offline

Board footer

Powered by FluxBB