Two future feature suggestions

Myusername · 2019-12-13 20:23:08

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?

colak · 2019-12-13 20:59:59

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.

Bloke · 2019-12-13 22:40:21

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.

Myusername · 2019-12-13 23:29:26

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?

Bloke · 2019-12-13 23:39:36

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.

Myusername · 2019-12-14 00:26:30

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.

colak · 2019-12-14 08:33:03

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.

etc · 2019-12-14 10:15:52

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.

Bloke · 2019-12-14 11:47:31

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.

etc · 2019-12-14 12:31:27

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

Myusername · 2019-12-14 15:55:49

etc wrote #320520:

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.

I think I would expect what the plugin already does, but as I told Stef, it may stop working in the future, and a site without AMP does not currently appear on the main slide of google searches, causing the site without AMP fique em big disadvantage.

AMP pages do not support any kind of javascript in your HTML, as well as any inline styles. In addition to several other requirements, and this all makes using the plugin necessary. (At least I think, if you have another way to do what I described above easily, I would like to know.) What the plugin basically does is make you have posts with “/amp/” at the end of the URL (as an alternate URL). It also makes it possible to use a conditional tag like this <txp:if_variable name="pat_amp" value="1"> to control what should be shown on the AMP page, and what should NOT be shown on AMP pages.

In Wordpress, for example, there is an official AMP plugin.

Anyway, I’m just giving a more amateur view of things.

Last edited by Myusername (2019-12-14 16:03:47)

etc · 2019-12-14 16:58:32

Myusername wrote #320526:

In Wordpress, for example, there is an official AMP plugin.

You don’t really need any plugin to make a AMP site with txp. The simplest way is to serve all pages as AMP, modern browsers have no problem to output them. To this end you just need to create a txp Page like

<!doctype html>
<html ⚡>
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width,minimum-scale=1">
  <link rel="canonical" href="<txp:page_url context />">
  <title>AMP Website Demo</title>
  <script async src="https://cdn.ampproject.org/v0.js"></script>
</head>
<body>
  <txp:article>
    <h2><txp:permlink><txp:title /></txp:permlink></h2>
    <amp-img src="https://unsplash.it/400/300?image=11"
             width="400"
             height="300"
             alt="a sample image">
    </amp-img>
    <txp:body />
  </txp:article>
</body>
</html>

Then assign this page to all sections, publish few articles and that’s all. The layout will be very basic and unstyled, but your site is AMP-compatible as long as your articles body is. Now you can progressively enhance this Page with menus and other AMP components. This will require some work and knowledge, but it’s basically what WP plugin is – a template.

Textpattern CMS

Textpattern CMS support forum

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