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.

Myusername · 2019-12-14 18:05:26

etc wrote #320530:

The layout will be very basic and unstyled, but your site is AMP-compatible as long as your articles body is.

I don’t mean that you are wrong, but in fact, it is not just the body of the article that needs to be compatible to have an AMP page.

Literally the whole page needs to be compatible: It is not allowed to use javascript, for example, whether it is inside <head> or at the end of <body>, there are also CSS commands that are not allowed, such as display: table.

You gave a good example of an AMP page, however, you would have to limit my main page not to use some CSS commands. Also, what would you do if you wanted to use a library like Jquery?

Here comes the alternate version of the page I mentioned earlier. So you can have your page showing all the power you want, and another version with AMP, which would be extremely more limited and simple. Of course, it will not be used by default, it will only be used when the user comes from Google search slides.

But the point here is that you can have an alternate AMP page from existing pages, displaying or hiding anything you want, which can only be accessed by using “/amp/” at the end of any publication’s URL.

I’m working on the look of an AMP site on Textpattern using the “pat_if_amp” plugin, it will soon be ready and I’ll show you how it works, if you want.

Last edited by Myusername (2019-12-14 18:06:53)

Bloke · 2019-12-14 18:20:13

If the large part of pat_if_amp is detecting if the URL contains /amp or not, you can probably do that with native tags now. Check the URL at the top of every page and set a <txp:variable> then test it at key points on your page via <txp:if_variable> to switch content. Maybe make up your own shortcode tag in a form. Up to you.

You could then serve a different, simpler stylesheet. Only key bits of content. Skip JavaScript. Whatever you want.

There’s so much you can do without plugins once you start weaving the power of the tags we introduced and enhanced in Textpattern 4.7.+.

Last edited by Bloke (2019-12-14 18:20:46)

colak · 2019-12-14 19:27:08

Bloke wrote #320534:

If the large part of pat_if_amp is detecting if the URL contains /amp or not, you can probably do that with native tags now. Check the URL at the top of every page and set a <txp:variable> then test it at key points on your page via <txp:if_variable> to switch content.

I, and possibly Myusername, would appreciate a tags example here:).

Also, excluding the size of the images and some proprietry tags and specs, what I’m not sure about is the difference between AMP and the media css query. ~~Maybe I am understanding it wrongly but isn’t AMP designed to serve lighter stylised content to mobile devices?~~ Found it. Basically AMP uses Google as a proxy.

AMP pages are served to the user from the Google AMP cache.

Last edited by colak (2019-12-14 19:46:31)

Textpattern CMS support forum

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