Theme four-point-nine

giz · 2026-01-02 20:33:50

The default theme for 4.9 needed updating to reflect the new image generation system, so I thought I’d give it a go.

My approach is one-size-fits-all, and provides a range of sizes for the browser to choose from (it uses sizes="auto").

A bunch of template suggestions followed:

Pages and Forms

The default and archive pages are somewhat daunting or complex for newbies, so I simplified them by creating 2 new forms (misc/head.txp and misc/pagination.txp). This reduced the pages considerably, but there is still more that can be done eg. the <body> tag variants are a candidate for another form. Is <txp:if_author> et.al used enough to warrant so many lines throughout the default templates? I’d like to see a peppering of some of the more recent/useful tags and attributes e.g. <txp:yield />. Maybe we could treat default.txp as only-the-basics, with archive.txp as the page with bells and whistles?

I added an image capability to article_listing.txp, and made minor formatting changes throughout – typically using wraptag="foo" to replace surrounding tags where possible to reduce the line count, and moving html comments so that they are within a <txp:if_etc> tag so they display if required.

Style

The css in the four-point-nine install is compressed, making it difficult to edit. I’m recommending new styling which still presents the site as a wireframe, but allows the user to control aspects via css variables at the top of the file, or dig deeper to make changes to components etc. lower down.

jakob · 2026-01-02 21:54:25

Happy New Year Gary! You’re making a good start already! Just a brief answer for now as I’m short on time. I’ve only taken a quick look at your commits for now but I like your general approach. Things like excerpting css variables I think are a great idea. Users can then add own stylesheets in the presentations tab and set their own css variables or add extra css, potentially transforming the basic framework (4.9 adds some other ways of bringing in css from Textpattern’s styles panel as inline content). I see various other simplifications in your commits, and some more segmentation into forms, which I agree aids readability. Ditto wraptag to avoid if_conditionals.

A more general aspect: as informative as schema.org structured data can be, I find it clouds the readability of the demo theme, even to the point of causing roundabout constructions that would not be necessary if one didn’t have to cater for the extra attributes. I absolutely see its purpose for complex sites and markup patterns that html does not already cater for, or for types of site with particular content patterns (and then arguably the json-ld method could end up being more concise), but the demo theme is not that complex in terms of content and my personal feeling is that search machines aren’t going to have difficulties processing the demo site. In short, the principle is great, but how much extra search-machine clarity does it actually bring in this demo case? Maybe this is just a gripe of mine?

For example:

<p itemprop="image" itemscope itemtype="https://schema.org/ImageObject">
    <txp:variable name="img-tag" />
</p>

denotes that it is an image?! … which the img tag already does on its own. Also, is it still important to differentiate between images with and without a caption? MDN suggests not, expressly calling figure a figure with optional caption element and shows a Just an image example. The validator doesn’t seem to complain, either, if a figcaption is not included.

Might there also be a less nested way of handling the multiple if_… situations? I suppose it does demonstrate the conditional tags, but even with experience, I have to read it carefully to follow. Oleg showedan alternative pattern. If I have site that needs this more than once, I do the nesting dance once and define a page_context variable that can I use in the rest of the templates.

Overall nice ideas in there. I imagine the toned-down styling will be polarising, but I like it. Maybe some style variants would illustrate the potential of the css custom properties?

When I have more time, I’ll give it a proper tryout.

Bloke · 2026-01-02 22:29:57

Fab start! The default theme defintely needs some consolidation, and I love the idea of using CSS variables to show off the customisation opportunities. And yeah, auto thumbs…

Currently, sadly, the thumbnail tags need height="0" to prevent them automatically creating weirdly tall images (without CSS to tame them) but I’m hoping this can be addressed in a few weeks in a maintenance release 4.9.1 to also catch a few stray edge case bugs. Hopefully I can get my head round a way to retain the thumbnail tag’s broadly backwards-compatible nature (which it is now) but also less wordy (which it certainly isn’t now).

So if we can iterate this idea for the default theme, I’m all for including it in 4.9.1.

The microformats do seem over the top. Not just in our theme, but in general. schema.org is way way waaaay too prescriptive and, as Jools says, a lot of it is completely unnecessary if using descriptive HTML5 tags. I’d love to hack some of it out. Yes, keep the “BlogPosting” stuff perhaps because div and section tags need a little hinting. But definitely slim it down.

I would actually like to take this opportunity to showcase the tag processing order – although I’m not sure how intuitive it is in a default theme – to actually ditch the wordy inline microformats and use JSON-LD. There’s a whole discussion on it and the consensus seems to be that the JSON-LD structure can be built by peppering <txp:variable name="json-ld" add> containers (see Jools’ comment and my reply) throughout the template and then using <txp:variable[-1] name="json-ld" /> to output the entire structure in the <head> tag, utilising secondpass to add it after the variable has been constructed (even though it is output before them all in the source code). It’s clever and shows off how powerful the tag processor is, and also simplifies the template.

Thoughts on this welcome. But yes, definitely a fantastic step up. Thank you, Gary (and Happy New Year).

giz · 2026-01-03 16:30:36

(HNY :)

Thanks!

I need to first grok/experiment-with the logic of the alternative and Jool’s comment approaches — I’ve never understood (and have consequently shied away from) the ‘shift’ attribute. In the past my method of determining whether it’s the homepage has been <txp:if_section name=", default">. Tag-processing-order is also new to me ;-)

I too dislike the clutter and redundancy of much microdata. I’ll attempt a cleanup, lowest hanging fruit first… Maybe we should change it from “BlogPosting” to “Article”.

Bloke · 2026-01-03 16:35:39

I still use <txp:if_section name=""> to check for front-page, so you’re not alone.

And sure, if Article makes more sense as a microformat type, then that’s cool with me.

giz · 2026-01-03 19:25:36

Updated images.txp

<figure>
    <img srcset="<txp:image_url thumbnail width="320" /> 320w,
            <txp:image_url thumbnail width="640" /> 640w,
            <txp:image_url thumbnail width="1280" /> 1280w,
            <txp:image_url thumbnail width="2560" /> 2560w"
        sizes="auto"
        width="<txp:image_info type="w" />"
        height="<txp:image_info type="h" />"
        loading="lazy"
        alt="<txp:image_info type='alt' default='<txp:image_info type='name' />' />"
    />
    <txp:if_individual_article>
        <txp:evaluate>
            <figcaption itemprop="caption">
                <!-- image_info without a type attribute outputs the caption -->
                <txp:image_info escape="textile"/>
            </figcaption>
        </txp:evaluate>
    </txp:if_individual_article>
</figure>

I removed the microdata (including the <meta height/width lines – redundant as we’re specifying the width and height in the <img> tag itself – recommended to prevent CLS). The fallback for the alt description is now the image name.

I’m unsure about the ::if_individual_article tag, but I’ve regularly found the need to omit captions on landing pages.

As images are such an integral part of a modern website, would it be worth while abstracting it all into a <txp::images /> (or <txp::figure />) shortcode so some yield functionality can be exposed? Scope-creep? Maybe just use an evaluate block on the caption?

JSON_LD scripts can be placed in the head or body, so they could be included here directly or as a shortcode within a <txp:hide> block. Showcasing another tag :)

Last edited by giz (2026-01-03 19:39:09)

Textpattern CMS

Textpattern CMS support forum

#1 2026-01-02 20:33:50