RFC: Textpattern 5 ideas & feature requests

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 · Today 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 · Today 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 (Today 14:52:07)

gaekwad · Today 14:52:43

Bloke wrote #340907:

A pref seems too bludgeony.

[…]

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

Thanks, Bloke. I’d considered the split button approach, but that felt too bludgeon-y to me…hence prefs. Either would suffice, though I’m erring toward the split approach if the UX fam-a-lam can find a way to make it work.

Bloke · Today 15:02:20

Yeah, neither are ideal.

If we kept the ‘Go back’ button separate, we could make the Save process adaptive, but I’m not sure how friendly that is. So the split button has two options: “Save” being primary, and “Save, then list” (or whatever wording) is the secondary action. But it stores a per-user pref that indicates which option you chose, and switches the order of the actions next time you visit the edit step.

That kind of feels helpful because it’s zero config and if you’re doing bulk stuff, it’s handy to have it ‘remember’ which action you take most often in your current workflow. But if you later decide to go into ‘extensive editing mode’ and choose Save then it’ll offer that as the default action.

My reservation with this is twofold:

it feels reminiscent of the adaptive menus in Microsoft products circa 1997 where you could never find the less-used action you want because it got shuffled under the submenu arrow if you didn’t use it much.
documenting things becomes more unwieldy (click the “Save” or “Save and return” button…)

There might be a better way.

Textpattern CMS

Textpattern CMS support forum

#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 Today 14:24:08

Re: RFC: Textpattern 5 ideas & feature requests

#105 Today 14:49:34

Re: RFC: Textpattern 5 ideas & feature requests

gaekwad wrote #340905:

#106 Today 14:52:43

Re: RFC: Textpattern 5 ideas & feature requests

Bloke wrote #340907:

#107 Today 15:02:20

Re: RFC: Textpattern 5 ideas & feature requests

Board footer