RFC: Textpattern 5 ideas & feature requests

jakob · 2025-08-15 17:02:06

Bloke wrote #340194:

I don’t see this as a major issue, because I suspect 80 (90?)+ percent of people will use it for just marking up text. It’s only us hardcore folk that tend to go above and beyond the standard usage, right?

I absolutely see that as an issue. If you want to embed an image with a srcset, or perhaps a small set of images, a shortcode is the only way to go (apart from writing it all in html – or is there another option). As soon as a client declares they want Markdown, and then later decides they could imagine having a slideshow within the article, what do you do if shortcodes don’t work…

etc wrote #340192:

From a quick GH test, Markdown encodes txp tags:

phiw13 wrote #340193:

FWIW, Textpattern 4.9, Markdown plugin active. Markdown extra selected as format, input:

Hello, <txp:author />...

So GitHub can’t but Textpattern can. That would certainly be encouraging if one can continue using shortcodes and regular tags with Markdown in Textpattern.

Bloke · 2025-08-15 17:20:50

jakob wrote #340195:

a client declares they want Markdown, and then later decides they could imagine having a slideshow within the article, what do you do if shortcodes don’t work…

Put the shortcode on its own line? I believe Parsedown will handle that, it’s just mixing them it can’t do as there’s no way to ‘escape’ complex codes.

As phiw13 demonstrated, simple tags (without attributes?) work fine inline. I’ve not tested this rigorously (uhh, at all) so the situation may be better than we hoped. Perhaps Markdown can handle inline markup now.

phiw13 · 2025-08-16 01:59:51

jakob wrote #340195:

I absolutely see that as an issue. If you want to embed an image with a srcset, or perhaps a small set of images, a shortcode is the only way to go (apart from writing it all in html – or is there another option). As soon as a client declares they want Markdown, and then later decides they could imagine having a slideshow within the article, what do you do if shortcodes don’t work…

So GitHub can’t but Textpattern can. That would certainly be encouraging if one can continue using shortcodes and regular tags with Markdown in Textpattern.

It is not surprising GH can’t handle those <txp:tag />. It doesn’t known anything about it, and treat it as “unknown tag” or such. Thankfully it sanitise it and does it in a friendly way, the tag is still visible. I seem to remember Vignette completely removing them, which is still better than leaving them in probably invisible and then open for potential abuse.

And yes, as I mentioned upthread, your shortcode tags would continue to work fine.

phiw13 · 2025-08-16 02:32:54

Bloke wrote #340197:

As phiw13 demonstrated, simple tags (without attributes?) work fine inline. I’ve not tested this rigorously (uhh, at all) so the situation may be better than we hoped. Perhaps Markdown can handle inline markup now.

As far as I can tell, I can do most everything the same in a Markdown managed file as I do with a Textile one. Or at least most what we need here (shortcodes being the most important one). And of course some more, really complex Textpattern tags might have a problem. But that happens with Textile as well.

Here a very basic example: emps.l-c-n.com/tests/markdown-test1 – a shortcode to embed the image, the <txp:author /> used as sample before (of course you can’t see from it that the underlying code is Markdown :-()

PS – I don’t remember if there is an .notextile or == equivalent in Markdown.

Bloke · 2025-08-16 08:29:39

That’s good to know. So having both languages available side by side is a win.

Dragondz · 2025-08-19 10:23:14

Hi everyone,

My 2 roblox coins,

If having markdown as an additional option can ease some new users why not.

I think it could be good to have a startup approach for this, quickly build the feature the simplest way possible to not cost a lot of dev time and test the response from user, if the response is positive devs can take more time to refine it.

Cheers.

gaekwad · 2025-08-28 13:58:42

Some considerations for admin-side language strings, specifically around pophelp and their (its?) parity with textpacks.

Permit pophelps to be installed / updated in the way textpacks are currently.
Permit pophelps & textpacks to be deleted (see #1768 for existing issue)

Bloke · 2025-08-28 14:30:33

gaekwad wrote #340320:

Permit pophelps to be installed / updated in the way textpacks are currently.

Good idea. We should be able to do this. They’re XML and we have an importer so it shouldn’t be a stretch with some UI sprinkling.

Permit pophelps & textpacks to be deleted

That’s more problematic. Hiding unused ones via a toggle is simpler and less likely to confuse, imo. We can figure the best way, though.

jakob · 2025-08-29 09:05:42

gaekwad wrote #340320:

Some considerations for admin-side language strings, specifically around pophelp and their (its?) parity with textpacks.

Permit pophelps to be installed / updated in the way textpacks are currently.

Permit pophelps & textpacks to be deleted (see #1768 for existing issue)

That’d be nice. I faked it in a recent update to etc_search by retrofitting a textpack string to the button.

Bloke · 2025-08-29 09:36:03

Bloke wrote #340321:

[Pophelps are] XML and we have an importer so it shouldn’t be a stretch with some UI sprinkling.

It’d be great if we could handle this on the Languages panel.

All we really need is a way to indicate if a language has an update available for both (either?) pophelp and lang strings in the box.

Could we cover the install / update / reload using the existing button? So if either file is newer, it updates or installs them both?

Can anyone think of a situation where someone might want to install or remove only one and not the other?

The percentage still only applies to Textpack completion, as we’ve no way to gauge which elements require pophelp.

Edit: not sure about the manual additional strings box at the bottom. Could we accept either ini-style strings or XML there? Should de easy to detect which and handle accordingly.

This almost feels doable now :)

Last edited by Bloke (2025-08-29 09:39:12)

gaekwad · 2025-08-29 13:30:26

Bloke wrote #340321:

That’s more problematic. Hiding unused ones via a toggle is simpler and less likely to confuse, imo. We can figure the best way, though.

Quick back of napkin maths shows the language packs + pophelps are currently ~3.5MB from a total of ~8MB in the expanded filesystem with /textpattern/setup/ present – so about 40% of the overall payload. Language packs is one area that likely keep growing, and it’s not something we can optimise easily.

Aside: are there any inherent risks associated with not uploading all the unused packs?

Bloke · 2025-08-29 13:53:26

gaekwad wrote #340360:

are there any inherent risks associated with not uploading all the unused packs?

None whatsoever. The missing languages just won’t show up in the Languages panel (which is why we can’t “remove” them from the UI list without deleting the physical files… which means they’re then not available in future without downloading a pack and dropping it in the lang directory.)

Last edited by Bloke (2025-08-29 13:54:32)

jakob · 2025-09-03 06:07:59

Not necessarily the language panel method, but just cross-posting to this thread where Stef already outlined a method for plugins.

gaekwad · 2025-10-10 14:24:08

Two things…

First, can we take a moment to acknowledge this thread has passed 20,000 views?

Second, could we consider having a pref to choose whether the Save button on non-article content (i.e. files, images, links) bounces you back to the list of said content or keeps you on the content item itself?

Articles, forms, pages…you tap or click Save…you stay on the article / form / page edit page. Great. As expected.

The other content…tapping or clicking Save brings you back to the list of that content…which then takes a tap / click & maybe some scrolling to get back to edit that content.

Thank you for your considerations, Textpattern Council.

Bloke · 2025-10-10 14:49:34

gaekwad wrote #340905:

could we consider having a pref to choose whether the Save button on non-article content (i.e. files, images, links) bounces you back to the list of said content or keeps you on the content item itself?

This is something I’ve pondered. Some workflows require remaining on the ‘edit’ step, others I’m quite glad I don’t have to click Go back. A pref seems too bludgeony (though a per-user pref might work).

One thing I’ve considered is a split button. Seems as though we could streamline the actions here – on the Write panel too – and have:

Save – default. Stays on the page
- Save and go back – does what it says on the tin
- Go back – abandons changes and returns to the list view

Not sure. Would need some ratification from those more versed in UX than me. ‘Go back’ seems a bit presumptuous that you have come from the list view, so there might be better labelling to be had.

Last edited by Bloke (2025-10-10 14:52:07)

Textpattern CMS support forum

#91 2025-08-15 17:02:06

Re: RFC: Textpattern 5 ideas & feature requests

Bloke wrote #340194:

etc wrote #340192:

phiw13 wrote #340193:

#92 2025-08-15 17:20:50

Re: RFC: Textpattern 5 ideas & feature requests

jakob wrote #340195:

#93 2025-08-16 01:59:51

Re: RFC: Textpattern 5 ideas & feature requests

jakob wrote #340195:

#94 2025-08-16 02:32:54

Re: RFC: Textpattern 5 ideas & feature requests

Bloke wrote #340197:

#95 2025-08-16 08:29:39

Re: RFC: Textpattern 5 ideas & feature requests

#96 2025-08-19 10:23:14

Re: RFC: Textpattern 5 ideas & feature requests

#97 2025-08-28 13:58:42

Re: RFC: Textpattern 5 ideas & feature requests

#98 2025-08-28 14:30:33

Re: RFC: Textpattern 5 ideas & feature requests

gaekwad wrote #340320:

#99 2025-08-29 09:05:42

Re: RFC: Textpattern 5 ideas & feature requests

gaekwad wrote #340320:

#100 2025-08-29 09:36:03

Re: RFC: Textpattern 5 ideas & feature requests

Bloke wrote #340321:

#101 2025-08-29 13:30:26

Re: RFC: Textpattern 5 ideas & feature requests

Bloke wrote #340321:

#102 2025-08-29 13:53:26

Re: RFC: Textpattern 5 ideas & feature requests

gaekwad wrote #340360:

#103 2025-09-03 06:07:59

Re: RFC: Textpattern 5 ideas & feature requests

#104 2025-10-10 14:24:08

Re: RFC: Textpattern 5 ideas & feature requests

#105 2025-10-10 14:49:34

Re: RFC: Textpattern 5 ideas & feature requests

gaekwad wrote #340905:

Board footer