Text asset naming scheme best practice & form wildcards

gaekwad · 2025-09-02 11:46:47

Two questions, one thread.

What’s considered ‘safe’ best practice for separators & prefixes when naming forms, styles & pages?

I’m building a new site from scratch and I can define the namespace for text assets. I’m not particularly set on one route over another, but I’d like to future-proof the naming scheme so I don’t have to make emergency remedial changes when an upgrade happens. I have vague memories of a textpattern.org explosion years ago when a Textpattern upgrade happened as some forms were prefixed with ., _ and other exotic symbols.

I have become accustomed to prefixing text assets with numbers to act as a natural sorting mechanism, like so:

1000-head
1010-main
1020-aside
1030-info
1040-footer

…and so on. Are there any gotchas from a database point of view that prefixing with numbers would cause problems? I ask because some (most? all?) versions of MySQL don’t allow database names to begin with a number.

I also understand that _ can represent a wildcard in some (most? all?) versions of MySQL, so I’m using - as a separator. Is there an objectively better character that’s safer to use?

This leads me to the second part of my call today…

Can I output multiple forms with a wildcard syntax?

Taking the above example, can I use <txp:output_form /> to export all forms beginning with 10? In other words, can the form attribute be used with a wildcard?

Bloke · 2025-09-02 12:22:07

For the first part, stick with alphanumeric, underscore and hyphen for best compatibility and least future headaches. BUT if you want to use any Forms as shortcodes then you MUST use underscore. As far as I recall (unless we’ve changed it in 4.9.0) hyphenated form names don’t work as shortcodes.

Secondly, I’m pretty sure you can comma-separate list forms in the form attribute but I don’t think it supports wildcards. We can certainly pass a list of forms into our parse_form() but I can’t recall if that’s extended to the front side tag.

I’ve not tried this but you may be able to use a variable to build a list of form names you want by tricking another tag/plugin (such as rah_repeat) into expanding wildcards and then plugging that into the form attribute. YMMV.

gaekwad · 2025-09-02 12:24:21

Bloke wrote #340375:

For the first part, stick with alphanumeric, underscore and hyphen for best compatibility and least future headaches. BUT if you want to use any Forms as shortcodes then you MUST use underscore. As far as I recall (unless we’ve changed it in 4.9.0) hyphenated form names don’t work as shortcodes.

Thank you. Alphanumeric + underscore separators it is, then!

Secondly, I’m pretty sure you can comma-separate list forms in the form attribute but I don’t think it supports wildcards.

Thank you. I had a feeling this was the case, I’ll stick with the vanilla (listing) approach rather than witchcraft for now.

Last edited by gaekwad (2025-09-02 20:19:14)

etc · 2025-09-02 17:25:04

Txp 4.9 is much more permissive re tag names, so you can name you form 11-joy😀 and call <txp::11-joy😀 /> if you wish.

Wildcarding is tricky bwc-wise. SQL wildcard symbols % and _ can be used in form names, so form="10%" can not be handled as ‘all forms starting with 10’. But, say, * and ? are forbidden in form names and hence available as wildcards, so we could implement something if necessary.

Bloke · 2025-09-02 17:27:10

Nice. Couldn’t remember if you’d lifted the restriction re: naming. That’s fab.

etc · 2025-09-02 17:40:54

For the background. Most symbols valid in XML names should be also valid in txp tag/attribute/shortcode names in 4.9.

Bloke · 2025-09-02 18:25:46

Thanks. I don’t even remember contributing to that discussion! Jeez, my memory.

gaekwad · 2025-09-02 18:55:38

etc wrote #340379:

Txp 4.9 is much more permissive re tag names, so you can name you form 11-joy😀 and call <txp::11-joy😀 /> if you wish.

Wildcarding is tricky bwc-wise. SQL wildcard symbols % and _ can be used in form names, so form="10%" can not be handled as ‘all forms starting with 10’. But, say, * and ? are forbidden in form names and hence available as wildcards, so we could implement something if necessary.

Thank you, etc – I appreciate the clarification.

jakob · 2025-09-02 20:49:00

gaekwad wrote #340374:

I have become accustomed to prefixing text assets with numbers to act as a natural sorting mechanism, like so:

1000-head...

…and so on.

I definitely like the visual order that brings to the list of form names, but it feels strange to me writing the numbers in the form="1234_form_name" attribute. There’s no reason why you shouldn’t, but I’m forever forgetting which number belongs with which form (I have the same problem with the German SKR classification codes for accounting expenses).

My approach is to try to adopt a “reasonably similar” naming scheme so that forms that belong together also appear together in the list, e.g. site_…, page_…, article_…, event_…, and so on. I try and use the same / similar names for my (S)CSS files (where sensible), so that they roughly correspond, making it easier to find where to find the corresponding styles. Of course, if you’re using Tailwind, such things are irrelevant.

Bloke · 2025-09-02 22:22:40

You can also make your own Form groups. Just add them to Advanced Prefs. E.g.

[shortcodes]
title="Shortcodes"
[sitestuff]
title="Page elements"

And house your Forms under relevant groups. Then you can do away with the prefixes as you can twist down the group to find all the related assets.

Within the group, sure, name them with number prefixes or letters or clever names that happen to be alphabetical:

base
bodytext
incidental
info
tail

gaekwad · Yesterday 09:08:39

jakob wrote #340386:

I definitely like the visual order that brings to the list of form names, but it feels strange to me writing the numbers in the form="1234_form_name" attribute. There’s no reason why you shouldn’t, but I’m forever forgetting which number belongs with which form (I have the same problem with the German SKR classification codes for accounting expenses).

There is some vague method to my madness here, albeit it’s a stretch. I’ll have a go at explaining…questions are welcome.

I was trying to order as many forms as possible to their position on the page / content that has been generated. For example:

0 prefix forms are location-agnostic.
1 prefix forms are pre-@<html>@ (e.g. Textpattern pre-flight stuff).
2 prefix forms are <head>.
3 prefix forms are <header>.
4 prefix forms are <nav>.
5 prefix forms are <section>.
6 prefix forms are <article>.
7 prefix forms are <aside>.
8 prefix forms are <footer>.
9 prefix forms are post-@<footer>.

The numeric prefix can be expanded to have more granularity, so 1 can be 10 to 19, etc. As is my way, I’m coming from a background of doing this a bunch elsewhere, so I’m trying to apply some logic without taking to an absurd level.

Speaking of which, the server build guide I have follows a similar numeric prefix, but the granularity of that needs a waaaaay longer prefix to keep things in order. For example, if I need to check the Base64-encoded version of undefined-server.conf, which is an Nginx config file to minimise drive-by tomfoolery, I need to check this directory for the Linux version:

1000-0000-0000-0000-0000 linux/
  1040-0000-0000-0000-0000 web/
    1043-0000-0000-0000-0000 httpd/
      1043-3000-0000-0000-0000 nginx and forks/
        1043-3300-0000-0000-0000 nginx/
          1043-3330-0000-0000-0000 source/
            1043-3330-2000-0000-0000 scaffold/
              1043-3330-2070-0000-0000 deny/
                1043-3330-2070-3000-0000 files/
                  1043-3330-2070-3700-0000 source/
                    1043-3330-2070-3700-7000 undefined.server.conf/

The filename is 1043-3330-2070-3700-7700 base64.md. Which is absurd. But it works, so I’m alright with it!

My approach is to try to adopt a “reasonably similar” naming scheme so that forms that belong together also appear together in the list, e.g. site_…, page_…, article_…, event_…, and so on. I try and use the same / similar names for my (S)CSS files (where sensible), so that they roughly correspond, making it easier to find where to find the corresponding styles. Of course, if you’re using Tailwind, such things are irrelevant.

This is pretty much how I’ve done it until now, but a new project (first in a long time, admittedly, so I’m rusty) has me sanity-checking a lot of stuff for current best practices.

Thank you, jakob – insightful as always!

gaekwad · Yesterday 09:10:41

Bloke wrote #340390:

You can also make your own Form groups. Just add them to Advanced Prefs. E.g.

[shortcodes]...

And house your Forms under relevant groups. Then you can do away with the prefixes as you can twist down the group to find all the related assets.

I hadn’t even considered that – thank you!

Textpattern CMS

Textpattern CMS support forum

#1 2025-09-02 11:46:47