Articles / snippets that have no URL + don't show in feeds

Bloke · 2019-12-11 10:12:09

[ Topic split from the cnk_snippet thread. ]

jakob wrote #320425:

* An interesting suggestion that Oleg/Stef had in response to this was the possibility of assigning articles to sections that have no url scheme (i.e. no link of their own). That would solve part of the problem of feeds, urls, etc. but not the overfull article list.

Since Oleg introduced per-section permlink schemes, this has potential. Add an entry to the list of available URL schemes: none. If the scheme is set thus, you can’t view the article.

Similarly, when using <txp:section_list /> we could get it to automatically exclude any sections with no URL scheme so they won’t appear in your navigation. Of course, if you actually want to display this section, you can provide it manually in the sections attribute (although why you’d want to do this if there are no articles that you can see, I’m not sure).

Edge cases might be that you can hard-code links to the articles because, even though the permlink scheme would be set to ‘none’, you can always get at the articles by using messy syntax. Is this likely to cause a problem that someone might just do example.com?id=123 and discover your snippets out of context?

Anyway, as long as we think about that and make some sensible choices, a system like that would allow you to create a section called ‘snippets’ and assign article content to it, free of your site navigation, but still available to draw it into other places (such as Forms) via <txp:article_custom> tags. We’d also have to think about the <txp:permlink> tag and how it would react, as well as excluding the articles from next/prev neighbour navigation.

That would solve part of the problem of feeds, urls, etc. but not the overfull article list._

Yes, so perhaps in tandem, we filter the Articles panel to show only articles assigned to sections that have permlink schemes. A filter/checkbox of some kind might then be introduced to show all of them, and that setting could be remembered (localStorage). Or, a new panel exactly like the articles panel to only manage content that’s assigned to no-permlink Sections. That panel would only appear if you have created such a Section. Not sure I’m a fan of either of those options.

Alternatively, omit it by default from the Articles list so it doesn’t clutter your real articles. But if you click on the article count in the Sections panel, it would take you to the Articles panel and filter the articles to only the ones from the clicked section – exactly like it does now for regular sections. So the only valid ways to view such articles in the Articles panel are:

1) To click the article count in the Sections panel.
2) To perform a search on the Articles panel – either by Section (i.e. manually do what clicking on the article count from the Sections panel does) or by content/category/whatever, which shows results from all articles regardless of permlink scheme.

Not sure. Oleg? Is all this doable in short supply as an extension to the per-section permlink scheme? Or is it something we should defer to 4.8.1? Or not do at all?

etc · 2019-12-11 11:52:32

Bloke wrote #320435:

Not sure. Oleg? Is all this doable in short supply as an extension to the per-section permlink scheme? Or is it something we should defer to 4.8.1? Or not do at all?

It’s tempting, of course, but are we sure it will fit our future custom fields model? Would ‘articles’ become ‘items’ that are or are not publicly accessible or should we introduce a new ‘item’ entity? We’d better think twice imo.

Bloke · 2019-12-11 11:56:21

Good point. Let’s think about it.

jakob · 2019-12-11 14:43:23

etc wrote #320438:

Would ‘articles’ become ‘items’ that are or are not publicly accessible or should we introduce a new ‘item’ entity?

Hehe, I remember that idea about ‘items‘ from the original discussion.

Bloke wrote #320435:

Since Oleg introduced per-section permlink schemes, this has potential. Add an entry to the list of available URL schemes: none. If the scheme is set thus, you can’t view the article.

Yep. That should entail that they don’t appear in feeds by default either.

Similarly, when using <txp:section_list /> we could get it to automatically exclude any sections with no URL scheme so they won’t appear in your navigation.

Yep. Unless explicitly mentioned, e.g. in a section_list attribute.

… a system like that would allow you to create a section called ‘snippets’ and assign article content to it, free of your site navigation, but still available to draw it into other places (such as Forms) via <txp:article_custom> tags.

Perfect!

We’d also have to think about the <txp:permlink> tag and how it would react, as well as excluding the articles from next/prev neighbour navigation.

Maybe this / these simply default to current / next / prev article_url_title. A typical situation is that you might use #article-url-title to jump to the relevant part, or to trigger a modal or something.

Article list display / article edit …

Maybe – for the time being at least – they could be simply handled just like normal articles. The only difference is that they’re not part of feeds, etc.
You’d need to be able to get to them easily for editing, so I’m not sure about the other ideas like only findable via the sections panel, which would make them hard to find, and not available to all user privilege levels.

My ideal scenario would be that there’s some kind of callback in the admin-list panel that could allow one – with the help of a plugin – to:

remove them from the regular article list (+ search + next/prev)
add a menu item to output them – or a subset of them – in a separate list panel, or several section-specific panels.
presumably a plugin with an own list panel would also mean one could customise the columns that show and the default sort order (i.e. by date for events).

For example, a “gig” or “faq“ plugin might simply create that no-url section, filter those articles out of the articles panel and show them in their own Content menu entry. In the case of a “gigs” plugin it might be sorted by date, or by a custom field that holds the date. In essence, you’d need a plugin to shift that section into its own content entry, but the plugin wouldn’t need to introduce any new content models to the database or replicate built-in if_first / if_last / if_different / sorting + filtering tags that already exist in Textpattern, it would just shift them to their own panel.

etc · 2019-12-11 15:02:07

Another possibility is themeless sections. No theme – 404 on access, and it does not depend on permlink scheme. You also could unset ‘live’ theme but set ‘dev’ theme when developing.

Bloke · 2019-12-11 15:07:01

jakob wrote #320456:

I’m not sure about the other ideas like only findable via the sections panel, which would make them hard to find, and not available to all user privilege levels.

Good point re: privilege levels.

some kind of callback in the admin-list panel… to remove them from the regular article list (+ search + next/prev)

You can partially do this already with the admin_criteria callbacks. See the mrd_for_your_eyes_only plugin and adapt as you see fit to return AND Section != 'snippets' from the plugin, which also excludes from searches. Then you can siphon off those articles to your own panel in the same plugin.

Not sure about next/prev on the Write panel. Think that’s automatic.

Bloke · 2019-12-11 15:09:24

etc wrote #320459:

Another possibility is themeless sections.

I like that! This is why we pay you the big bucks ;)

We should bat this idea around and see what the fallout might be. That would likely solve the front-end display side of things.

etc · 2019-12-11 15:14:39

Bloke wrote #320461:

I like that! This is why we pay you the big bucks ;)

I’m worth the double :-)

We should bat this idea around and see what the fallout might be. That would likely solve the front-end display side of things.

I guess some filterAtts() tweaks would be necessary, but that’s all about it front-wise.

jakob · 2019-12-11 15:31:25

Bloke wrote #320460:

You can partially do this already with the admin_criteria callbacks. See the mrd_for_your_eyes_only plugin and adapt as you see fit to return AND Section != 'snippets' from the plugin, which also excludes from searches. Then you can siphon off those articles to your own panel in the same plugin.

Yes, I’ve tried that out before to restrict to only own articles.

Not sure about next/prev on the Write panel. Think that’s automatic.

And the search too. You did show me in another thread – that I can’t find right now – where to add a callback that IIRC was connected to this (and worked).

Those callbacks would also be useful for situations like multi-author sites where people can only edit their own articles, which comes up from time to time in the forum.

etc wrote #320459:

Another possibility is themeless sections. No theme – 404 on access, and it does not depend on permlink scheme. You also could unset ‘live’ theme but set ‘dev’ theme when developing.

Not sure I fully understand this idea of a “themeless section”, but that’s probably just me being slow on the uptake…

Whichever way, this or the no-url scheme variant, seems like something that wouldn’t require major structural changes.

PS: I split this part of the cnk_snippet thread into this new thread. If you have a better idea for the topic title, just say!

Bloke · 2019-12-11 16:08:19

Let’s say, hypothetically it was possible to assign “No theme” to a section. Currently, it’s not possible because there’s no ‘empty’ item in the Theme dropdown when you assign one from the multi-edit or when creating one.

But if that was there, no theme = no pages/forms/styles = no renderable content regardless of what you set the permlink scheme to in the section. It would effectively be ignored so if you visited ‘example.com/snippets/anything-at-all’ you would see a white screen.

If we trapped that scenario and made it 404 instead (or 403: forbidden, or does that leak information?) you could hide articles in one or more sections by simply assigning “no theme” to them.

As Oleg says, with some filterAtts() tweaks, that means it’s not possible to directly – from the URL – access anything assigned to these sections. The only way to display it would be to ‘include’ it from other sections via <txp:article_custom>.

As for the admin-side, you can partially do it already with this plugin:

if (txpinterface == 'admin') {
    register_callback('abc_hide_section', 'admin_criteria', 'list_list');
}

function abc_hide_section($evt, $stp) {
    return " AND Section != 'snippets'";
}

That won’t help you with searches. I’m not entirely sure what the search_criteria callback is for as I haven’t had much luck harnessing it in my tests here. Maybe we should add a callback that allows you to provide the same criteria to append to the search results as you do for the admin_criteria. That might be worth an extra line of code.

Last edited by Bloke (2019-12-11 16:10:57)

etc · 2019-12-11 16:19:09

Bloke wrote #320472:

As Oleg says, with some filterAtts() tweaks, that means it’s not possible to directly – from the URL – access anything assigned to these sections. The only way to display it would be to ‘include’ it from other sections via <txp:article_custom>.

I think we would need another tag (or at least attribute) for this: <txp:article_custom /> uses filterAtts() too. Actually, you wouldn’t like your snippets be accidentally accessed via a tag used for all kind of things.

jakob · 2019-12-11 16:20:03

Bloke wrote #320472:

That won’t help you with searches. I’m not entirely sure what the search_criteria callback is for as I haven’t had much luck harnessing it in my tests here. Maybe we should add a callback that allows you to provide the same criteria to append to the search results as you do for the admin_criteria. That might be worth an extra line of code.

Check this thread. That was the tip you gave me then and it was helpful.

Textpattern CMS

Textpattern CMS support forum

#1 2019-12-11 10:12:09