Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2019-12-13 20:23:08

Myusername
Member
Registered: 2019-12-12
Posts: 44

Two future feature suggestions

I’ve been following the forum posts a lot, and I wanted to give the developers a suggestion. Who knows, they might even enlighten me.

There are plugins that in my opinion are essential in the creation of any site, especially when it comes to large sites that have a lot of content. So I’m a little afraid when I think of migrating my site to Textpattern, as these plugins may stop working, and I’m not a PHP professional who could solve my problem right away.

Some examples of essential plugins I talk about are rah_sitemap and pat_if_amp, for example.

Both are self-explanatory, so I don’t need to go into explanations here. But the question is: Wouldn’t it be interesting to have these features natively in Textpattern? Would it be complicated to bring in future versions?

Offline

#2 2019-12-13 20:59:59

colak
Admin
From: Cyprus
Registered: 2004-11-20
Posts: 7,997
Website

Re: Two future feature suggestions

Myusername wrote #320510:

Some examples of essential plugins I talk about are rah_sitemap and pat_if_amp, for example.

Both are self-explanatory, so I don’t need to go into explanations here. But the question is: Wouldn’t it be interesting to have these features natively in Textpattern? Would it be complicated to bring in future versions?

The rah_sitemap functionality can easily be achieved natively. Tell us what sections, categories, articles you would like to include or exclude and we can help.

I believe that amp is an ethically ambiguous technology as it was proven to be more about controlling, rather than assisting to serve the content.

Admittedly, these kind of technologies are indeed spreading, which means that txp will be ever bloating to accommodate them. Although Patrick’s work is indeed very welcome to the cms and the community, I believe that AMP compatibility should remain in the plugin domain.

Having said that, I would support whatever the final decision our devs will make.


Yiannis
——————————
neme.org | hblack.net | LABS | State Machines | NeMe @ github | Covid-19; a resource
I do my best editing after I click on the submit button.

Online

#3 2019-12-13 22:40:21

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,458
Website

Re: Two future feature suggestions

As Yiannis says, a sitemap plugin is no longer necessary. You can create your own auto-updating sitemap very simply using native tags and, more to the point, control exactly what you make visible; something that a plugin can’t hope to easily expose.

Here’s an example that Yiannis himself has constructed for one of his sites that has thousands of pages. You can see that template in action at www.neme.org/sitemap/.

As for AMP, well, not everyone uses it so we’d prefer to leave this feature served via plugin. Pat’s code is excellent and well maintained so if you need this functionality I wouldn’t hesitate to recommend it.

Rather than continually add stuff, we’re gradually finding ways to jettison as much code as possible from core into optional modules. This helps cut our codebase down and helps people keep their sites streamlined. One of the things we pride ourselves on is how fast our parser is compared to most of the competition, even though it’s still phenomenally powerful.

We are in the process of modularising XML import/export. We removed our outdated importer a few versions ago and have since built a framework to allow a simple few-line bridge plugin to offer content importing from other CMSs. We may consider removing comments in future from core too, for this modularisation treatment. Undecided.

We could build in the same modularisation for AMP, perhaps, but it’s not on our radar. For now, though, it’s 100% plugin territory. If you need it, install the plugin.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#4 2019-12-13 23:29:26

Myusername
Member
Registered: 2019-12-12
Posts: 44

Re: Two future feature suggestions

Bloke wrote #320512:

We could build in the same modularisation for AMP, perhaps, but it’s not on our radar. For now, though, it’s 100% plugin territory. If you need it, install the plugin.

I don’t see the problem using the plugin, it works perfectly. But since it’s not a native feature, it may stop working in future textpattern updates, right?

Offline

#5 2019-12-13 23:39:36

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,458
Website

Re: Two future feature suggestions

Potentially yes, but it depends how the plugin is written. If it’s a lot of back-end code hooking into existing panels then yes this can change if we move things around (although the panel layouts are generally fairly well established and don’t change that much). If it does things on its own panel, then there’s more control over that, so it’s less likely to break unless we remove functions in core (which we do occasionally a few versions after they’ve been deprecated) or if the plugin uses PHP features that have been removed by the PHP team.

If our front-end code ever changes, we do our level best to maintain backwards compatibility. I have front-side plugins from 2006 that are still functioning in the latest version.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#6 2019-12-14 00:26:30

Myusername
Member
Registered: 2019-12-12
Posts: 44

Re: Two future feature suggestions

Bloke wrote #320514:

Potentially yes, but it depends how the plugin is written. If it’s a lot of back-end code hooking into existing panels then yes this can change if we move things around

Yes, so I suggested the native AMP feature, as the plugin might crash in the future. And running out of AMP for some sites is a nightmare (especially for news sites) as it keeps them from being shown in the first search results on google on mobile. This native feature would make any website owner safe about that.

Like you said, it’s not everyone who uses it, so I think this feature could be disabled by default, and only those who wanted to use it would probably turn it on (probably from the textpattern preferences screen). It would be lovely.

Anyway, thanks for your reply.

Offline

#7 2019-12-14 08:33:03

colak
Admin
From: Cyprus
Registered: 2004-11-20
Posts: 7,997
Website

Re: Two future feature suggestions

Just another note. AMP is indeed marketing itself as if it is a useful service but I believe that the near future, promised/threatened by 5G mobile technologies will make it obsolete.


Yiannis
——————————
neme.org | hblack.net | LABS | State Machines | NeMe @ github | Covid-19; a resource
I do my best editing after I click on the submit button.

Online

#8 2019-12-14 10:15:52

etc
Developer
Registered: 2010-11-11
Posts: 3,693
Website

Re: Two future feature suggestions

Myusername wrote #320515:

Yes, so I suggested the native AMP feature, as the plugin might crash in the future. And running out of AMP for some sites is a nightmare (especially for news sites) as it keeps them from being shown in the first search results on google on mobile. This native feature would make any website owner safe about that.

Sorry, what do you mean by AMP feature? As I get it, AMP is kinda restricted HTML framework (promoted by Google) that you are free to use in txp. You would just need to create/import a theme respecting AMP standards and keep to it in all content you publish. But there is no way to magically turn a general HTML into AMP without breaking something.

So, what would you expect from txp core AMP-wise? We could add some attribute to txp image tags to generate <amp-img /> instead of <img />, the rest is up to you. You’ve got a full and easy control on your templates with txp.

Offline

#9 2019-12-14 11:47:31

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,458
Website

Re: Two future feature suggestions

etc wrote #320520:

We could add some attribute to txp image tags to generate <amp-img /> instead of <img />, the rest is up to you.

Could a plugin do that, btw? Registering an attribute on a core tag and intercepting it? I’ve not played with the attribute registration feature yet.

I’ve never played with AMP so I’m not sure of the attraction, nor of its capabilities or what it brings to the web. If and when someone comes to me with a desperate need to build a site that has it, I’ll probably look into it then.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#10 2019-12-14 12:31:27

etc
Developer
Registered: 2010-11-11
Posts: 3,693
Website

Re: Two future feature suggestions

Bloke wrote #320522:

Could a plugin do that, btw? Registering an attribute on a core tag and intercepting it? I’ve not played with the attribute registration feature yet.

Not atm, global attributes apply post-parse to tags output. We will introduce pre-parse attributes (e.g. for cache), but there is no mean to intervene “per-parse”, save via common entry points like doWrap(). But you can very well register a plugin as <txp:image /> tag and do what you want.

I’ve never played with AMP so I’m not sure of the attraction, nor of its capabilities or what it brings to the web.

You get the general idea here: “AMP is an open-source HTML framework” (citation) that Google supports via its search ranking and cache. Nothing essentially different from Bootstrap/Foundation and such, but more restrictive and mobile-oriented. Fully treatable with txp :-)

Offline

Board footer

Powered by FluxBB