Is it still alive?

etc · 2022-12-20 17:40:51

franzl wrote #334350:

Static/single sites are possible, yes, but not in the same way like writing an blogarticle.

They are with etc_cache. The same editing workflow, the same url. Most pages of my site are served by apache from disk cache, without even starting the php server, but I edit them as usually.

zero · 2022-12-21 19:59:18

I’m a long time Textpattern user and never learned php and never written a plugin, that stuff does my head in. But I’ve created many websites, often quite complex, and see no need for any other CMS. As a long time internet user, I understand that bells and whistles are usually unnecessary, they may be interesting for a time, but usually they are a distraction.

I’d spend some time explaining to people why bells and whistles are unnecessary and why keeping things simple is the way to go, and then, after they’ve tried it, they’ll know exactly what they want extra, whether it’s bells, whistles or better functionality. It is a fact that clutter affects the brain and peace of mind, so getting into a KISS (keep it simple, stupid) mentality is good for a person and they will learn a good lesson to take with them for the rest of their life.

This Textpattern forum has helped me quite a lot in that respect. I used to think I kept it simple, but many of the folk on here, particularly the coders, really get to the point and think clearly. Which all helps make Textpattern the best CMS around (although I haven’t compared any others in the last few years, ha ha). BTW, I don’t mean to imply that you’re not keeping it simple, franzl, but just pointing out a way of doing things that has run through txp for many years.

Bloke · 2022-12-21 20:30:48

etc wrote #334353:

It should be easy to introduce a trailing_slash pref with possible values like ‘Yes’, ‘No’ and ‘Lists only’ (as presently).

I never realized lack of, or inclusion of, a trailing slash was much of a problem. People pop up occasionally and have strong opinions either way but I thought our balance of slash for listings and no slash for endpoints made sense without introducing more endless configuration options. Textpattern has always been about convention over configuration whenever possible.

That said, if an option to control this makes sense, then let’s put it in. I presume it really only needs to be plumbed into pagelinkurl() et al. I’m slightly concerned that if we introduce an option, it may become useless in certain url schemes (e.g. title only, as you say) and would potentially break the user or SEO experience. At the moment, if you have an article with the same name as a section, there is still disambiguation (uhhh, I think) through the automatic inclusion of the trailing slash.

Bloke · 2022-12-21 20:35:49

etc wrote #334353:

a <txp:meta /> tag. Put in a Page, it will output meta data of the landing article/section.

Isn’t that what meta_description tag does? It can be toggled to either be used in the header or not based on the format attribute, iirc. Or have I missed the point?

etc · 2022-12-21 22:20:38

Bloke wrote #334365:

I presume it really only needs to be plumbed into pagelinkurl() et al.

The most tricky part is pretext(). Recall that each section can have its own URL scheme, which are not clearly distinguishable. So when txp sees /2019/covid/ URL, it has to guess whether to interpret is as id_title or section_title or breadcrumb or something else, without making too many db calls. At least, with our current scheme there is a clear distinction between individual (no slash) and list (slash) article URLs, which helps a lot. But the detection method is tied to the predefined schemes, so this ‘add slash’ request is a good occasion to see whether we can eventually introduce custom ones.

etc · 2022-12-21 22:33:02

Bloke wrote #334366:

Isn’t that what meta_description tag does? It can be toggled to either be used in the header or not based on the format attribute, iirc. Or have I missed the point?

It does, but only for <meta name="description" />. The idea is to introduce a generic txp tag that could generate multiple html <meta /> tags (like robots, etc). The question is how users would define these meta data in a simple way given that their names/values can be arbitrary.

Bloke · 2022-12-22 02:21:14

etc wrote #334369:

The idea is to introduce a generic txp tag that could generate multiple html <meta /> tags (like robots, etc).

Hmmm, yeah, still don’t see the use case here. Even if we could find a friendly way to store arbitrary name-value metadata against, what…: pages, forms, articles, etc? What benefit do we gain from, e.g.:

<head>
<txp:meta type="description" />
<txp:meta type="keywords" />
<txp:meta type="author" />
...

vs:

<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<meta::description />
<meta name="keywords" content="<txp:keywords />">
<meta name="author" content="<txp:author />">
...

Besides being a tiny bit shorter? Guess we could concatenate them to spit out a bunch of things:

<txp:meta type="description, author, keywords" />

But I’m not sure how we could intelligently output meta tags that don’t follow the name/content pattern (such as http-equiv, which can take content-security-policy, content-type, etc).

colak · 2022-12-22 05:51:16

etc wrote #334368:

At least, with our current scheme there is a clear distinction between individual (no slash) and list (slash) article URLs, which helps a lot.

As I mentioned elsewhere, it also makes semantic sense, as the url does not pretend to be hosted in its own directory. A more logical/semantic request would be to give individual articles urls an extension, such as .html.

This is not a request as, for me, the current schemas work just fine.

etc · 2022-12-22 10:00:39

Bloke wrote #334374:

Hmmm, yeah, still don’t see the use case here.

Let us take an example. Our default theme on section pages contains hard-coded

    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no, viewport-fit=cover">
    <meta name="generator" content="Textpattern CMS">
    <meta name="description" content="This is a section.">
    <meta name="robots" content="index, follow">

Now suppose that the site admin wants to exclude certain sections from indexing, via

    <meta name="robots" content="noindex, nofollow">

He can add some conditionals to theme Pages, but this is not very clean. Now suppose that we add a meta field to txp_sections table that admin users can edit (say, in ini format):

robots=noindex, nofollow
keywords=section, might, need, keywords, too
...

Theme authors, instead of hard-coding html <meta /> tags, could use something like

<txp:meta>
charset=utf-8
viewport="width=device-width, initial-scale=1, shrink-to-fit=no, viewport-fit=cover"
generator=Textpattern CMS
robots=index, follow
<conditional txp tags>
...
</conditionals>
</txp:meta>

The tag would then generate a list of <meta />, replacing theme’s values with the section own metas:

    <meta charset="utf-8">
     ...
    <meta name="robots" content="noindex, nofollow">
    <meta name="keywords" content="section, might, need, keywords, too">

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.

Textpattern CMS support forum

#16 2022-12-20 17:40:51

Re: Is it still alive?

franzl wrote #334350:

#17 2022-12-21 19:59:18

Re: Is it still alive?

#18 2022-12-21 20:30:48

Re: Is it still alive?

etc wrote #334353:

#19 2022-12-21 20:35:49

Re: Is it still alive?

etc wrote #334353:

#20 2022-12-21 22:20:38

Re: Is it still alive?

Bloke wrote #334365:

#21 2022-12-21 22:33:02

Re: Is it still alive?

Bloke wrote #334366:

#22 2022-12-22 02:21:14

Re: Is it still alive?

etc wrote #334369:

#23 2022-12-22 05:51:16

Re: Is it still alive?

etc wrote #334368:

#24 2022-12-22 10:00:39

Re: Is it still alive?

Bloke wrote #334374:

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

Board footer