Textpattern Next Non-Patch Version Roadmap

Bloke · 2019-03-12 16:07:55

Please share your thoughts/ideas on the Textpattern Next Non-Patch Version Roadmap here. We look forward to your feedback and opinions on plans for the next exciting installment of our favourite CMS.

jakob · 2019-03-12 20:23:11

Great post, Stef + Pete! Of the things you mention, I’m in favour of them all. ?

Too greedy? Okay, if I was forced to prioritise, these seem to me most important:

Unlimited custom fields for Articles, Images, Files, Links, Sections, Categories and Users
File and Image handling improvements

I reckon those would be worthy of a main version bump.

Some are already well underway like custom fields, some of the images and dark mode (looking at the commits).

And even though I work in two languages, I’d still like to see some more general ‘structural’ things happen before better multi-language capability:

‘Unlimited’ (or at least significantly more than 2) assignable categories
Theme prefs and attached files/plugins. We already have a great new facility with the themes, but we don’t have many to showcase. If sites are not to end up all looking identical, the ability to have theme-specific settings (e.g. fonts, key colours, etc.) would be excellent, as would the ability to bundle plugins and sample start content to get people going. IIRC Stef has already put some of the groundwork in for the necessary field types (also good for custom fields). I think some of the groundwork for these also exists.

The items I know least about it, and would like to understand better are:

Investigate GraphQL as a replacement for XML-RPC
Investigate third-party mail transport support

gaekwad · 2019-03-12 20:43:32

jakob wrote #317014:

The items I know least about it, and would like to understand better are:

Investigate GraphQL as a replacement for XML-RPC

Investigate third-party mail transport support

Both of these are loosely under the umbrella of “things have changed, let’s evolve”. The mail transport thing is, broadly speaking, aimed at making email sending more robust, with more options. At the moment, Textpattern uses PHP mail() to send transactional emails. A web server is not necessarily the best email server, and anecdotally it’s becoming harder to ensure an email sent from a server actually arrives at the intended destination. Offloading email sending to either a) a provided SMTP server (with appropriate DKIM, SPF and DMARC to stay in business) or b) a transactional email service like SendGrid makes better use of the right tool for the job.

As for the voodoo that is GraphQL, well…I’ll defer that to Phil as he’s the expert there.

Algaris · 2019-03-13 09:53:59

The prospect of unlimited custom fields has me very excited.

jakob wrote #317014:

‘Unlimited’ (or at least significantly more than 2) assignable categories

Yes please. This is something I always come up against when using Textpattern.

I opened an issue on GitHub for this here: Add unlimited categories to the core

phiw13 · 2019-03-13 12:17:39

jakob wrote #317014:

Too greedy? Okay, if I was forced to prioritise, these seem to me most important:

Unlimited custom fields for Articles, Images, Files, Links, Sections, Categories and Users

File and Image handling improvements

I reckon those would be worthy of a main version bump.

Yes! and yes! those two are my most important feature requests. Especially the first one, coupled with expanded categories handling for images & files.

Then,

“Ongoing code improvements“ sure, always welcome. Oleg has done a stellar job over the last year.
improved mail() handling (third-party mail transport support) – yeah, ok, although I don’t have much problem with it.
The GraphQL – hmmm. Seeing that it is a toy that originates in the Facebook eco system has me immediately very wary.

BTW,

Textpattern core has no code for gathering usage metrics, and has no spyware or similar undesirable software to ‘phone home’.

That is another part of Textpattern that I value highly!

Bloke · 2019-03-13 12:33:05

I’ve answered Algaris’ issue (finally!) but I’m not sure I have a clear path in my head of how to move forward with unlimited cats.

Part of me thinks that if we can crack unlimited custom fields in a suitable fashion and permit filtering (both ANY/ALL) from the URL then unlimited cats becomes kind of moot. You could make a CF called tags for example, set up a dropdown multi-select list of available tags to display when creating content and make assignments that way. Hide the category block and you’re away.

Perhaps example.org/filter/article/tags/foo+bar would show articles that had both `foo` and `bar` assigned to the tags custom field? Not sure on the syntax as it could get pretty hairy when we have to specify:

Some ‘trigger’ (filter in the above example) to indicate we want to filter by CF instead of some other attribute.
The content type we wish to search (article in the above example).
The field we wish to search (tags in the above example).
The content values we wish to consider, separated by some delimiter that could indicate ALL or ANY matching inclusion.

Dunno. Having unlimited category assignment for all content types baked in is a nice convention. Like a special custom field. I’m just concerned the various naming strategies we may have to come up with are going to get mighty confusing.

philwareham · 2019-03-13 14:19:03

Regarding GraphQL (and also Facebook’s former role in it) this article gives a nice overview

TLDR; it’s an API for delivering data/content to any endpoint. So, say, your Textpattern installation could power a web app, mobile app, or one of 1000s of other projects that accept GraphQL data.

etc · 2019-03-13 16:49:21

Re GraphQL, an obscure point (for me) is its configuration: who must do it? Someone has to decide which data is exportable and how. If we do it in core, advanced users could find it too restrictive. If we leave it with users, the less advanced ones could find it too complicated. But I know very little of GraphQL and possibly get the whole thing wrong.

phiw13 · 2019-03-14 07:42:00

philwareham wrote #317028:

Regarding GraphQL (and also Facebook’s former role in it) this article gives a nice overview

Not much to reassure me in that article… :-(. But then, it is a Wired article.

Dragondz · 2019-03-14 07:42:48

etc wrote #317030:

Re GraphQL, an obscure point (for me) is its configuration: who must do it? Someone has to decide which data is exportable and how. If we do it in core, advanced users could find it too restrictive. If we leave it with users, the less advanced ones could find it too complicated. But I know very little of GraphQL and possibly get the whole thing wrong.

Hi, maybe if possible create a plugin for GraphQL exposing basic data for beginner users and let advanced ones modify it or create their own plugins to handle advanced use?

Bloke · 2019-03-14 08:16:17

Dragondz wrote #317038:

Hi, maybe if possible create a plugin for GraphQL exposing basic data for beginner users and let advanced ones modify it or create their own plugins to handle advanced use?

That sounds like a winner if it’s possible. If anyone would like to try this out and needs core to do anything to support it, please let us know.

phiw13 · 2019-03-14 11:17:03

Dragondz wrote #317038:

Hi, maybe if possible create a plugin for GraphQL exposing basic data for beginner users and let advanced ones modify it or create their own plugins to handle advanced use?

That sounds like a good idea – a bit similar to the com_connect contact form / email plugin. And if you don’t want or need that tech, you don’t install the plugin and your site is not exposed to the eventual risks.

philwareham · 2019-03-14 11:58:59

Sure, I’d be fine with a plugin if it was an officially supported (core) plugin like com_connect. I can see why people would not want it. Equally, having it can open the CMS up to all sorts of new exciting possibilities.

We can then also ditch all the old RPC server stuff in core and streamline that.

ia278 · 2019-03-19 17:42:01

While I think it’s a lot easier to develop a website on TextPattern compared to other CMSes, I do think it’s a lot simpler to publish articles on platforms such as WordPress (pre v5.0, the Gutenberg editor is stupid IMO)! Because of this, I’m limiting my suggestions to one area – the article writing experience.

So what would I do differently? It’s difficult to comprehensively say without researching the problem, but of the top of my head I’d suggest two things;

1. WYSIWYG editor in the core

Once it comes to typing on computers, there’s a layout that we’re all quite familiar with;

That’s a screenshot from Word – but it could be from virtually anywhere, given how widespread WYSIWYG editors are in digital products.

I’ve got no problem with Textile. But from a user experience point of view, it’s nearly always better to present users with an interface they’re familiar with, rather than ask them to learn something new. It’s why Gutenberg has gone down badly with users, and definitely one of the reasons I wouldn’t build a client website with TextPattern – I think the familiarity of WYSIWYG editors trump Textile.

2. Article image handling

It sounds like this is going to be massively improved in the next release – and I can’t wait to see what’s suggested!

Saying that, my (very ambitious) dream would be some way of being able to view images in the text tab (or even the preview tab). Again, I’ve probably been spoiled by Word and influenced by a desire for consistency – but not being able to get a general gist of the general layout of a page without previewing it has always slowed me down when I write an article! Adding to this, I can’t see an easy way for non-technical users to easily change the size of an image.

My personal work around these issues have been to create a non-indexed testing area to publish articles in development (for some reason, draft article previews don’t update when changes are made), and to assign image sizes by class name (so images of width 100%, 75%, 50% etc. would have different class names) – but again, this seems over-complicated, and another reason I’d build a client site with other CMSes.

Personally, these things aren’t problems for me – I love this CMS! But if I could improve anything, it’d be those two things.

Last edited by ia278 (2019-03-21 14:29:41)

etc · 2019-03-20 11:27:05

@ia278 thanks for the ideas, very welcomed. I see the point of

… it’s a lot easier to develop a website on TextPattern compared to other CMSes, … it’s a lot simpler to publish articles on platforms such as WordPress

We have discussed WYSIWYG editors integration many times. Each time the conclusion was “it’s plugins territory”. But I finally think we could ship it natively – not in core but in a theme. We have no time to develop our own editor, I think, so the choice belongs to theme authors. I have tried jQuery TE integration in Hive, it works out of the box though needs some polishing.

@philwareham would you like to develop a WYSIWYG capable theme for the next txp release? It looks independent of custom fields, so it could be 4.7.4.

Textpattern CMS

Textpattern CMS support forum

#1 2019-03-12 16:07:55