Textpattern CMS support forum

You are not logged in. Register | Login | Help

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,620
Website

Textpattern Next Non-Patch Version Roadmap

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.


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

#2 2019-03-12 20:23:11

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 3,393
Website

Re: Textpattern Next Non-Patch Version Roadmap

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

TXP Builders – finely-crafted code, design and txp

Offline

#3 2019-03-12 20:43:32

gaekwad
Member
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 2,440

Re: Textpattern Next Non-Patch Version Roadmap

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.

Offline

#4 2019-03-13 09:53:59

Algaris
Member
From: England
Registered: 2006-01-27
Posts: 436

Re: Textpattern Next Non-Patch Version Roadmap

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

Offline

#5 2019-03-13 12:17:39

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 1,626
Website

Re: Textpattern Next Non-Patch Version Roadmap

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!

Offline

#6 2019-03-13 12:33:05

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,620
Website

Re: Textpattern Next Non-Patch Version Roadmap

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.


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

#7 2019-03-13 14:19:03

philwareham
Core designer
From: Farnham, Surrey, UK
Registered: 2009-06-11
Posts: 3,175
Website

Re: Textpattern Next Non-Patch Version Roadmap

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.

Offline

#8 2019-03-13 16:49:21

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

Re: Textpattern Next Non-Patch Version Roadmap

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.


etc_[ query | search | pagination | date | tree | cache ]

Offline

#9 2019-03-14 07:42:00

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 1,626
Website

Re: Textpattern Next Non-Patch Version Roadmap

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.

Offline

#10 2019-03-14 07:42:48

Dragondz
Moderator
From: Algérie
Registered: 2005-06-12
Posts: 1,306
Website

Re: Textpattern Next Non-Patch Version Roadmap

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?

Offline

Board footer

Powered by FluxBB