Application / System events documented

[robbiejackson]

User description

Documentation for Application events and the onBeforeExtensionBoot and onAfterExtensionBoot

---

PR Type

Documentation

---

Description

• Comprehensive documentation for Application/System events

• Detailed explanations of 10 main system events triggered during HTTP request handling

• Documentation for onBeforeExtensionBoot and onAfterExtensionBoot events with use cases

• Index table updated with links to all documented application events

---

Diagram Walkthrough

flowchart LR
  A["New application.md<br/>documentation file"] -->|"Contains event details"| B["10 system events<br/>documented"]
  B -->|"onAfterInitialise<br/>onAfterRoute<br/>onAfterDispatch<br/>etc."| C["Event descriptions<br/>arguments & returns"]
  A -->|"Includes"| D["onBeforeExtensionBoot<br/>onAfterExtensionBoot"]
  E["index.md updated"] -->|"Links to"| A
  E -->|"Adds 11 rows"| F["Event reference table"]

Loading

File Walkthrough

Relevant files

Documentation

application.md New Application/System events documentation                            docs/building-extensions/plugins/plugin-events/application.md New comprehensive documentation file for Application/System events Includes Joomla request flow overview showing where events are triggered Documents 10 main system events with descriptions, arguments, and return values Detailed sections on onBeforeExtensionBoot and onAfterExtensionBoot with use cases and examples +381/-0  index.md Updated index with Application/System events table              docs/building-extensions/plugins/plugin-events/index.md Added 11 new rows to the event reference table for Application/System events Links all documented events to the new application.md file with anchor references Includes event names, descriptions, group classification, and release information Covers events from before 4.0 through 5.0 releases +11/-0

---

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
⚪	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Documentation Only: This PR adds documentation and does not implement or modify runtime logging, so it neither satisfies nor violates audit trail requirements based on the provided diff. Referred Code --- sidebar_position: 1 title: Application / System Events toc_max_heading_level: 2 --- Application / System Events =========================== Application / System Events are triggered by the core Joomla application code - the highest level code which provides the main flow of control in Joomla. For a plugin to capture these events it should be defined as a system plugin. In this category we also include the events onBeforeExtensionBoot and onAfterExtensionBoot, as they don't fit into any other category, and your plugin has to be a system plugin to receive them all. :::warning System plugins are loaded every time Joomla runs, on both the site front-end and administrator back-end. If you have a PHP syntax error in a system plugin then you will get locked out of the Joomla administrator back-end, and will have to go into phpmyadmin (or equivalent) to set to 0 the `enabled` field within the plugin record in the `#__extensions` table. ... (clipped 360 lines) Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: No New Code: The changes are Markdown documentation with minimal illustrative snippets, so meaningful naming compliance for code cannot be assessed from this diff. Referred Code --- sidebar_position: 1 title: Application / System Events toc_max_heading_level: 2 --- Application / System Events =========================== Application / System Events are triggered by the core Joomla application code - the highest level code which provides the main flow of control in Joomla. For a plugin to capture these events it should be defined as a system plugin. In this category we also include the events onBeforeExtensionBoot and onAfterExtensionBoot, as they don't fit into any other category, and your plugin has to be a system plugin to receive them all. :::warning System plugins are loaded every time Joomla runs, on both the site front-end and administrator back-end. If you have a PHP syntax error in a system plugin then you will get locked out of the Joomla administrator back-end, and will have to go into phpmyadmin (or equivalent) to set to 0 the `enabled` field within the plugin record in the `#__extensions` table. ... (clipped 360 lines) Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: No Error Paths: The PR only adds documentation and contains no executable error handling logic to evaluate for robustness or edge case management. Referred Code --- sidebar_position: 1 title: Application / System Events toc_max_heading_level: 2 --- Application / System Events =========================== Application / System Events are triggered by the core Joomla application code - the highest level code which provides the main flow of control in Joomla. For a plugin to capture these events it should be defined as a system plugin. In this category we also include the events onBeforeExtensionBoot and onAfterExtensionBoot, as they don't fit into any other category, and your plugin has to be a system plugin to receive them all. :::warning System plugins are loaded every time Joomla runs, on both the site front-end and administrator back-end. If you have a PHP syntax error in a system plugin then you will get locked out of the Joomla administrator back-end, and will have to go into phpmyadmin (or equivalent) to set to 0 the `enabled` field within the plugin record in the `#__extensions` table. ... (clipped 360 lines) Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Not Applicable: As this PR only updates documentation and does not change user-facing error handling, compliance cannot be determined from the diff. Referred Code --- sidebar_position: 1 title: Application / System Events toc_max_heading_level: 2 --- Application / System Events =========================== Application / System Events are triggered by the core Joomla application code - the highest level code which provides the main flow of control in Joomla. For a plugin to capture these events it should be defined as a system plugin. In this category we also include the events onBeforeExtensionBoot and onAfterExtensionBoot, as they don't fit into any other category, and your plugin has to be a system plugin to receive them all. :::warning System plugins are loaded every time Joomla runs, on both the site front-end and administrator back-end. If you have a PHP syntax error in a system plugin then you will get locked out of the Joomla administrator back-end, and will have to go into phpmyadmin (or equivalent) to set to 0 the `enabled` field within the plugin record in the `#__extensions` table. ... (clipped 360 lines) Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: No Inputs Added: The PR introduces no new input handling or data processing code; therefore validation and data handling security cannot be assessed from this diff. Referred Code --- sidebar_position: 1 title: Application / System Events toc_max_heading_level: 2 --- Application / System Events =========================== Application / System Events are triggered by the core Joomla application code - the highest level code which provides the main flow of control in Joomla. For a plugin to capture these events it should be defined as a system plugin. In this category we also include the events onBeforeExtensionBoot and onAfterExtensionBoot, as they don't fit into any other category, and your plugin has to be a system plugin to receive them all. :::warning System plugins are loaded every time Joomla runs, on both the site front-end and administrator back-end. If you have a PHP syntax error in a system plugin then you will get locked out of the Joomla administrator back-end, and will have to go into phpmyadmin (or equivalent) to set to 0 the `enabled` field within the plugin record in the `#__extensions` table. ... (clipped 360 lines) Learn more about managing compliance generic rules or creating your own custom rules
Update

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Correct the event API usage Correct the code example for onAfterRender to use $event->getSubject() instead of the non-existent $event->getApplication() method to access the application object. docs/building-extensions/plugins/plugin-events/application.md [245-246] -$event->getApplication()->getDocument(); // or -$event->getApplication()->getBody(); // just to get the HTML body +$app = $event->getSubject(); +$doc = $app->getDocument(); // or +$body = $app->getBody(); // just to get the HTML body Apply / Chat Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies that the AfterRenderEvent object does not have a getApplication() method and provides the correct way to access the application object via $event->getSubject(). This fixes a significant error in the documentation's code example.	Medium
General	Improve clarity of the example Replace the ambiguous plugin name example fields:content with the clearer sef:system to better illustrate the plugin_name:plugin_type format. docs/building-extensions/plugins/plugin-events/application.md [320] -- for plugins the plugin name and type separated by a colon, eg "fields:content" +- for plugins the plugin name and type separated by a colon, eg "sef:system" Apply / Chat Suggestion importance[1-10]: 5 __ Why: The suggestion correctly points out that the example fields:content could be ambiguous and proposes a clearer alternative, sef:system, which improves the documentation's clarity for developers.	Low
Update

[Fedik]

@robbiejackson thanks for doing this!

[Fedik]

I suggest something like:

$app = $event['subject'];          // these two
$app = $event->getApplication();   // are equivalent

For our events all arguments available via array access $event.
This way when try access non-existing argument the code will return null,
and with $event->getArguments()['non-existing'] PHP will show warning "non existing Array key"

[robbiejackson]

Sorry Fedir, I don't understand what you mean.

[HLeithner]

I wouldn't explain that these two are equal, we always prefer the explicit getXYZ() method because this automatically allows an IDE or static Codeanalyser to verify the usage.

Don't give the choice, that's also important for AI so it uses the better version.

Why? because now you say they "are equivalent" choices which is basically not true. What you now need to do is explain why one is the preferred way, which is a waste of time to read. If you want to explain it do it in the base event description and not in a special event.

[Fedik]

Sorry Fedir, I don't understand what you mean,

When need "array access" then better do it directly from the $event and not with getArguments()

Because:

$args = $event->getArguments();
$args['non-existing'];  // PHP will show warning: access to non existing value in array, kind of
$event['non-existing']; // Will return null

this also can be safely used to check if argument exists:

if ($event['argimentName']) {
  ///
}

But Harald's suggestion also good.

[robbiejackson]

Ah ok, I see now, I wasn't aware of the "array access" stuff, but I'll include some description in the general page on accessing the plugin event parameters.

For this page I'll go with Harald's suggestion of making it simpler and just using the getter where available.

The 4.4 version will have to be a bit different as the Application event classes only arrived in Joomla 5.

[HLeithner]

Also this is the wrong direction, the documention should be written in the "here and now" format and not talking about history. If you come here you want to read how to do it and how it was. For this we have versioning.

[robbiejackson]

Yes agreed. I'll keep it for 4.4, but remove it for 5 and 6

[robbiejackson]

I've done a 4.4 version, but haven't yet copied to 5.4 and 6.0.

[robbiejackson]

For v6 I'm intending to remove completely that page Joomla 4 and 5 Changes and replace it with something in general about accessing the arguments and returning values.

However it will require more significant changes across the board to remove links etc, so I'll do that as a separate PR.

[HLeithner]

thanks, when you need something or when the prs are ready please ping me