Active On, Status No

etc · 2023-03-22 16:04:03

Yep, this would be even better. IIRC, core already splits plugins in parts and stores them on disc (needs confirmation).

Bloke · 2023-03-22 16:32:34

It does. And in fact there already seems to be both raw and cooked help files, so the template compiler doesn’t need changing (beyond the changes I made yesterday to fix the textile capability).

Bloke · 2023-03-31 00:17:48

Tentative support for full plugin editing has landed. It needs strings in a few places, and somebody needs to go through to figure out how to lay it out better to avoid all that whitespace on desktop. Maybe rejigging some of the field orders too. But in theory, it’s now possible to edit every plugin field, and even rename plugins… sort of.

The issue with renaming is that if you choose a name that already exists, it unceremoniously dumps you back on the edit panel and undoes all your edits (because it re-reads the plugin data from the filesystem). Anyone who fancies tackling that, be my guest.

Changes should stay in sync between DB and disk, even on multi-edit actions like change load order. The only possible issue is that if you delete the disk copy by hand, it still shows up in the database but none of the fields will be filled in with data – it reads everything from disk. Might need to add a fallback that if it can’t find the disk-based data then it looks in the DB for it.

One other thing that is mystifying me… the Code textarea is limited to a fixed height but the Help and Textpack areas autogrow to fit the content. That’s most undesirable, imo. Even though you can CTRL/CMD-S to save, it’s still a pain to have to scroll down and down and down to get to the Textpack block. If anybody has any idea why it does this, please enlighten me.

If anything in the help block is changed, it will recompile it to HTML for you on save. This means an appreciable delay when saving – depending on how big the help block is – and it will probably always do it on first save, but after that it does only do it if you make help file changes, so it’s not massively onerous.

I haven’t yet added the export functionality to compile plugins for distribution. Will look into that. But for now, this is probably 90% of Plugin Composer functionality baked into core. Please give this a play. If anybody can make any performance improvements or code tweaks to cut down on repetition, please do so.

Incidentally, it uses the new UI library to render most of the Edit panel. Mmmmmm…

phiw13 · 2023-03-31 01:37:05

somebody needs to go through to figure out how to lay it out better

Just had a very (very !) quick look – and no testing.

For the layout,

Options 1: why not reuse the default/standard edit panels (e.g Files or Categories)? Wrap the whole thing in a div class="txp-edit" and 85% of the work is done.

Option 2, copy the “Pages” and “Forms” panels. The meta data fields in the narrow column, your 3 textareas in the large column. Bonus the save button is sticky at the top of the page.

The autogrow thing prolly the script thingie I have that disabled in the install that uses Hive.

Edit

based on the autosize.js, if you give all those textareas the class .code, they won‘t grow anymore
the more I look at that edit panel, Option 2 above is the way to go.

Last edited by phiw13 (2023-03-31 02:13:48)

Bloke · 2023-03-31 06:52:09

Good call on the layout. I’ll go for option 2 and add class code too. Thank you.

phiw13 · 2023-03-31 09:39:03

Bloke wrote #335209:

Good call on the layout. I’ll go for option 2 and add class code too. Thank you.

👍🏽

PS – For the meta-data part, see the Edit image panel.

Bloke · 2023-03-31 16:40:09

Slight snag with option 2 (Pages/Forms layout) is that it’s designed such that the <form> is in the bigger area. The smaller sidebar is only for switching content and isn’t part of the form submission itself. In the Plugin panel case, all fields need to be in the form.

I’m not sure if it’s possible to hack it so the form spans the two div containers, e.g.

<form class="txp-layout">
   <div class="txp-layout-4col-3span">
       // main 3 textareas
   </div>
   <div class="txp-layout-4col-alt">
      // smaller form fields in here
   </div>
</form>

If I can figure it out, I’ll try that. If not, we may have to fall back on a layout like in the Images panel.

EDIT: Oooh, it seems to work okay.

Last edited by Bloke (2023-03-31 17:15:22)

Bloke · 2023-03-31 19:19:48

I’ve tweaked the layout as a sort of hybrid between the Pages and Image Edit panels.

The save/cancel buttons are rendering a little oddly. Not entirely sure how to fix that at present: I’ve probably missed a class name. Edit: I did.

I also need to push some changes to the UI library so CheckboxSets (and probably RadioSets) can take some optional glue – such as non-breaking space – to avoid them rendering strangely.

Last edited by Bloke (2023-03-31 23:12:18)

phiw13 · 2023-04-01 02:05:54

A quick look on dev demo site – looks good I think.

A non-breaking space between checkbox and <label /> ?

Bloke · 2023-04-01 06:19:02

phiw13 wrote #335230:

A non-breaking space between checkbox and <label /> ?

Yes but it needs to be done in the UI library. Gotta figure out how to do that

Bloke · 2023-05-01 10:07:05

phiw13 wrote #335230:

A non-breaking space between checkbox and <label /> ?

This is really annoying me. I’ve just pushed a commit that changes the way checkbox and radio sets are rendered. Instead of being two side by side elements, I’m wrapping the input and its associated text in a <label> tag. The theory being that if they’re wrapped like that, they might stay together, as the browser considers them as a unit.

Nope. It renders this markup:

<div class="txp-form-field-label">
    <label for="flags">flags</label>
</div>
<div class="txp-form-field-value">
    <label for="flags-1"><input class="checkbox" id="flags-1" name="flags[]" type="checkbox" value="1">&#160;plugin_has_prefs</label>
    <label for="flags-2"><input class="checkbox" id="flags-2" name="flags[]" type="checkbox" value="2">&#160;plugin_lifecycle_notify</label>
</div>

That looks right to me (although maybe the for attribute is redundant in this construct? Not sure on the correct usage) but the checkbox still appears on its own, and the label wraps to the next line on the second pairing. Baffled. Maybe there’s some admin CSS that’s overriding this and preventing the nbsp from taking hold? Any ideas why this may be occurring and what we can do about it?

If we can get it working at the UI library level here, I’ll consider adding some $glue parameter, or repurpose the break property perhaps in CheckboxSet/RadioSet so it acts as the join between input and label.

Side note: is the approach of wrapping the input and label in a <label> tag good practice? Or is it better if they’re separate and side-by side, as it was? Or is there any other markup we can consider that would help lay this out in a satisfactory manner?

phiw13 · 2023-05-01 11:43:14

(i haven’t tried your recent commit yet)

Side note: is the approach of wrapping the input and label in a <label> tag good practice?

Yes, that is a good (and valid) practice – and in this case, it will help solve the issue.

Given the label tag wrapped around both radio/checkbox and label-text, add this to your custom.css ( or add to textpattern.css)

label[for*="flags-"] {display:inline-block; background: cyan;}

(or check the mock-up here)

There might still be problems, e.g. with a language where the string is long without spaces.

Technically, the for attribute is not needed in that case/pattern, but it doesn’t hurt to leave it.

BTW: in this

<div class="txp-form-field-label">
    <label for="flags">flags</label>
</div>

the <label for="flags"> is not needed (and can be confusing for AT I suspect), you set the <label /> directly around the radio/checkbox – see the pattern on the Preferences panel.

–^–

PS – for the whole plugin edit panel, you need to make your the for attribute on the <label /> has a corresponding id attribute on the <input /> or <textarea /> – both need to be the same value. Currently the id are all missing.

Or is that an issue with the new UI-widget library? I now see the same problem on other recently updated panels.

Bloke · 2023-05-01 11:57:37

Ah okay thanks. So maybe something in our stylesheet is stopping it wrapping, or something needs explicitly adding to make a non-breaking space not break! I’ll add your CSS and give it a whirl. The only thing I’d prefer is if we could not specifically target these elements but make a wrapper class that we can hook into so the CSS pattern can be applied elsewhere.

Regarding, the for, I think it adds that automatically if we pass in an ID to the constructor, but I wonder if it’s adding it when one hasn’t been supplied. I’ll check that, thanks for the sanity check. It’ll be a UI library thing I need to chase down.

Bloke · 2023-05-01 12:07:20

Oooh, one other thing. As it stands, I’ve got:

input.sp.label

inside the <label> tag wrapper. That’s hard coded for now and I may expose the separator as mentioned above. Or maybe if the CSS tweaks fix it, the nbsp might not be needed at all.

Either way, if one were to pick an RTL language, would that practice break things? Or is the browser clever enough to reverse the order of elements?

Maybe separating them like they were is better? Or adding some markup to them to indicate how to treat them in RTL cases is necessary? I know we have a bunch of RTL rules in our stylesheet so maybe that covers it. Best practice here is a bit outside my sphere of knowledge.

Last edited by Bloke (2023-05-01 12:08:50)

phiw13 · 2023-05-01 12:14:11

Either way, if one were to pick an RTL language, would that practice break things? Or is the browser clever enough to reverse the order of elements?

Do nothing and let the browser do the necessary magic!

Ref the non-breaking space, if you go with the suggested markup (<label /> around radio/checkbox) you can omit it I think.

Textpattern CMS

Textpattern CMS support forum

#31 2023-03-22 16:04:03

Re: Active On, Status No

#32 2023-03-22 16:32:34

Re: Active On, Status No

#33 2023-03-31 00:17:48

Re: Active On, Status No

#34 2023-03-31 01:37:05

Re: Active On, Status No

#35 2023-03-31 06:52:09

Re: Active On, Status No

#36 2023-03-31 09:39:03

Re: Active On, Status No

Bloke wrote #335209:

#37 2023-03-31 16:40:09

Re: Active On, Status No

#38 2023-03-31 19:19:48

Re: Active On, Status No

#39 2023-04-01 02:05:54

Re: Active On, Status No

#40 2023-04-01 06:19:02

Re: Active On, Status No

phiw13 wrote #335230:

#41 2023-05-01 10:07:05

Re: Active On, Status No

phiw13 wrote #335230:

#42 2023-05-01 11:43:14

Re: Active On, Status No

#43 2023-05-01 11:57:37

Re: Active On, Status No

#44 2023-05-01 12:07:20

Re: Active On, Status No

#45 2023-05-01 12:14:11

Re: Active On, Status No

Board footer