RFC: Textpattern 5 ideas & feature requests

Bloke · 2024-09-13 12:51:58

Yes! Please! Do we think output_file is an appropriate tag name? I’m thinking what if we could harness it in future to output images or playback videos or allow plugins to trigger downloadable content in response to a third party payment, etc.

Would <txp:output> be more flexible? Perhaps with a type attribute to differentiate (default=“file” or even context dependent somehow?) Or <txp:send>? Or something…?

Happy to keep it specific to files if it makes sense to consider other stuff later.

etc · 2024-09-13 17:40:54

I would restrict it to txp ‘files’ atm. Just added type attribute to <txp:file_download /> tag:

<txp:file_download id="1,2,3" sort="RAND()" type="application/pdf">
    <txp:header name="content-disposition" value="inline" />
</txp:file_download>

Please test.

Bloke · 2024-09-13 18:50:01

etc wrote #337855:

I would restrict it to txp ‘files’ atm.

Fine by me.

Just added type attribute to <txp:file_download /> tag:

Sweet. Will test when I get a chance. Thank you for the elegant solution.

bashirnoori · 2024-09-16 01:19:53

If we have different field format for custom fields like text, radio button, checkbox, dropdown … it will be great as I need sometime to manage some items/articles through custom_field.
For example, I already display article_image for all articles, some time I don’t want to show that in a specific article and now I do with custom field named is_show_article_image if the value there become 0 or NO, then it will not display in article, so for that if I prepare checkbox it will be easy to clients to understand.
Also, I have a products page which shows the product type now I manage that through custom field text, if that possible to make drop-down or radio buttons, it will be great.

Bloke · 2024-09-16 05:12:27

Custom fields of different types is very much part of the plan. In fact, it’s coded already and, not only does it let you define the type, it stores its data in the most efficient way possible under the hood, which is something no other CMS does, as far as I’m aware.

On top of this, what you seem to be after is dependent custom fields. That’s interesting and not something I’d yet considered, beyond the fact that each can be grouped into a family. To do that requires JavaScript to toggle fields on and off, and honestly, the only ones it applies to are (single) checkbox, radio and select field types as the ‘controlling’ field.

I guess the JS code could be fairly standard, but we’d have to have some conventions in place such that the ‘controlling’ field must be opt in, i.e. it needs to always be “add such and such” not “hide such and such”. Because otherwise the logic would need to be flipped and that’s going to make it harder to manage the code.

Leave this with us and we’ll see what’s possible.

colak · 2024-09-17 16:38:07

Bloke wrote #337867:

Custom fields of different types is very much part of the plan. In fact, it’s coded already and, not only does it let you define the type, it stores its data in the most efficient way possible under the hood, which is something no other CMS does, as far as I’m aware.

On top of this, what you seem to be after is dependent custom fields. That’s interesting and not something I’d yet considered, beyond the fact that each can be grouped into a family. To do that requires JavaScript to toggle fields on and off, and honestly, the only ones it applies to are (single) checkbox, radio and select field types as the ‘controlling’ field.

I guess the JS code could be fairly standard, but we’d have to have some conventions in place such that the ‘controlling’ field must be opt in, i.e. it needs to always be “add such and such” not “hide such and such”. Because otherwise the logic would need to be flipped and that’s going to make it harder to manage the code.

Leave this with us and we’ll see what’s possible.

yummy!!!!

giz · 2024-11-08 19:45:22

This release of Textpattern deserves an admin interface which is equally flexible and modernised.

Improve the css class naming system of many of the layout containers i.e. .txp-layout-4col-alt or .txp-layout-4col-3span to something more descriptive.
- Currently these selectors appear in different contexts with differing functions, meaning you have to resort to css selectors like .txp-layout:has(> .txp-layout-1col:first-child) to distinguish between general listing pages and say the edit_image tab. This would be a huge help in writing simpler, leaner, easier admin-theme css.
- I’d love to see admin-themes/themename/themename.php used to specify/append-to the classnames of many key elements in the interface (or a BEM-style the class naming system).
Use native html widgets eg. <details> instead of jqui widgets.
Refactor and simplify occurrences of jqui css; it’s from another era and is brittle. The icons alone account for a major chunk of the css payload, and many aren’t used.
Remove the Dark/Light mode widget, and leave the user to control their preferences via their device settings.
Improve the layout so that it is responsive to all viewport sizes — and more flexible so developers can add content anywhere without overt layout glitches.

Bloke · 2024-11-08 20:25:40

@giz. On board with all that. I’d love to dump jQuery and jQuery UI.

etc · 2024-11-09 09:18:24

Bloke wrote #338175:

@giz. On board with all that. I’d love to dump jQuery and jQuery UI.

I guess we all are. Now who has time/skills for such a massive refactoring? Any good will is more than welcome to submit prototypes.

We have already started some improvements: core css rules/variables, light-dark() colour schemes, etc. But many UX features currently are admin theme related, which makes difficult altering them in core without implying theme authors. For example, the Dark/Light widget is only present in Hive themes, core just tries to follow.

phiw13 · 2024-11-09 09:32:27

Bloke wrote #338175:

I’d love to dump jQuery and jQuery UI.

Yes, sure. That is lots of work for jQuery, including the menu system.

But jQuery UI for sure. Some small first step: remove the use of JQUI for the “format: textile” select widget on the Write panel, above the body/excerpt textarea. The styling already exists in the theme stylesheet, see the language selector at the top of the login panel.

html 
<p class="login-language txp-reduced-ui"><label for="lang">Language</label>
<select name="lang" id="lang" data-submit-on="change">
<option value="en-gb" dir="auto" selected="selected">English (British)</option>
<option value="es" dir="auto">Español</option>
<option value="fa" dir="auto">فارسی</option>
<option value="fr" dir="auto">Français</option>
<option value="ja" dir="auto">日本語</option>
</select>
</p>

I regularly see that widget jumping slightly on page load, waiting for jQUI to finish (there is lots of js at work on the panel)

phiw13 · 2024-11-09 09:40:12

giz wrote #338174:

This release of Textpattern deserves an admin interface which is equally flexible and modernised.

Got those txp-layout-** classes: perhaps it might make more sense to add some classes, for exampe, the large .txp-layout-4col-3span column containing the editing area on the Write, Forms, pages, … panels, one could add a class txp-editor-container.

The Edit Image panel should be change to adopt a layout similar to the Edit Plugins, or Forms, …) panels - the large editor column on the left.

The icons: plan is to move them to the new core textpattern/textpattern.css. The list could surely be pruned. If you feel like, suggestions welcome, I guess.

etc · 2024-11-09 10:23:04

phiw13 wrote #338177:

But jQuery UI for sure. Some small first step: remove the use of JQUI for the “format: textile” select widget on the Write panel, above the body/excerpt textarea. The styling already exists in the theme stylesheet, see the language selector at the top of the login panel.

Good idea, but how to style it so that it takes the width of the selected option?

giz · 2024-11-09 20:19:21

Happy to contribute :) Note: Textpattern is a black box for me, and I’m crap at javascript.

Initially as an excuse to learn more about demanding usage cases of css grid and subgrid, I’m working on a new admin theme, starting from scratch. My aim is to introduce a grid-based paradigm which plays well with the existing nomenclature, and allows for elements to be distributed according to the author’s whim.

An initial prototype is 80% there¹, but I’m battling deeply nested divs which need to be coerced into acting as grid children i.e. copious display: contents; selectors. I don’t know of any other way around the issue without breaking compatibility :(

¹ 37kB nested output, uncompressed

I feel the best way forward is to prepare a document which identifies all the various nodes used throughout the interface, their classnames, ids and node ancestry. We need to identify patterns in the structure so the sass can follow suit. Does a document like this already exist?

Icons

How about using icomoon to generate a Textpattern icon font; I used it a while ago and found it removes much of the pain in dealing with icons. However we deal with them, I’m all for limiting the use of icons in the interface — particularly where they are redundant (appear together with a label); less is more :p

Ajax

The majority of issues I’ve had with client websites have occurred since AJAX saving was introduced (mostly write panel + bot_write_tab_customise glitches). The question needs to be asked: do we need it? It adds unnecessary complexity when most users wouldn’t notice the difference between an AJAX and full page refresh.

etc wrote #338179:

Good idea, but how to style it so that it takes the width of the selected option?

With a clean css slate, it can do this automatically.

Bloke · 2024-11-09 21:01:50

giz wrote #338180:

a document which identifies all the various nodes used throughout the interface, their classnames, ids and node ancestry.

I swear we (or maybe I) started one in the 4.3 era when were sanitising class names. But it’s probably been lost in the mists of time and various doc hosting moves.

etc · 2024-11-09 21:48:13

giz wrote #338180:

An initial prototype is 80% there^1^, but I’m battling deeply nested divs which need to be coerced into acting as grid children i.e. copious display: contents; selectors. I don’t know of any other way around the issue without breaking compatibility :(

It does not absolutely need to be bwc, we are on a txp5 thread here.

The majority of issues I’ve had with client websites have occurred since AJAX saving was introduced (mostly write panel + bot_write_tab_customise glitches). The question needs to be asked: do we need it? It adds unnecessary complexity when most users wouldn’t notice the difference between an AJAX and full page refresh.

AJAX preserves undo/redo history and cursor position, among other things. Sure, it also makes preserving js listeners and so on less trivial, but there should be a way.

With a clean css slate, it can do this automatically.

Curious to see it.

Textpattern CMS support forum

#31 2024-09-13 12:51:58

Re: RFC: Textpattern 5 ideas & feature requests

#32 2024-09-13 17:40:54

Re: RFC: Textpattern 5 ideas & feature requests

#33 2024-09-13 18:50:01

Re: RFC: Textpattern 5 ideas & feature requests

etc wrote #337855:

#34 2024-09-16 01:19:53

Re: RFC: Textpattern 5 ideas & feature requests

#35 2024-09-16 05:12:27

Re: RFC: Textpattern 5 ideas & feature requests

#36 2024-09-17 16:38:07

Re: RFC: Textpattern 5 ideas & feature requests

Bloke wrote #337867:

#37 2024-11-08 19:45:22

Re: RFC: Textpattern 5 ideas & feature requests

#38 2024-11-08 20:25:40

Re: RFC: Textpattern 5 ideas & feature requests

#39 2024-11-09 09:18:24

Re: RFC: Textpattern 5 ideas & feature requests

Bloke wrote #338175:

#40 2024-11-09 09:32:27

Re: RFC: Textpattern 5 ideas & feature requests

Bloke wrote #338175:

#41 2024-11-09 09:40:12

Re: RFC: Textpattern 5 ideas & feature requests

giz wrote #338174:

#42 2024-11-09 10:23:04

Re: RFC: Textpattern 5 ideas & feature requests

phiw13 wrote #338177:

#43 2024-11-09 20:19:21

Re: RFC: Textpattern 5 ideas & feature requests

Icons

Ajax

etc wrote #338179:

#44 2024-11-09 21:01:50

Re: RFC: Textpattern 5 ideas & feature requests

giz wrote #338180:

#45 2024-11-09 21:48:13

Re: RFC: Textpattern 5 ideas & feature requests

giz wrote #338180:

Board footer