Joomla has a variety of core events, organised into groups.
Authentication events are triggered during the user authentication process.
This event is triggered to verify that a set of login credentials is valid.
Event called to initialise the captcha. It returns Boolean true on success, false otherwise.
Content events are triggered during the content creation process.
This is the first stage in preparing content for output and is the most common point for content orientated plugins to do their work. Since the article and related parameters are passed by reference, event handlers can modify them prior to display.
Results are returned by modifying the referenced arguments. Sometimes a boolean might be returned to check for success or failure of the event.
This is a request for information that should be placed between the content title and the content body. Although parameters are passed by reference, this is not the event to modify article data.
Returned value from this event will be displayed in a placeholder.
This is a request for information that should be placed immediately before the generated content. Returned value from this event will be displayed in a placeholder.
This is a request for information that should be placed immediately after the generated content. Returned value from this event will be displayed in a placeholder.
This is an event that is called right before the content is saved into the database. You can abort the save by returning false.
This is an event that is called after the content is saved into the database. Even though article object is passed by reference, changes will not be saved since storing data into database phase is past. An example use case would be redirecting user to the appropriate place after saving.
This is an event that is called before a JForm is rendered. It can be used to modify the JForm object in memory before rendering. For example, use JForm->loadFile() to add fields or JForm->removeField() to remove fields. Or use JForm->setFieldAttribute() or other JForm methods to modify fields for the form.
This is an event that is called after the data for a JForm has been retrieved. It can be used to modify the data for a JForm object in memory before rendering. This is usually used in tandem with the onContentPrepareForm method - this event adds the data to the already altered JForm.
This is an event that is called right before the content is deleted from the database. You can abort the delete by returning false.
This is an event that is called after the content is deleted from the database. An example use case would be redirecting user to the appropriate place after deleting.
This is an event that is called after content has its state change (For example, Published to Unpublished).
This event is triggered by a variety of search related operations. It is a request for a plugin to return the result of a search request. The rows must return the following fields, which are used in a common display routine: browsernav, catslug, created, href, section, slug, text, title
As system plugins are loaded before any other event group, they may also contain any other event.
This event is triggered after the framework has loaded and the application initialise method has been called.
This event is triggered after the framework has loaded and initialised and the router has routed the client request. Routing determines which component should receive the request. The component optional parameters are then set in the request object that will be processed when the application is being dispatched.
This event is triggered after the framework has dispatched the application. Dispatching is the process of pulling the option from the request object and mapping them to a component. If the component does not exist, it handles determining a default component to dispatch. When this event is triggered the output of the component is available in the document buffer.
This event is triggered immediately before the framework has rendered the application.
This event is triggered after the framework has rendered the application. When this event is triggered the output of the application is available in the response buffer.
This event is triggered before the framework creates the Head section of the Document.
This event authorises that a particular user should be able to login. The system triggers this event after the user has been authenticated and before he has been signed in the website.
The system triggers this event when the user has been authenticated but he has not been authorised to login. You should only use this event in User plugins.
This event is triggered before an update of a user record.
This event is triggered after an update of a user record, or when a new user has been stored in the database.
The event is triggered when a user is about to be deleted from the system.
The event is triggered after a user has been deleted from the system.
This event is triggered after the user is authenticated against the Joomla! user-base.
his event is triggered whenever a user authentication request is failed by any plugin.
This event is triggered whenever a user is successfully logged in.
This event is triggered before the user is logged out of the system.