Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
RFC: Textpattern 5 ideas & feature requests
This is discussion thread for your Textpattern 5 ideas. It’s a companion to our blog post Textpattern CMS 4.9.0 will support PHP 8.4 and MySQL 8.4 and is intended as a ‘thinking out loud’ space for the ‘big’ version of Textpattern that we’re planning after Textpattern 4.9.0.
Please reply with your ideas & feature requests for consideration in Textpattern 5. We value your advice & feedback as real-world Textpattern administrators / users, but please be aware that we can’t promise to include any suggested idea or feature. It’s useful to get a consensus, and it assists us in prioritising features that are to be included.
Please also keep discussion respectful and constructively critical. An idea or feature request might not be relevant to your own Textpattern needs, but please consider the Textpattern user base overall before replying to another user’s post.
Thank you, and let’s go!
Offline
Re: RFC: Textpattern 5 ideas & feature requests
I’ll just list a few things that I’m intending to focus our efforts. In no particular order:
- Merge the custom fields branch in as-is and iterate it forward. It’s close to being production ready (for articles) anyway. Missing items are wiring the txp: tags up to use the new table and some edge cases I’ve noted in code comments. Then roll it out to other content types and think about how to let us tweak the Write panel layout.
- Multiple image formats per tag (srcset/picture support) and carefully-controlled dynamic image generation. This might involve just fixing up the code for the now defunct SLIR project and bundling the best bits in core. TBD.
- Constraints (min, max, sizes, steps, validation patterns, etc) which will slot nicely into the new UI library shipped with Txp 4.9.0. That gives us great custom field and Prefs constraints to improve data validity, and would extend to plugins.
- Add file/image support to the importer so we can open up the nearly-there API to plugins or official modules to make importing and exporting data from other systems more seamless.
- Retire article Keywords and retool them as Tags, allowing us to filter them in combinations via the URL. This may or may not encompass categories on upgrade. TBD.
- Take some more steps towards full multi-lingual content by stripping out some of the ‘title’ columns and offloading them to the lang table.
Those are the big ticket items on my list. I’m sure there are others I’ve forgotten offhand.
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
#3 2024-08-19 14:19:51
- Algaris
- Member
- From: England
- Registered: 2006-01-27
- Posts: 548
Re: RFC: Textpattern 5 ideas & feature requests
1) Unlimited article categories. This is always something I’m running up against with Textpattern. The ability to have articles belonging to more than two categories would be amazing.
2) Custom fields in a similar way to how Advanced Custom Fields Pro handles them in WordPress. Being able to completely change the appearance of the Write tab based on the Section selected would be amazing and having access to a wide variety of fields (such as repeaters) would open up so many possibilities.
3) This is a follow on from my second point. The ability to choose different types of text fields when using custom fields such as WYSIWYG / visual editor fields, plain text, Markdowen, Textile, and HTML fields, etc.
4) Built in support for com_connect with the ability to create custom contact forms using a visual editor in the Textpattern admin area.
5) I know this one is wishful thinking and probably not on the radar. The ability to use Textpattern as a completely flat file system (for site design and content) like Statamic or Kirby and ditch the database completely if you want to. This would make moving from development to production a snap. No longer having to worry about URLs, absolute paths, and article/file/image IDs.
Last edited by Algaris (2024-08-20 08:04:18)
Offline
Re: RFC: Textpattern 5 ideas & feature requests
Command line ability to update.
…. texted postive
Offline
Re: RFC: Textpattern 5 ideas & feature requests
bici wrote #337666:
Command line ability to update.
What do you mean, specifically? Installation is already scriptable so we could build on that. What would your ideal workflow be to upgrade a site via the command line?
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
Re: RFC: Textpattern 5 ideas & feature requests
Myusername wrote #337667:
the text areas in Textpattern are simple HTML textarea elements, whether in the writing panel or in code editing panels. My question is whether there is any effort from the developers to change this, either by including a text/code editor in Textpattern or by taking steps to make their implementation easier.
We have no plans to automatically include code/syntax highlighting at present. The simple reason being that they usually rely on third party libraries like prosemirror, codemirror, etc, and they’re often slow and cumbersome. Plus, some people prefer other editors, or none at all (e.g. for those people using a version control workflow or who import stuff directly into the database via etc_flat). So we offer the lowest common denominator that works.
I am not averse, however, to putting scaffolding in place to make it easier for developers to add such things. A few plugin authors have successfully integrated various editors over the years, but if we can add API access or stuff to core that would help ease plugin development in this regard, then we’re open to it.
things like uploading images directly through the editor in the writing panel seem like a challenge
Have you looked at com_article_image?
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
Re: RFC: Textpattern 5 ideas & feature requests
Myusername wrote #337667:
the text areas in Textpattern are simple HTML textarea elements, whether in the writing panel or in code editing panels. My question is whether there is any effort from the developers to change this, either by including a text/code editor in Textpattern or by taking steps to make their implementation easier. This way, it would be up to plugin developers to implement them, but with more core support, making it easier to implement and maintain the plugin.
Just to add to that, Pete / kuopassa has a number of write-panel editor integrations (you may know them already, as you said you’d tried some plugins), and I have used them before to replace the ancient hak_tinymce when helping people upgrade old sites. To be fair, the Tiny editor has improved a lot, but … they now have a pricing model with a free tier that suffices for small, irregularly updated sites (1000 loads/month) but a punitively steep entry price (I think ~65$/month) once you exceed that.
Markdown you can integrate using wet_textfilter_markdown.
———
I’m personally not fussed about the code editor side of things, because I do all that externally now, but … I do think textile syntax highlighting in the write panels would be highly desirable. smd_textile_bar is a nice help for clients who find textile a bit challenging to grasp. I think that could/should become a “core” option, switchable via a pref. It can stay quite simple like in Kirby. Adding syntax highlighting to textile makes the apparent abstractness of textile more palatable for clients and makes page structure more readily understandable without making any pretences at being wysiwyg. I’m thinking of the kind of subdued level of highlighting you see in iaWriter, Ulysses, Bear and other markdown editors.
The simple reason being that they usually rely on third party libraries like prosemirror, codemirror, etc, and they’re often slow and cumbersome.
My understanding from past discussions was that a key barrier to using existing third-party tools was principally that it’s hard to support txp::shortcode tags in your textareas, which for me would be a blocker, because the !image.jpg!
syntax is too limited nowadays. Other reasons were lack of textile support, and in some cases the high cost of integration.
TXP Builders – finely-crafted code, design and txp
Offline
Re: RFC: Textpattern 5 ideas & feature requests
jakob wrote #337676:
I do think textile syntax highlighting in the write panels would be highly desirable. smd_textile_bar is a nice help for clients who find textile a bit challenging to grasp.
Happy to look at making the plugin either a com_* officially supported module (preferable?) or look into taming it into core. Some of the options are a little ‘advanced’ (e.g. form insertion) but they are darn handy at times. Worth exploring.
My understanding from past discussions was that a key barrier to using existing third-party tools was principally that it’s hard to support txp::shortcode tags in your textareas
Yes, that too. Good catch, I’d forgotten about that.
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
#9 2024-08-20 17:38:07
- Myusername
- Member
- Registered: 2019-12-12
- Posts: 165
Re: RFC: Textpattern 5 ideas & feature requests
Bloke wrote #337673:
Have you looked at com_article_image?
Yes, I tested it months ago, it’s been a while. But I never looked at its code, and looking quickly now, I see that the upload process should be done using Textpattern’s internal functions. More advanced knowledge might be needed, I think (or maybe I’m just dumb, after all). I was thinking more about an API where you can upload images (and other files?) using, including, JavaScript. This way, the plugin developer only needs to worry about connecting the editor to the API and nothing else. APIs are always very interesting, in my opinion. I extensively use the WP API for many tasks, to create or read articles, categories, images, etc.
Offline
Re: RFC: Textpattern 5 ideas & feature requests
Our callbacks are kind of API-ish but if we can expose more stuff via a proper API then it’s a win. I don’t have much experience in this so any guidance or examples would be very helpful.
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
Re: RFC: Textpattern 5 ideas & feature requests
Incidentally, I do have – somewhere – a branch where I began to remap all our callbacks to a more consistent structure. Pre/post on every admin step or before/after every change of state.
Essentially it was a giant lookup table in the heart of our callback
routines that remapped the ones that were inconsistent (for backwards compatibility with core and plugins), and then many of the callbacks were renamed, plus extra ones defined throughout. The plan was to create a more consistent foundation for exposing the inner workings of Textpattern to be twisted into more workflows by plugins and themes.
If it helps, I could dig this out and expose it as a feature branch sometime.
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
Re: RFC: Textpattern 5 ideas & feature requests
Bloke wrote #337671:
What do you mean, specifically? Installation is already scriptable so we could build on that. What would your ideal workflow be to upgrade a site via the command line?
a shell script command to update Textpattern via the command line on the server.
eg. php txpcli.php update
…. texted postive
Offline