RFC: design out the archive page template in the default theme

etc · 2019-10-13 10:28:50

colak wrote #319690:

I agree with you that it has to do with the urls which is an issue that at some point we need to bring onto the table.

SEO maybe one reason, but more importantly, it has to do with the semantic structure of sites. … good in that system is the flexibility of the url structure which is not as absolute as ours.

AFAIR, we have discussed it many times. IMO, sections are not suited for content organisation, they rather reflect differences in the internal content structure. That will be especially true with upcoming custom-fields branch. It’s ok having a section for “galleries” and another one for “plugins”, since they have different data sets. But separating “dogs” and “cats” via sections looks wrong. Categories fit better here, but they are not mandatory, so we can not provide a general-purpose category/title permlink scheme in core.

Vienuolis · 2019-10-13 11:06:23

colak wrote #319690:

flexibility of the url structure which is not as absolute as ours.

Really? The article URL pattern /title gives me unlimited flexibility: I can specify a /section-category-keywords-author-title-id here, if desired (manually, and maybe via cf or plugin).

etc · 2019-10-14 11:01:27

Actually, section/category1/category2/title and section/path/to/category permlink schemes seem natural, should we implement them?

colak · 2019-10-14 13:14:10

etc wrote #319698:

Actually, section/category1/category2/title and section/path/to/category permlink schemes seem natural, should we implement them?

Hi Oleg

With /category1/category2/, you mean the possible 2 categories of an article or /category/sub-category/...?

Vienuolis · 2019-10-14 14:29:52

colak wrote #319699:

With /category1/category2/, you mean the possible 2 categories of an article or /category/sub-category/...?

In theory, and according to the rules of bibliography, both your variants should mean the same. In Textpattern, Category2 should act as a subcategory of Category1 — hierarchically, like in UDC. For tagging purposes, there are keyword one + keyword two + keyword three.

Edit: sorry, UDK is UDC — Universal Decimal Classification in English language.

Last edited by Vienuolis (2019-10-14 16:18:30)

Bloke · 2019-10-14 14:46:11

As you know, I’m keen to expand our URL schemes and eventually permit (more) customised variants. So anything we can do towards these stepping stones is fine by me.

A few things to bear in mind:

category1/2 will be retired one day in favour of unlimited cats/tags.
we need to phase out the i18n /kategorie etc URLs and replace them with known hooks in English. It was an interesting experiment but ultimately pretty useless, especially with browser manufacturers jumping over one another to (annoyingly) try and remove the URL entirely from the user experience, relying on search engines to fill the void for the lazy.
Anything we introduce now needs to remain supported even when the above points are eventually implemented, until enough time has passed that we can remove them completely.

etc · 2019-10-14 15:58:11

I see it like this:

if no category is set, URL is just section/title.
if category1, category2, category3 etc are on the same category path (in this order), that would be section/category1/category2/category3/title or section/full/path/to/category3/title, to decide.
otherwise, it’s tricky, but we could imagine section/category1+category2+category3/title or even

section/the/longest/common/path/of/category1+category2+category3/title

And I tend to agree with @Vienuolis, article categories should respect the categories hierarchy, in which case the third point is not a problem.

Bloke · 2019-10-14 16:11:45

etc wrote #319703:

article categories should respect the categories hierarchy

I like this – and it could be rolled out to all content types when we get unlimited cats/tags across the board.

The original plan was just for freeform tagging and to allow for filtering via the URL using AND/OR combos (like smd_tags but better). But if we also permit these unlimited cats/tags to be reordered – via drag/drop/whatever – then they not only act as ways to find/filter content but can also be used to set the ‘priority’ or ‘importance’ of those tags by making them higher up the list, and thus offer some form of continuity for creating the type of URLs you mention when we migrate to tags.

etc · 2019-10-14 16:15:37

Bloke wrote #319704:

… when we migrate to tags.

I hope we don’t drop categories – I fear BC issues with <txp:category_list /> and other tags.

Bloke · 2019-10-14 16:21:12

Didn’t I send you the plan doc? If not, let me know and I’ll share it.

The plan was to run them side by side. A clean break. So existing sites just carry on working, but on upgrade all current cats are “copied” to the tag table so the new suite of <txp:> tags that accompany them are available out of the box for anyone who wants to swap out their <txp:category...> tags and start to use them.

etc · 2019-10-14 19:44:31

Bloke wrote #319708:

Didn’t I send you the plan doc? If not, let me know and I’ll share it.

Ah, you did, sorry, but I had a poor internet connexion at that moment. Will read now.

Anyway, a commit is in dev now, it works along these lines, testers welcome.

A related question is the search by category. Suppose we have a category tree like

animals
|- mammals
|  |- cats
|  |- dogs
...

If a Garfield article is categorized as cats and we are searching for animals, should Garfield be returned too? This would mean that we don’t really need to associate two different categories on the same path to an article.

Algaris · 2019-10-15 09:00:26

Bloke wrote #319701:

category1/2 will be retired one day in favour of unlimited cats/tags.

Whoop! Whoop! This makes me very happy as I’m always banging my head against the two category limit.

colak · 2019-10-20 08:09:59

etc wrote #319712:

A related question is the search by category. Suppose we have a category tree like

animals...

If a Garfield article is categorized as cats and we are searching for animals, should Garfield be returned too? This would mean that we don’t really need to associate two different categories on the same path to an article.

I’m returning to respond to this one. I guess that it depends on the templates. I’m all for a deeper classification. Consider /animals/mammals/cats/etc/.

/animals/ could only return a category list of animals. ie Mammals, Actinopterygii, Chondrichthyes, Birds, Amphibians, Reptiles.

/mammals/ could return cats, dogs, elephants, etc

clicking on cats could take us to Lions, Tigers, domestic cats, etc

domestic cats could return Siamese, Sphynx, Burmese, etc

From there on, we can have a list of available Siamese cats in individual articles.

I am aware that google no longer cares for this kind of taxonomies in their results but they are useful nevertheless in structural and usability terms.

If sections will eventually be totally divorced from the url structures, we have to discuss other ways to create semantically correct taxonomies within sites using clean urls.

The one thing I have a problem with the above is some of the real world cases. ie. a list of articles by an author (not in the txp sense but maybe using custom_field) who contributed both in the cats and dogs taxonomy. This is of course possible using the current txp releases but the issue here is that part of the page content breaks the actual taxonomic division.

I realise that the issues I am raising may require radical changes in txp but it will also make it even more flexible.

etc · 2019-10-20 09:05:58

colak wrote #319788:

Consider /animals/mammals/cats/etc/.

/animals/ could only return a category list of animals. ie Mammals, Actinopterygii, Chondrichthyes, Birds, Amphibians, Reptiles.

/mammals/ could return cats, dogs, elephants, etc

clicking on cats could take us to Lions, Tigers, domestic cats, etc

domestic cats could return Siamese, Sphynx, Burmese, etc

From there on, we can have a list of available Siamese cats in individual articles.

That’s already done in dev via a new <txp:article depth /> attribute (name to debate). By default, landing on animals/ returns animals. But if you set depth="1" you’ll get its children (mammals etc). If you wish, you can bound depth between two values: depth="0-2" will give you animals with its children and grandchildren. Valueless depth matches all descendants of animals.

If sections will eventually be totally divorced from the url structures, we have to discuss other ways to create semantically correct taxonomies within sites using clean urls.

Currently all clean modes recognize /section/title urls, it would be difficult to remove for legacy reasons.

The one thing I have a problem with the above is some of the real world cases. ie. a list of articles by an author (not in the txp sense but maybe using custom_field) who contributed both in the cats and dogs taxonomy. This is of course possible using the current txp releases but the issue here is that part of the page content breaks the actual taxonomic division.

Not sure to understand you: would this do?

<txp:article_custom my_author="darwin" category="cats, dogs" />

colak · 2019-10-20 16:58:44

etc wrote #319789:

That’s already done in dev via a new <txp:article depth /> attribute (name to debate). By default, landing on animals/ returns animals. But if you set depth="1" you’ll get its children (mammals etc). If you wish, you can bound depth between two values: depth="0-2" will give you animals with its children and grandchildren. Valueless depth matches all descendants of animals.

Will this be reflected in the URL structure?

Currently all clean modes recognize /section/title urls, it would be difficult to remove for legacy reasons.

I agree. I’m just trying to think way ahead!

Not sure to understand you: would this do?

<txp:article_custom my_author="darwin" category="cats, dogs" />...

Indeed it works. I was thinking too strictly regarding what an article page should contain rather than txp’s possibilities.

Textpattern CMS support forum

#16 2019-10-13 10:28:50

Re: RFC: design out the archive page template in the default theme

colak wrote #319690:

#17 2019-10-13 11:06:23

Re: RFC: design out the archive page template in the default theme

colak wrote #319690:

#18 2019-10-14 11:01:27

Re: RFC: design out the archive page template in the default theme

#19 2019-10-14 13:14:10

Re: RFC: design out the archive page template in the default theme

etc wrote #319698:

#20 2019-10-14 14:29:52

Re: RFC: design out the archive page template in the default theme

colak wrote #319699:

#21 2019-10-14 14:46:11

Re: RFC: design out the archive page template in the default theme

#22 2019-10-14 15:58:11

Re: RFC: design out the archive page template in the default theme

#23 2019-10-14 16:11:45

Re: RFC: design out the archive page template in the default theme

etc wrote #319703:

#24 2019-10-14 16:15:37

Re: RFC: design out the archive page template in the default theme

Bloke wrote #319704:

#25 2019-10-14 16:21:12

Re: RFC: design out the archive page template in the default theme

#26 2019-10-14 19:44:31

Re: RFC: design out the archive page template in the default theme

Bloke wrote #319708:

#27 2019-10-15 09:00:26

Re: RFC: design out the archive page template in the default theme

Bloke wrote #319701:

#28 2019-10-20 08:09:59

Re: RFC: design out the archive page template in the default theme

etc wrote #319712:

#29 2019-10-20 09:05:58

Re: RFC: design out the archive page template in the default theme

colak wrote #319788:

#30 2019-10-20 16:58:44

Re: RFC: design out the archive page template in the default theme

etc wrote #319789:

Board footer