Asset v2 – Server-Side Trigger Investigation Log

Document revision: 2026-02-20 Author: Mngr

This page documents the systematic investigation of server-side lifecycle triggers for Asset v2 in the MediaWiki / Page Forms / Cargo environment.

The purpose is to record **facts and conclusions**, so work can be resumed without loss of context.

Context

Environment (locked during investigation):

OS: AlmaLinux 10.1
Web server: Apache (httpd)
PHP: php-fpm
MediaWiki: 1.45.x
Page Forms: 6.x
Cargo: installed and operational
Logging: wfDebugLog confirmed working
SELinux: temporarily permissive during testing

Asset v1 was fully removed before starting Asset v2.

Investigation Goal

Find a **reliable, server-side trigger** that fires during Asset creation (using Page Forms + Cargo) and can be used as the authoritative lifecycle anchor for Asset v2 logic (identifier finalisation, page move, file rename, immutability).

Client-side JavaScript is explicitly excluded as an authoritative mechanism.

Proven Infrastructure Facts

The following facts were proven empirically:

LocalSettings.php executes on every request
wfDebugLog() works reliably and writes to /var/log/mediawiki/asset.log
Custom extensions load correctly (verified in Special:Version)
Custom extension hooks can execute (verified using BeforePageDisplay)
Page Forms successfully creates pages and writes Cargo rows

These points are **not in doubt**.

MediaWiki Save Hooks Tested

The following MediaWiki core save hooks were tested:

PageSaveComplete
PageContentSaveComplete

Tests were performed:

inside a custom extension
and directly inside LocalSettings.php

Result:

None of these hooks fired when saving pages via Page Forms
No log output was produced, even when hooked directly in LocalSettings.php

Conclusion:

MediaWiki core save hooks are not reliable lifecycle anchors for Page Forms + Cargo saves in this environment.

Page Forms Hooks Tested

Page Forms server-side hooks were tested directly in LocalSettings.php, including:

PageFormsFormSubmitted

Result:

No hook output was logged
No evidence of server-side Page Forms hooks firing in this setup

Conclusion:

Page Forms hooks are not firing (or not exposed) in this environment.

Key Negative Result (Important)

The following was proven:

Neither MediaWiki save hooks
nor Page Forms hooks

fire during Asset creation in this system.

This is not a configuration error but an observed system behavior.

Remaining Guaranteed Server-Side Event

One fact remains certain:

Cargo writes rows to the database during Asset creation
This operation must occur for Assets to exist

Therefore:

Cargo data write events are the only guaranteed server-side trigger during Asset creation.

Temporary LS.php Trigger Strategy

During investigation, it was confirmed that:

LocalSettings.php is a valid place to test hook firing
Adding hooks there provides absolute certainty (no extension indirection)

This technique is valid and should be reused to verify Cargo hooks.

Status at End of Session

No authoritative lifecycle trigger has yet been confirmed
MediaWiki and Page Forms hooks are ruled out
Cargo hooks remain the primary candidate
A temporary LS.php hook test is the correct next diagnostic step

Restart Plan for Next Session

The next session MUST begin with:

Fresh eyes
Re-testing triggers using LocalSettings.php only
Verifying Cargo hooks (e.g. CargoAfterStoreData) in isolation
Only after confirmation, moving logic into an extension

No extension logic should be written until a trigger is empirically confirmed.

Guiding Principle (Reaffirmed)

What can be done server-side, should be done server-side
What does not empirically fire must not be relied upon
Determinism is more important than architectural elegance

SELinux (AlmaLinux 10.1) – Security Context Consideration

AlmaLinux 10.1 enforces SELinux by default.

Observations during Asset v2 investigation:

SELinux was previously confirmed to block Lua execution when in enforcing mode
Lua only worked correctly after explicit SELinux allowance or permissive mode
During trigger investigation, SELinux mode may influence:
- PHP hook execution
- extension file access
- hook registration side effects
- logging behavior

Important note:

All trigger tests performed during this investigation MUST be repeated once with SELinux enforcing (setenforce 1) and once with permissive (setenforce 0), to rule out silent denials.

This applies especially to:

Page Forms hooks
Cargo hooks
Extension-based lifecycle logic

SELinux state is therefore a first-class diagnostic variable and must be checked explicitly at the start of each session.

Suggested diagnostic commands:

getenforce
sudo setenforce 0   # temporary permissive mode
sudo setenforce 1   # restore enforcing mode

Conclusion:

No lifecycle trigger should be considered reliable until verified under SELinux enforcing mode.