adi_matrix – Multi-article update tabs

phiw13 · 2025-02-18 02:17:07

Bloke wrote #339089:

I might try and get rid of the rows and stuff altogether in the plugin. It should be up to themes to style, right?

the cols and rows attributes, same as size or width and height for image and iframe, have basically a zero specificity so leaving them in won’t limit what a stylesheet can do.

That said, I don’t particularly object them having rows=3. Themes & custom.css can size those as they see fit.

By default, without cols and rows a textarea displays as something like 170px wide and 34px height in Safari , Firefox is a little bigger but with same aspect ratio – aprox. 2 lines tall (depends on font-size, and browser config). Demo here

jakob wrote #339088:

However … the textarea is still that high because it’s defined by rows="5" in the textarea attributes (which I guess is where the js is getting the height from). If you set it to rows="3" in adi_matrix, you’ll find you don’t need to switch off autosize.js.

You can turn off Hive autosize.js for specific textareas by including the class code on the textarea. The script is configured to explicitly ignore those¹ – see the textearea on the Pages/Forms/Edit Plugins.

–^–

¹ var e=document.querySelectorAll("textarea:not(.code)"); in the script. I had to look it up once to disable the Write panel growing textarea for a client.

phiw13 · 2025-02-18 02:24:58

Bloke wrote #339085:

Okay, I’ve done all these,

Thank you, I’ll test and enjoy later today.

And of course, I’m not sure what to do about the hive dark mode, so that’s pending further discussion, possibly with a mind to changeing core behaviour somehow. Does it need a 3rd switch option? Light, Dark, and Follow System? Maybe ditch the light bulb and add it as a proper pref three-way radio?

I don’t think you need to change Core behaviour, but Theme Hive behaviour. And I am uninterested in implementing such a switch in Sandspace.

phiw13 · 2025-02-18 06:52:11

A general usage question: Is the publisher role the only one to have permission to access the matrix_admin panel? My managing editor user does not / can not see that panel.
Related: If the above is correct and not a bug, then the newly added “edit” button on the matrix panel should not be visible to no-publisher roles.
Related to that “edit” button: use this pattern: (see Themes, Sections, users, etc panel, above the table).

<div class="txp-control-panel">
  <a class="txp-button" href="#">New theme</a>
</div>

Good work with the latest edits and changes, thank you.

Bloke · 2025-02-18 10:19:36

Oops, thank you. Yes, matrix admin is publisher only. Patched.

Bloke · 2025-02-18 10:27:35

phiw13 wrote #339091:

I don’t think you need to change Core behaviour, but Theme Hive behaviour.

Hmmm, without the concept of theme variable support in core, that’s going to be hard work.

Guess we have to live with it for now.

Bloke · 2025-02-18 10:33:46

I added a tentative Prefs link to the admin panel as a shortcut. I’ve put it before the matrix selection dropdown for now. Putting it after the select list made it seem too much like it was a “Go” button for the select list. And putting it beneath the matrix near the Save button seems too much like a random place for it and made it feel like it was a ‘cancel’ button or something.

Any improvements welcome. Is a link better than a button, since it’s, well, a link?

I’ve also messed about with setting a code class on the Keywords textarea and removed the cols attribute. 3 rows now, too. Is that better?

Last edited by Bloke (2025-02-18 13:17:28)

giz · 2025-02-18 19:13:05

Thanks, Bloke. I’ll poke it on my test site (which includes Hive 4.9 as an option)…

(I think link is better than button in this context – a button does stuff to the page, a link goes elsewhere).

In my efforts I’ve omitted the Dark/Light mode button as I find it redundant/cluttering; this functionality is better left to the user’s OS settings. How do others feel? Controlling Light/Dark mode is typically trivial in css — but there is a caveat; if plugin-injected css includes colour styling, there’s a good chance Light/Dark mode will break.

I did some digging on my textarea style attributes in a matrix: <textarea name="article_35[keywords]" cols="18" rows="5" class="mceNoEditor" style="overflow: hidden; overflow-wrap: break-word; resize: none; text-align: start; height: 135px;"></textarea>. Maybe .mceNoEditor offers an insight to how/where the injection is occurring?

Using 3 rows for textareas in a matrix works without any fuss :) On the other hand, Date and Time fields will always struggle to be compact, no matter the context. Sighs.

Last edited by giz (2025-02-18 19:13:33)

Bloke · 2025-02-18 21:18:38

giz wrote #339097:

(I think link is better than button in this context – a button does stuff to the page, a link goes elsewhere).

I concur so I’ll probably flip it to a link and stick it at the end of the matrix select dropdown.

In my efforts I’ve omitted the Dark/Light mode button as I find it redundant/cluttering; this functionality is better left to the user’s OS settings.

I think it’s reasonable to assume that if someone has set their operating system to auto-switch or always be dark or light, that apps track that setting likewise. However, I’ve seen many apps that offer the options of 1: Light, 2: Dark, 3: Follow system in their settings. i.e. very few at the app level have a dedicated switch to automatically track daylight hours, they just leave it to the system to pass that info along.

That gives users a good combination of options because they can override the OS light/dark mode that’s currently in force if they really don’t like the way a particular app has implemented their theme. But as you say, unless the app is careful in how it handles the rules, it can lead to weirdness like we have in this plugin where part of the UI follows the system while other parts take the app’s visual mode into account.

phiw13 · 2025-02-19 00:01:19

giz wrote #339097:

In my efforts I’ve omitted the Dark/Light mode button as I find it redundant/cluttering; this functionality is better left to the user’s OS settings. How do others feel? Controlling Light/Dark mode is typically trivial in css — but there is a caveat; if plugin-injected css includes colour styling, there’s a good chance Light/Dark mode will break.

That is why I suggested the use of a basic set of core custom properties(/textpattern/textpattern.css) but that still seems to break in Hive somehow.

Personally I much prefer the choice to be left to the OS, e.g if the user choice is “light mode”, use that and vice versa. If the user prefers has made the choice of automatically tracking day/night, respect that. It seems very strange to me to have your OS set to “dark mode” (“dimming”) but then to prefer a UI for a specific app to be display in light mode (back to “blinding”).

My biggest complain about 1Blocker is the app UI set to always dark. (and I have a horrible time trying to read anything in it. Luckily the application is very good at what it is designed to do, and accessing the app UI is something that I only need once every in a while).

I did some digging on my textarea style attributes in a matrix: <textarea name="article_35[keywords]" cols="18" rows="5" class="mceNoEditor" style="overflow: hidden; overflow-wrap: break-word; resize: none; text-align: start; height: 135px;"></textarea>. Maybe .mceNoEditor offers an insight to how/where the injection is occurring?

As noted above, that is Hive autosize.js. That inline style should be gone now that those textarea have .code class added.

Bloke · 2025-02-19 00:10:05

Haha, yeah, I have apps like that. Unusable in one mode or the other. You have kind of justified the reason for having an app-specific override, exactly like I posited: if an app like 1Blocker has a shoddy implementation of one particular mode, you could choose to override it so you at least have a chance to use it at all times of day. If they’d provided a switch.

But I agree that it is (and should be) an exception, as 99% of the time, apps should be well-designed enough that following the system mode works. Set and forget.

I wouldn’t lose any sleep if our lightbulb switch vanished in Hive, and Txp properly followed the system mode by default.

phiw13 · 2025-02-19 00:13:40

Bloke wrote #339093:

Oops, thank you. Yes, matrix admin is publisher only. Patched.

That is a little unfortunate… I would expect a managing editor to be allowed (as in, that is a person busy with the day-to day managing)

Bloke wrote #339098:

I concur so I’ll probably flip it to a link and stick it at the end of the matrix select dropdown.

As is at time of writing, first in flow is a little odd (main action on that panel is creating / managing matrices). Placing it after the select widget seen better. Possibly add some spacing between select combo and link-button? If the select combo comes first, set some margin-end on the <select />: #matrix_id { margin-inline-end: var(--txp-spacing, 1em); }.

phiw13 · 2025-02-19 00:16:16

Bloke wrote #339100:

Haha, despite not seeing a need for deviating from the OS setting, you have justified the reason for having an app-specific override, exactly like I posited: if an app like 1Blocker has a shoddy implementation of one particular mode, you could choose to override it so you at least have a chance to use it at all times of day. If they’d provided a switch.

No I see it as a bug that should be fixed, and I have reported it to the developers (“we’ll consider it”; and then they lost 1 star in the Appstore rating). If you consider that your app should override default OS behaviour, included that as an option.

Last edited by phiw13 (2025-02-19 00:18:34)

Textpattern CMS

Textpattern CMS support forum

#265 2025-02-18 02:17:07

Re: adi_matrix – Multi-article update tabs

Bloke wrote #339089:

jakob wrote #339088:

#266 2025-02-18 02:24:58

Re: adi_matrix – Multi-article update tabs

Bloke wrote #339085:

#267 2025-02-18 06:52:11

Re: adi_matrix – Multi-article update tabs

#268 2025-02-18 10:19:36

Re: adi_matrix – Multi-article update tabs

#269 2025-02-18 10:27:35

Re: adi_matrix – Multi-article update tabs

phiw13 wrote #339091:

#270 2025-02-18 10:33:46

Re: adi_matrix – Multi-article update tabs

#271 2025-02-18 19:13:05

Re: adi_matrix – Multi-article update tabs

#272 2025-02-18 21:18:38

Re: adi_matrix – Multi-article update tabs

giz wrote #339097:

#273 2025-02-19 00:01:19

Re: adi_matrix – Multi-article update tabs

giz wrote #339097:

#274 2025-02-19 00:10:05

Re: adi_matrix – Multi-article update tabs

#275 2025-02-19 00:13:40

Re: adi_matrix – Multi-article update tabs

Bloke wrote #339093:

Bloke wrote #339098:

#276 2025-02-19 00:16:16

Re: adi_matrix – Multi-article update tabs

Bloke wrote #339100:

Board footer