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

Bloke · 2019-10-12 10:02:29

gaekwad wrote #319683:

One article is fine. The content of it might need fresh eyes

Yeah. If nothing else, this is a good goal.

I was just thinking back to what Oleg said about people making one Page per article and it’s something I’ve seen too on sites. So if there’s a way to break that implied link – either through documentation within the Page assets or in the welcome article through cleverly extracting bits of our orientation “bird’s eye view” doc – then that’d be cool too.

etc · 2019-10-12 10:23:49

Bloke wrote #319684:

people making one Page per article and it’s something I’ve seen too on sites.

I think people often create sections for tagging or SEO purpose, since it’s the easiest way to have clean informative URLs. That’s not really what sections are designed for, but why not. The problem is that the default setup suggests one needs a page per section, and there it becomes a mess. We really should put a huge bold YOU DON’T NEED A PAGE PER SECTION somewhere.

colak · 2019-10-13 08:18:10

etc wrote #319685:

I think people often create sections for tagging or SEO purpose, since it’s the easiest way to have clean informative URLs. That’s not really what sections are designed for, but why not. The problem is that the default setup suggests one needs a page per section, and there it becomes a mess. We really should put a huge bold YOU DON’T NEED A PAGE PER SECTION somewhere.

I’m guilty re this, for certain pages and 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. I have only used WP once in a c collaborative project that I was not the main person responsible for the site and the only thing that I found good in that system is the flexibility of the url structure which is not as absolute as ours.

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.

Textpattern CMS

Textpattern CMS support forum

#13 2019-10-12 10:02:29

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

gaekwad wrote #319683:

#14 2019-10-12 10:23:49

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

Bloke wrote #319684:

#15 2019-10-13 08:18:10

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

etc wrote #319685:

#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:

Board footer