Active On, Status No

phiw13 · 2023-02-27 06:26:21

Bloke wrote #334790:

[…] the only thing you’ll see is ‘Modified’ added to the Version column. The upgrade is only validated on compatible version number differences.

Ok, I understand. One thing though: I modified a plugin. But I don’t see any ‘Modified’ label added. Just me ?

Bloke · 2023-02-27 09:39:49

phiw13 wrote #334791:

I modified a plugin. But I don’t see any ‘Modified’ label added. Just me ?

Curious. I just went into one of my installed plugins via the Plugins panel, added a random space to the plugin source code and hit Save. The ‘Modified’ warning appeared alongside the version tag immediately. Hmmm.

Oddly, though, if I go in and remove the same space, the Modified warning doesn’t go away. Further, there appears to be no way to restore a plugin to its original state. I’m sure we used to have a multi-edit option or something that allowed plugins to be rolled back to the old version stored in the DB’s code_restore column.

We could maybe add that as a hyperlink on the ‘Modified’ text but it’s perhaps a bit too easy then to roll back by mistake. Maybe multi-edit is better. There’s an ‘Update from drive’ option but I assume that’s primarily for pulling code in if you’re editing it outside of Textpattern for version control reasons.

Last edited by Bloke (2023-02-27 09:42:11)

phiw13 · 2023-02-27 11:21:56

Yes, curious. This testing was all with plugins that were installed (some modified) before the latest round of changes. Tomorrow I’ll test on another install and install some plugin first, then modify it.

etc · 2023-02-27 12:24:59

phiw13 wrote #334791:

I modified a plugin. But I don’t see any ‘Modified’ label added. Just me ?

Me too, neither ‘code restore’ link. I’ve tested it on the dev demo site (works on release).

Bloke · 2023-02-27 12:48:02

I must have screwed something up then somehow. But the code for detecting changes hasn’t been touched. Just moved a few lines further. 🤔

Incidentally, the code for detecting changes is a simple md5. When a plugin is installed, the restore version is cached in the DB and an md5 of it is stored in a separate column. Each time you view the panel, the real code column is run through MySQL’s MD5 function and compared to the md5 stored in the DB.

What’s odd is I can open a plugin in the Txp admin side and hit save without making any changes and the MD5 function calculates a different value to the one stored, so the Modified appears. Maybe saving strips off trailing spaces, or changes line endings or something.

phiw13 · 2023-02-28 00:25:55

From this GH commit :

Slight issue: plugins that have Options and upgrades available leave a gap where the Options should go. Toggle only alters visiblity, not display so the space doesn’t collapse.

Question: is there any reason why this particular toggle is set to visibility:hidden when the plugin is inactive? Setting to display:none would solve the issue above, and I don’t see any reason why not doing it.

Bloke · 2023-02-28 00:41:22

I think display: none would be preferable. Just didn’t want to alter it in case it broke anything else. Plus the JavaScript handler would probably need tweaking.

phiw13 · 2023-02-28 01:51:14

Bloke wrote #334818:

I think display: none would be preferable. Just didn’t want to alter it in case it broke anything else. Plus the JavaScript handler would probably need tweaking.

display: none then!

Why would the JS handler need tweaking? the visibility or display is controlled in the stylesheet, the JS just adds or removes the .active class on the row.

tr .manage span, tr .plugin-prefs {
  visibility: hidden;
}
tr.active .manage span, tr.active .plugin-prefs {
  visibility: visible;
}

I don’t think the 1st selector (.manage) is ever used. This could be simplified…

tr:not(.active) .plugin-prefs { display: none; }

Last edited by phiw13 (2023-02-28 01:52:20)

Bloke · 2023-03-01 22:03:54

Thank you, that seems to work a treat. Committed.

I haven’t pushed it to Phil’s main repo because I don’t have write access, and haven’t got a GitHub-based clone of it so can’t make a PR right now. I’ve opened an issue instead and added the diff patch there.

Bloke · 2023-03-22 01:11:32

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.

phiw13 · 2023-03-22 05:28:53

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.

etc · 2023-03-22 09:46:07

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.

Bloke · 2023-03-22 11:19:51

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.

etc · 2023-03-22 12:56:23

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.

Bloke · 2023-03-22 14:24:55

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?

Textpattern CMS

Textpattern CMS support forum

#16 2023-02-27 06:26:21

Re: Active On, Status No

Bloke wrote #334790:

#17 2023-02-27 09:39:49

Re: Active On, Status No

phiw13 wrote #334791:

#18 2023-02-27 11:21:56

Re: Active On, Status No

#19 2023-02-27 12:24:59

Re: Active On, Status No

phiw13 wrote #334791:

#20 2023-02-27 12:48:02

Re: Active On, Status No

#21 2023-02-28 00:25:55

Re: Active On, Status No

#22 2023-02-28 00:41:22

Re: Active On, Status No

#23 2023-02-28 01:51:14

Re: Active On, Status No

Bloke wrote #334818:

#24 2023-03-01 22:03:54

Re: Active On, Status No

#25 2023-03-22 01:11:32

Re: Active On, Status No

phiw13 wrote #334791:

#26 2023-03-22 05:28:53

Re: Active On, Status No

Bloke wrote #335151:

#27 2023-03-22 09:46:07

Re: Active On, Status No

Bloke wrote #335151:

#28 2023-03-22 11:19:51

Re: Active On, Status No

#29 2023-03-22 12:56:23

Re: Active On, Status No

#30 2023-03-22 14:24:55

Re: Active On, Status No

Board footer