Is it still alive?

Bloke · 2022-12-22 10:39:09

Sure if it makes it simpler and incurs less maintenance overhead it’d be a nice addition. I certainly use a conditional if_section tag to include or exclude stuff I don’t want indexed or to do special things with certain sections. I guess not having to do that would be useful so if there’s a way to do this fairly cleanly and logically then great. Might be fun with the syntax for http-equiv but it’s probably doable.

etc · 2022-12-22 10:59:19

Bloke wrote #334389:

Might be fun with the syntax for http-equiv but it’s probably doable.

We could use ini sections:

[name]
generator=Textpattern CMS
...
[http-equiv]
refresh=30
...

Or JSON format, or whatever. But this should be easy for non-techy end-users, and that’s the tough part.

jakob · 2022-12-22 11:48:15

I currently do varying meta tags, or similar content that needs to be user-definable (e.g. google search console ID), in different ways:

Either an if_section statement in the head form where there is little variation in a site …
Or I create a site-wide variable that’s loaded at the top of the page that holds a comma-separated list of noindex_sections. I often find it easier to simply list the sections that need dealing with differently in one place. I use an own variant of the oui_prefs plugin to make them user-editable as a “Site variables” block on the Admin pane.
Or I use jcr_section_custom to add a custom field to the section holding that kind of data. If the upcoming custom fields can also be added to sections in a similar way (even better as a toggle rather than a text field as my plugin does), then devs could make their own user-editable toggles as desired. Problem solved IMO.

A freeform entry field with some form of structured input like you suggest would make that more extensible without adding innumerable toggle switches endlessly catching up with new meta data. But end users will still need to observe and correctly enter a particular syntax when using ini and json formats. It’s almost as much as simply writing out the HTML tags. The benefit is that it limits what end users can add to the page head.

I don’t see any benefit in providing a meta tag to write out a regular HTML meta tag with fixed site-wide content. That doesn’t need to be user-editable, and one can write it simply as HTML.

Making such settings for individual pages requires a custom_field… Again, if the future custom fields branch allows one to add different CF types – toggle-switch, drop-down – (and possibly also to position them in a particular place on the write pane) that would also address that need without needing a specially developed tag.

Bloke · 2022-12-22 11:52:36

Ini format is more intuitive imo. Also easier from a special character viewpoint as stuff doesn’t need escaping inside quotes.

But as Jakob says, rolling your own html tags with a conditional is not much more onerous than specifying everything in sections and having a single tag spit it all out. So we’d need decent use cases or productivity/convenience benefit to justify doing it.

Last edited by Bloke (2022-12-22 11:57:57)

etc · 2022-12-22 12:09:07

Bloke wrote #334397:

rolling your own html tags with a conditional is not much more onerous than specifying everything in sections and having a single tag spit it all out.

Not from site designers perspective, but for end users it means mixing content and presentation. Each time you need a new meta (content), you have to modify some Form/Page (presentation).

Bloke · 2022-12-22 12:09:16

P.S. custom fields are planned for sections. The only sticking point is that pages and sections, iirc, don’t have a numeric ID field and the custom fields table mandates it. So we’ll need to tweak the tables to cater for it.

Bloke · 2022-12-22 12:09:58

etc wrote #334399:

Not from site designers perspective, but for end users it means mixing content and presentation. Each time you need a new meta (content), you have to modify some Form/Page (presentation).

True dat.

franzl · 2023-01-05 17:50:09

I want to close it.
Thanks to all.

Textpattern CMS

Textpattern CMS support forum

#25 2022-12-22 10:39:09

Re: Is it still alive?

#26 2022-12-22 10:59:19

Re: Is it still alive?

Bloke wrote #334389:

#27 2022-12-22 11:48:15

Re: Is it still alive?

#28 2022-12-22 11:52:36

Re: Is it still alive?

#29 2022-12-22 12:09:07

Re: Is it still alive?

Bloke wrote #334397:

#30 2022-12-22 12:09:16

Re: Is it still alive?

#31 2022-12-22 12:09:58

Re: Is it still alive?

etc wrote #334399:

#32 2023-01-05 17:50:09

Re: Is it still alive?

Board footer