Here's a slightly more funky approach to the hook system we have today.
Right now a mod runs its hooks during install and they're added to the list of hooks to be run. But what if we got to the point where a plugin couldn't do file edits (because hooks allowed for everything), and you could disable a plugin by way of simply renaming the folder?
Got a bad plugin that breaks your site? Rename the folder, plugin is instantly disabled.
The solution basically is to prevent mods registering their hooks permanently, and instead listing the hooks they use in some kind of registry, which are then activated if the plugin is listed as enabled, at which during startup the hooks are engaged.
You'd want to have a plugins folder (I'd prefer not to use the Packages folder for this, for avoidance of confusion), where the plugins live, each plugin to one folder, and perhaps keep the folder name in a list of 'enabled plugins' somewhere.
It also means uploading a plugin can be simplified somewhat and that unpacking a bare GitHub repo should be easier.
This worked pretty good in Wedge, for the record.
If you want to do that, you might as well go the whole hog and do it with way phpBB does it: add the ability to switch plug-ins on and off from admin. That works, and is pretty much muppet-proof AFAICT.
(Although, being a bit of a code junkie anyway, because there's simply no sane way of customising presentation effectively without hacking code, I also do rather like mods that edit code directly, for some cases.)
That's what we did in Wedge in 2012, you press a button to enable it, job done - and if it breaks you have a safety valve to fix it without doing half the things SMF folks have to deal with...
As for plugins that edit markup, XF solved this a literal decade ago whereby they do find/replace in the template, but save it as a new revision to the template in the database where it gets added to the history so you can see what was added, and revert if it does something funky.
Quote from: Arantor on April 09, 2022, 09:15:27 AMYou'd want to have a plugins folder (I'd prefer not to use the Packages folder for this, for avoidance of confusion), where the plugins live, each plugin to one folder, and perhaps keep the folder name in a list of 'enabled plugins' somewhere.
If I understood this correctly, Ipb has it like this. They have separated folders for plugins and applications and it makes things indeed much easier on both ends, from the admin side as well as from the users side.
Quote from: Arantor on April 09, 2022, 04:34:48 PMAs for plugins that edit markup, XF solved this a literal decade ago whereby they do find/replace in the template, but save it as a new revision to the template in the database where it gets added to the history so you can see what was added, and revert if it does something funky.
That sounds kinda cool. Could get a bit cluttered if there are a lot of edits, but nifty concept for sure. But in general I think the idea of not editing code directly is a good one. I just think there are some limited cases where (even if it's only for your own use) direct editing of code can still make sense.
I really dislike templates in the database...
I may have misunderstood, but I had the impression it was only the "revisions" that were stored in the db. If it's a case of all templating being in the db then yes, I would totally agree.
Stop fretting about implementation details. Consider the viability of the bigger picture first.
lol, you missed the subtext -- since the only complaint I made was regarding templates in the database -- I have no other issues with the suggestion. :P
That's the problem, though, you pitched it as though you didn't care about the actual point and only pointed to a perceived negative (that isn't really a negative).
And, honestly, right now fretting over the details is the last thing we should be doing: we should collectively be setting the high level goals and worrying about the implementation *later* of how a tiny portion of a thing should work.
The current debates about the customs form mod causing issues (irrespective of cause) and the hard work required to disengage the mod in question demonstrates why this feature is relevant.
Quote from: Arantor on April 09, 2022, 09:15:27 AMGot a bad plugin that breaks your site? Rename the folder, plugin is instantly disabled.
WordPress has this feature, and I for one agree it would be a nice idea for SMF.
But then, all mods would have to make a folder to do this, and what about some mods that copy files into multiple folders?
You put the entire mod in a single folder, and have whatever folders you like under this, like WordPress does. The largest WP plugins don't put everything in one folder...
It requires some actual design and thinking to design a mod system that can do this - and work to migrate plugins to it but honestly, worth the effort. And it's not like this hasn't been done on an SMF style base - both Wedge and StoryBB achieved this.
The basic idea sounds good to me. Details aside, I especially like the idea of making it simpler for users to control hooks even if they couldn't get to the admin panel.
Well, the key point is that you don't manage the hooks directly (as in the current model), you let SMF do that. The only user facing end of this is "plug-in enabled or disabled" and the latter is done with a rename of the folder.
Maybe I should have said "simpler for users to disable installed mods", but yes I got the point I believe :)