YesNoOk
avatar

Plugins (Read 5146 times)

Started by Nightwish, July 15, 2012, 14:58:44

0 Members and 1 Guest are viewing this.
Share this topic:
#1
Plugins |
July 15, 2012, 14:58:44
A short overview about plugins
In EoS, plugins work very similar as they do in WordPress. Plugins must be installed into a specific directory (right now, it's $boarddir/addons) and each plugin must live in its own sub-directory, so $boarddir/addons/testplugin is a valid plugin location. A plugin must define a main.php file, which is used by the plugin loader to initialize it for activation. Inside main.php, the plugin must define a class which must inherit from EoS_Plugin.

Activation / Deactivation
These are simple procedures. On activation, all the hooks exported by the plugin's class are activated and when a plugin is deactivated, the hooks are removed, thus, an inactive plugin will never execute any code. Only properly installed plugins can be activated.

Install / Uninstall
Some plugins may require additional steps before they can become active. For example, adding database tables or initializing configuration settings. Therefore, additional custom code might need to run when a plugin is installed for the first time. Whether or not a plugin requires installation is defined in the plugin's main class - simple plugins can indicate they do not require any custom installation steps and such plugins can be activated without installation.

The admin UI will deal with these things accordingly.

Can a plugin consist of multiple php files?
Well, of course. The only requirement is the main.php file which must implement your plugin's main class (inherited from EoS_Plugin). Hooks are allowed to refer functions in other files as long as they are located inside your plugin's main directory (sub-directories are allowed, should you really need them).

Plugins vs mods
Plugins are solely based on hooks. A plugin cannot modify existing code which should be desirable behavior anyway. Most problems with mods come from incompatible code modifications (e.g. one mod changes Subs.php in a way that breaks the installation of another mod).

Will EoS Alpha support mods in the classical (SMF-style) way?
Unknown at this time. I tend to avoid mods that modify existing code as much as possible, because of the vast source of problems (including major security issues) they can cause. However, it should also be clear that no hook-system can fully replace the flexibility that can be reached through code modifications. The final decision will thus be made at a later time.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
2 Like It 
#2
Re: Plugins |
July 16, 2012, 10:39:29
On the matter of installing mods: There is git. Think about it, mod = branch.

Installing a mod:
  git remote add
  git fetch
  git merge --no-ff

Uninstalling:
  git reset -m 1

This is a lot easier for developers than maintaining those diff-xml files, safer for users, and you get dependency tracking and conflict resolution for free. Now having this as the only way to add functionaliy to a forum would be too difficult for many users, but if there are plugins for basic stuff and git-branches for experts that seems like a good compromise for me.
#3
Re: Plugins |
July 18, 2012, 09:40:11
Well, using a full-featured version control system for managing mods certainly has some advantages and I'm pretty sure, experienced developers would prefer it over the current system (which I did never really like by the way).

I'm aware that not everything is possible with plugins - no matter how many hooks are available, it will always be limited vs. the ability to modify the core code. However, a good plugin system can be sufficient for most things.

However, relying on a complex system like git for installing mods is probably something a lot of users are not going to like, because what looks easy in the eyes of an experienced developer can be one hell of a task for a user.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#4
Re: Plugins |
July 25, 2012, 20:40:44
Should this feature work, yet? I wrote a plugin and activated it, so far so good, but it was never called, and when I looked for it I couldn't find any code that would load a plugin outside the plugin admin area. Am I doing something wrong, or is this still a work in progress?
#5
Re: Plugins |
July 25, 2012, 21:50:22
Should this feature work, yet? I wrote a plugin and activated it, so far so good, but it was never called, and when I looked for it I couldn't find any code that would load a plugin outside the plugin admin area. Am I doing something wrong, or is this still a work in progress?
It should work (I already have a few simple plugins working, like the github feed block in the side bar).

Plugins must use hooks to execute code, so it's a matter of choosing the proper hook to inject your code into (and yes, I know, there are way too few hooks at the moment, making some more advanced plugins impossible).

Look at addons/gitfeed/main.php for a very simple plugin.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#6
Re: Plugins |
July 26, 2012, 00:43:02
Got it.

addHook() used updateSettings($change_array, true); which uses an UPDATE query instead of REPLACE INTO - which doesn't work if integration_hooks isn't already present. Maybe use updateSettings($change_array, false) there, performance is certainly not an issue for hook installation :)

There should be more feedback in the installation procedure, perhaps an array_diff output showing how hooks changed or something, although all of that is probably in the pipeline already ;)
Last Edit: July 26, 2012, 00:45:09 by Valodim
#7
Re: Plugins |
July 26, 2012, 06:38:38
There should be more feedback in the installation procedure, perhaps an array_diff output showing how hooks changed or something, although all of that is probably in the pipeline already ;)
Hook installation will probably be logged in some way. Errors like duplicate hooks or non-existing files/callables are already logged to the error log, but on success, nothing happens (yet).

Also, if an error occurs during hook installation, the entire plugin should be deactivated to avoid more serious problems. That's also planned. Right now, it is possible to end up with a partial plugin installation, which is bad.

There is also a (currently inoperative) hooks tab which will allow to browse hooks by plugin, by hook type and so on..
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork