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.

Textpattern CMS

Textpattern CMS support forum

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