Skip to main content ↑ ↓
Topic: Addons directory (Read 8048 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Addons directory

We said something about wanting /forum_dir/addons.
But, we already have /forum_dir/packages.

Purpose of an "addons folder": to look for extra-controllers for actions, following naming patterns, in subdirs of addons installations. They might not even register an action (through a hook), but we can still find it.

Thoughts on reusing the same directory?
Point is, we already scan the directory for sub-dirs of 'mods' (they don't need to be archives). And you can install/uninstall/delete them.

The little good part about a directory at their disposal, is also that it's supposed to be a directory for which they don't need to copy/move files to install themselves, elsewhere. In case the forum uses only non-file-modifications addons. Only the addons dir needs to be writable.

I think I'm just trying to clarify my thoughts on the remaining course of action here. :)
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Addons directory

Reply #1 –

mmm...I think it would make sense...
Bugs creator.
Features destroyer.
Template killer.

Re: Addons directory

Reply #2 –

It works very well indeed ;)

Re: Addons directory

Reply #3 –

Quote from: Arantor – It works very well indeed ;)
Thank you :D

Oh, btw, I'm not suggesting we go all the way, with the unbelievable work you did on the direct upload! But yes, the simple thing to have a default known location and automatically find things, is just nice and handy to have.
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Addons directory

Reply #4 –

Well, the direct file upload stuff is going down a very deep and dark rabbit hole.

But just having a central place for things does solve a lot of headaches, though it creates others. That's why I ended up having loadPluginSource, loadPluginTemplate and loadPluginLanguage trio of functions, whose first parameter is the plugin id. (The idea is that a plugin should neither know nor care what folder their files are in, inside Plugins/)

Re: Addons directory

Reply #5 –


Quote from: Arantor – Well, the direct file upload stuff is going down a very deep and dark rabbit hole.
Argh, the idea is definitely challenging and interesting. What doesn't work?

QuoteBut just having a central place for things does solve a lot of headaches, though it creates others. That's why I ended up having loadPluginSource, loadPluginTemplate and loadPluginLanguage trio of functions, whose first parameter is the plugin id. (The idea is that a plugin should neither know nor care what folder their files are in, inside Plugins/)
Perhaps. But, is there an actual advantage to support them to only name differently folders with a clearly specified purpose? I mean, what does it bring, to a plugin writer, the possibility to name their /templates directory "bluemonkey"? When all the rest holds true: their templates are there and only there, and it's only the last dir name - not even the path.
Unless they drop their files without sub-directories. This should be a supported case.
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Addons directory

Reply #6 –

QuoteArgh, the idea is definitely challenging and interesting. What doesn't work?

Oh, it all works. It's just incredibly messy.

QuoteBut, is there an actual advantage to support them to only name differently folders with a clearly specified purpose?

That's not what I mean. Consider a plugin that adds an image file and that the image file is to be called via an <img> tag somewhere in some template.

How does the plugin know what folder it was uploaded to? Sure, it knows it was uploaded to Plugins/ somewhere, but that's all it knows. It doesn't know what folder within Plugins/ it was - and we have seen users who've put their forums into folders like smf_2-0_install (1)/ in the past through weird package naming conventions.

Consider also, if you have a plugin in a .zip package like myplugin_1.0.zip, would it not be logical to put that into myplugin_1.0/ in Plugins/ ? The problem then is how the plugin knows what the folder is.

So, what happens is that we do a check at startup of all 'enabled' plugins, validating that the path ties into a real existing folder and then associate the plugin id with its physical folder. From there we can always find the plugin's files or its URLs. And presumably a plugin isn't going to change its id so authors can always relate it properly.

Re: Addons directory

Reply #7 –

Ah. I see - I misunderstood earlier.

That raises other interesting problems. By the way, when you say "enabled", is that practically equivalent with "installed"?
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Addons directory

Reply #8 –

In SMF terms, yes. The files are present, but the plugin is not active until it is enabled - it is at that point the hooks are added to the list and whatnot.

Note that during startup, the list is examined and if the plugin does not apparently exist, its hooks are not registered. Means that disabling a plugin in the last ditch case is as simple as renaming its folder if things have truly gone south.

The architecture really isn't pretty but it's proven effective in our experience.