Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Active On, Status No
phiw13 wrote #334791:
I modified a plugin. But I don’t see any ‘Modified’ label added.
Found the bug, sorry. The modified string was only getting added if there was a new version available. It now shows all the time if the plugin is changed.
I also added a revert to installed code multi-edit option.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Active On, Status No
Bloke wrote #335151:
Found the bug, sorry. The modified string was only getting added if there was a new version available. It now shows all the time if the plugin is changed.
I also added a revert to installed code multi-edit option.
Both now work as intended.
The modified bubble is now more visible than it was on 4.8.8, which is a nice benefit.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Active On, Status No
Bloke wrote #335151:
Found the bug, sorry. The modified string was only getting added if there was a new version available. It now shows all the time if the plugin is changed.
I also added a revert to installed code multi-edit option.
These seem to concern only the ‘main’ php file, but is of limited use for bundled plugins atm. Moreover, the code is reverted only (?) in db but still loaded from fs. The ‘restore’ field should contain a snapshot and revert the whole bundle, dunno how.
Offline
Re: Active On, Status No
True. I did wonder about that when I added it. Restore is from last installed version in the DB, not from disk.
But then the Modified indicator is only regarding the PHP code. So even if it was to somehow ‘revert’ all the disk stuff (which is prone to error imo) then we’d need to alter the meaning of Modified in this context.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Active On, Status No
I’m not sure this plugin edit functionality is of much use in its present state and would delegate it to plugin composer, once the latter is patched.
Offline
Re: Active On, Status No
Maybe. But if there’s any functionality from plugin composer we can bring to core, I’d prefer that I think. Umm, maybe.
Thinking out loud, the composer was only really necessary because there was no disk access, and bundling plugins was complicated. If we tweak the zem_tpl.php generator to spit out raw Textile and (optional) compiled help in separate array elements then we can simply stash them on disk in .textile and .html files on installation.
That gives us the ability to add a help edit box on the Plugin Edit step which will either load in the textile file if it exists and recompile it to HTML on save, or the HTML file for direct editing if that’s not available.
Then all we need are a few radios for plugin type, etc on that screen and maybe a way to rename the plugin. And add an ‘export’ option to the multi edit tool, perhaps. That’s 75% of the Plugin Composer done and dusted in core without much more overhead. The only hard bit is the textpack strings.
Thoughts?
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Active On, Status No
Yep, this would be even better. IIRC, core already splits plugins in parts and stores them on disc (needs confirmation).
Offline
Re: Active On, Status No
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).
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Active On, Status No
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…
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Active On, Status No
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)
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Active On, Status No
Good call on the layout. I’ll go for option 2 and add class code too. Thank you.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Active On, Status No
Bloke wrote #335209:
Good call on the layout. I’ll go for option 2 and add class
codetoo. Thank you.
👍🏽
PS – For the meta-data part, see the Edit image panel.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline