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

gaekwad · 2019-10-11 13:55:50

For as long as I can remember, there’s been an archive page template, and I’ve never really understood what it’s for in real terms. I understand that older posts use it, but is there scope to make the Textpattern onboarding process a little easier and rework the default template to cover current and older articles?

I rarely see any presentational difference between posts using the default page and the archive page, so are we (OK, “is Phil”, more like) maintaining something that doesn’t need to be maintained? I’m genuinely interested in different points of view here, your advice and feedback is warmly welcomed. Thanks!

etc · 2019-10-11 13:59:00

IMO, it’s there mainly to show how one can use different pages for different sections, but personally I wouldn’t miss it.

Bloke · 2019-10-11 14:07:50

Yeah, it’s purely for showcasing multiple Pages. Plus, the default Page can get unwieldy with conditionals because it already handles author lists, category lists, search results and so forth.

I like that it’s there so it offers a nice separation between “front page” content and “regular article” content, even if a lot of the presentational elements are the same and handled by Forms. archive is a stupid name for it though. If we can come up with something better, that suits me.

bici · 2019-10-11 16:23:35

etc wrote #319653:

IMO, it’s there mainly to show how one can use different pages for different sections, but personally I wouldn’t miss it.

hmmm. As i recall the reason for “archive’ page template was because in the Blog era it was a model used by a few CMSes. The idea was that it was simple to have a 1-4 ( or whatever) output of articles on the main page. From there one used << previous/next >> links to view more articles and one could in theory click through to the first. But by having an archive link all articles were collected therein on that page, by year. I don’t think we should not throw it out.

And archive is a perfectly good name for what it does…. it collects all past articles into the “archive”.

Data archiving is the process of moving data that is no longer actively used to a separate storage device for long-term retention. Archive data consists of older data that remains important to the organization or must be retained for future reference

or have i misunderstood the issue?

Bloke · 2019-10-11 17:51:26

bici wrote #319668:

archive is a perfectly good name for what it does…. it collects all past articles into the “archive”.

I suppose it makes sense when looked at from that perspective, yeah.

Maybe it’s just my use case over the years that differs from this classical blog viewpoint. I tend to use default as the dogs’ body catch-all for specialist landing pages and “front page” content, then the archive Page for article content, like individual articles, landing page for article lists or groups that aren’t necessarily most recent. But it may show any article, not just those that have ‘dropped off’ the front page so it’s not necessarily an archive in my case; it’s just a way of displaying individual article content, wherever that may be in the site.

It’s rare I have more than three Pages: default, main and error.

etc · 2019-10-11 20:34:15

bici wrote #319668:

And archive is a perfectly good name for what it does…. it collects all past articles into the “archive”.

I’m fine with “archive” name and functionality, it’s just annoying to modify two (plus error_default) mostly identical pages when you need to change their layout.

Bloke · 2019-10-11 20:50:05

etc wrote #319671:

it’s just annoying to modify two (plus error_default) mostly identical pages when you need to change their layout.

Yeah, it can be annoying depending how things are set up. Offloading the inner furniture to Forms is where big wins can be made here, leaving the Pages to handle just the main HTML scaffolding (html, head, body and some section/div tags) plus conditionals for interpreting various URL patterns.

Then all the inner content and finer conditionals can be handled by one or two Forms across all Pages (maybe one for landing pages, one for individual articles, or even just a single Form with conditional).

I also tend to offload my <head> content to a set of Forms so various chunks can be brought in depending on what’s going on in the URL. Same with the navigation block.

If your default and archive Pages are broadly similar, I’d just go with a single asset. The only real reason to use a different Page is if the layout is significantly different. Like, if the front page is a bunch of flexboxes with article + headline images aligned alternately left/right, whereas your main article content or section landing pages are more linear.

Failing that, if this is a real problem in design circles… well, Page inheritance anyone? :P

etc · 2019-10-11 21:02:13

Bloke wrote #319674:

Page inheritance anyone? :P

I’ve finished there.

gaekwad · 2019-10-11 21:06:48

Bloke wrote #319674:

Failing that, if this is a real problem in design circles…

For me, it’s not a problem for Textpattern experts, they understand the semantics and architecture of the CMS and theme well enough, it just seems a bit unnecessary for a newbie who might choose to stick with the default theme as they work their way around and learn the ropes. The archive page isn’t vastly different to the default…so my thought train was whether it’s counter-productive to install this two-page approach for what is — visually, at least — almost the same thing.

In my experience a new user is much more likely to remove the default article first, which also takes care of Donald’s comment, mostly remove the Textpattern links, and sometimes shred the various categories. The standard issue pages and forms are left largely alone if the user is OK with the theme…and it’s a great default theme overall. Those people (again, in my experience) who search for Textpattern themes to replace the default theme DIY-style are sometimes a bit underwhelmed and stick with the default theme because it’s suitable for a lot of use cases. Obviously those with designers can farm out the work to them, but immediate themes availability is another issue.

I think my point is to examine what’s included with the default set of stuff, bearing in mind what happens to it after installation, and whether having archive and default do largely similar things is sending the wrong message. One route might be to make it look different enough that it’s obvious, but the default theme looks just fine as it is.

etc · 2019-10-11 21:33:36

gaekwad wrote #319677:

having archive and default do largely similar things is sending the wrong message.

Having seen users create a page per section and/or even a section per article, I’m inclined to agree with you.

Bloke · 2019-10-11 21:38:43

gaekwad wrote #319677:

having archive and default do largely similar things is sending the wrong message.

Agree. We could work towards either make them obviously different enough that the penny drops faster, or go with one. I’m fine with either approach.

The trouble with only having one article is that it looks that there’s a direct one-to-one link between Page and Article. The trouble with having more articles is that there’s more to delete.

Last edited by Bloke (2019-10-11 21:39:59)

gaekwad · 2019-10-12 06:40:03

Bloke wrote #319679:

The trouble with only having one article is that it looks that there’s a direct one-to-one link between Page and Article. The trouble with having more articles is that there’s more to delete.

One article is fine. The content of it might need fresh eyes, and the docs site can be used more liberally as a destination, rather than trying to shoehorn more info into a single article where everything is new. Information density is key, I think, and learning styles for people are different. I’ll ponder for a while, there may not be a solution, especially if there’s no problem to solve.

Textpattern CMS

Textpattern CMS support forum

#1 2019-10-11 13:55:50