Is it still alive?

franzl · 2022-12-20 15:14:07

Yes, I get your point. Of course it´s possible. Maybe you dont get my point. As an Dev. I´m able to create my own routing system, comment function… No problem, but that is exacly what I dont want. If I would do it on my own, I would leave Textpattern. A system created on my very own gives me freedom in every way, thats true. But I dont want to work on a system. I want to use it, yes, like an user without any idea of programming. That´s why I wrote “for the user´s”.

Even if I recommend Textpatter to other guys, I have to look that these guys are able to work with php to get a propper site. Otherwise I have to do the support. What is the result? I have to recommend WordPress. Even though to know Textpatter is the better cms. WordPress is totally overdozed to have a simple blog. And thats the point. Textpattern is quite a bit hard for people without programmingknowledge. I´ve tried to recommend Textpattern to other guys. I create theier themes and the first arcticles. I´m from germany and in my country there are a lot of laws to protect the privacy. It is complicate to setup Textpattern in a propper way. Static/single sites are possible, yes, but not in the same way like writing an blogarticle.

I hope you get the point. :-)

colak · 2022-12-20 16:53:34

franzl wrote #334350:

Even if I recommend Textpatter to other guys, I have to look that these guys are able to work with php to get a propper site. Otherwise I have to do the support. What is the result? I have to recommend WordPress. Even though to know Textpatter is the better cms. WordPress is totally overdozed to have a simple blog. And thats the point. Textpattern is quite a bit hard for people without programmingknowledge. I´ve tried to recommend Textpattern to other guys. I create theier themes and the first arcticles. I´m from germany and in my country there are a lot of laws to protect the privacy. It is complicate to setup Textpattern in a propper way. Static/single sites are possible, yes, but not in the same way like writing an blogarticle.

I hope you get the point. :-)

I’m respectfully not sure that I agree. The issue though, has nothing to do with the users having to learn php, but, as etc has already mentioned, with the excellent but very few design templates we offer.

Out of the box, wordpress looks terrible, and no one can do a custom design, or site structure, without knowing php. In txp, we can do it, with basic knowledge of how html tags work, and css. I’ve been an avid txp user for just over 18 years, and I have (ashamedly) never learned php. Txp is directed for designers and their clients. It was never directed for programmers. Much of the click hell you mention in WP was programmed, both by its developers and the designers. In txp, we seldom need to think that we need to programme, but many think of how to design for content.

Regarding privacy, do check Nicolas Morand’s oui_cookie if you need to use content from other sites that serve it with cookies. We are using the plugin and have recently had our site audited for GDPR technical compliance and no issues were found.

If you are referring to the noindex, nofollow meta tags, you can easily apply them globally, or use just one custom field which could easily be referred to in the head of individual articles.

etc · 2022-12-20 17:33:01

Okay, let’s see what we could do for end users in txp 4.9 without turning it into wp-light.

Trailing slash. It should be easy to introduce a trailing_slash pref with possible values like ‘Yes’, ‘No’ and ‘Lists only’ (as presently). Multiple URL schemes would probably not be possible In ‘Yes’ and ‘No’ modes, to avoid ambiguity, and identically named articles/sections pairs could be problematic. But caveat utilitor.
Meta tags. Say, we introduce a <txp:meta /> tag. Put in a Page, it will output meta data of the landing article/section. But how would we define this data, given their names/values are arbitrary, i.e. not limited to robots or whatever? We can add a meta field to, say, txp_section table, but what would be its format for end-users? Would they be happy with json "name": "value" pairs, or is ini name=value syntax easier to use, or something else?

Ideas welcome.

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">

Textpattern CMS

Textpattern CMS support forum

#13 2022-12-20 15:14:07

Re: Is it still alive?

#14 2022-12-20 16:53:34

Re: Is it still alive?

franzl wrote #334350:

#15 2022-12-20 17:33:01

Re: Is it still alive?

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

Board footer