magic file for active/deactive handlers

[ewinslow]

I suggest this because I'm not super comfortable with the manifest being tied to the code. It seems odd that something that is primarily meant to provide metadata about the plugin is also being used to help bootstrap it.

Instead of explicitly registering a function in the manifest, what if we just have Elgg magically recognize the files activate.php and deactivate.php, just like it does already with start.php? This paradigm would be much more familiar to plugin developers, I think.

[cash]

I think I prefer this. Less work to add something for activation. We should make a call on this before 1.8 is released - even better before 1.8 beta.

[brettp]

Agreed. Let's pull it out. Will require changes to the valid fields in ElggPluginManifest* classes.

[cash]

I'm assigning to beta so it has our attention. I don't think it *has* to be done before a beta release. I'm not familiar enough with the plugin code to predict how much work it is. I wouldn't think it would be much.

[lie2815]

Can I take this on? Would be a nice way to get my hands dirty with plugin stuff (and I also had a look at it already and found it fairly simple).

Or do you guys think this would be too big for a newbie? ;)

[vazco]

Maybe it would be a good idea to simply define handler/hook in start.php for activate/deactivate method? This would follow approach used in Elgg modules untill now

[brettp]

Replying to lie2815:

Can I take this on? Would be a nice way to get my hands dirty with plugin stuff (and I also had a look at it already and found it fairly simple).

Or do you guys think this would be too big for a newbie? ;)

This is a bit involved, but give it a shot. Hit me up on IRC if you need help.

Replying to vazco:

Maybe it would be a good idea to simply define handler/hook in start.php for activate/deactivate method? This would follow approach used in Elgg modules untill now

That's not possible because the plugin isn't loaded (so not registered for any hooks) when it's activated. It would work for deactivating, but I'd rather keep the two system symmetric. The activation should be considered a bootstrapping or preflight script--It needs to do things without requiring the plugin itself.

[vazco]

Brett, if we launched activate command after:
trigger_elgg_event('plugins_boot', 'system');

and before:
trigger_elgg_event('init', 'system');

I think the mechanism based on handlers should work - provided all non-function code in start.php is launched in plugin's init method. We would be able to launch activate command before launching plugin itself then.

[brettp]

I think there's confusion about the boot order here.

# Elgg bootstraps itself.
# Loads the active plugins.
# Fires plugins_boot, system event (which does nothing)
# Fires init, system event (which are registered for in the 2nd step)
# Fires ready, system event
# Everything else happens (actions, pages, etc)

To register for an event fired from an action, the plugin has to be activated in the 2nd step. It is _possible_ to load the plugin in the activate action, but this gets pretty ugly and could have some nasty consequences.

I think the easiest solution to avoid overly complicated code is to say "put activate.php and deactivate.php in your plugin's dir."

[brettp]

Bah:

• Elgg bootstraps itself.
• Loads the active plugins.
• Fires plugins_boot, system event (which does nothing)
• Fires init, system event (which are registered for in the 2nd step)
• Fires ready, system event # Everything else happens (actions, pages, etc)

[lie2815]

So... instead of registering a bunch of functions to call on activation in manifest.xml, this approach would allow for an activate.php file in the plugin directory. This would contain the appropriate code that needs to be run during activation.

If activation fails, currently, one of the functions simply needs to return false. How should this be done now? We can use return with include statements, too - should I go this way?

For other questions, I might try to get a hang of you on IRC in a few hours, Brett.

[cash]

How about throwing an exception to indicate failure?

[lie2815]

Neat, I'm actually positive I can do this (almost done, actually).

How should the activation code be handled, though? Should it be simple spaghetti code in the activate.php file? Or a group of functions that get attached to hooks similar to how it seems to be common in start.php?

[cash]

If you include the script, you give the author the option of a linear script (spaghetti code?), registered functions, including some class/library, ...

My guess is that most plugins can do what they need in a few lines. The most common need is to register an entity subtype to class mapping (take a look at the entity subtypes table for an example).

[lie2815]

I created a pull request on GitHub with my first implementation: ​https://github.com/Elgg/Elgg/pull/21

[lie2815]

Ok, the pull request is updated. It should now be ready to be applied.

[brettp]

(In [svn:9002]) Fixes #3310. Applied lie2815's patch to use activate.php and deactivate.php instead of manifest on_de/activate fields in plugins.

[brettp]

We forgot about the unit tests.

[lie2815]

Sorry, here you go: ​https://github.com/Elgg/Elgg/pull/26

[brettp]

(In [svn:9008]) Fixes #3310. Removed old on_activate unit tests.

[brettp]

Thanks for the patch Franz. Forgot to credit you in the commit msg!

[lie2815]

Ah, no problem. I often forget that, too.
Plus, there are other ways for you to credit me ;)