Elgg
As already mentioned, there are two types of events in the Elgg platform: Elgg events and plugin hooks. Plugin hooks tend to be triggered when an action has occurred and parts of that action can be overridden by a plugin though there are more cases when a plugin hook can be used because it is more general purpose than an Elgg event. There are four primary differences between plugin hooks and Elgg events:
Contents |
To register a handler, use the function register_plugin_hook as in this example:
register_plugin_hook('cron', 'hourly', 'myplugin_cronjob');
Your function hook handler should have the following prototype:
function my_plugin_hook($hook, $type, $returnvalue, $params) { ... do stuff ... }
You can trigger a plugin hook in your plugin with the trigger_plugin_hook function.
By adding calls to trigger_plugin_hook() in your code (generally your action code), you allow other plugin developers to register for those plugin hooks and extend the functionality of your plugin.
// auto adjust contrast unless another plugin has registered to do this if (!trigger_plugin_hook('photo_album_plugin','contrast', array('entity' => $image), false) { // no plugins returned true, so we auto adjust contrast ... }
The cron plugin hook allows your plugin to launch custom functionality on a regular period, triggered by the server.
The type parameter here should be a string containing the cron period you want to attach the functionality to. These are:
The permissions_check plugin hook allows you to override Elgg's default access permissions. This means you could allow the current user to edit an entity that he might not have permission to edit by default. (Note that it does not allow you to retrieve entities that the current user doesn't have permission to see.) An example would be overriding the permissions on a group entity like a photo album. You would like to allow everyone who belongs to a group to upload to any photo album that was created under the group. Each album though is owned by the user who created it so you may need to override the default permissions and check whether the user belongs to the group before giving write permission.
The plugin hook function is passed a params array with the entity type with the entity as the entity parameter and the current user as the user parameter. It is also passed the default true or false status of whether the current user can edit the entity in question as the returnvalue.
This should be used with caution! Before changing the default value, be sure to limit the scope of your function with an if clause to check that you are in the correct context. To use the context, you'll need to set the context variable in your actions as appropriate as well. Next your plugin hook function should check to see if it's the right sort of entity, and the execution context makes sense, before changing the permissions return value. Otherwise you may deny edit access to every entity, or even worse, allow write access to everything to everyone.
For more examples, see Permissions Check
By default, unvalidated users trigger the validate user event if they attempt to login or request a new password. If the uservalidationbyemail plugin is activated (as in a standard Elgg install), this will resend a validation link to the user and inform them that this has happened.
If you would like some other behaviour instead, you can define unvalidated_login_attempt or unvalidated_requestnewpassword plugin hooks. The user entity is passed in the entity parameter.