View source for ICT:HELP-Project:Asset v2 – Trigger Investigation Log

= Asset v2 – Server-Side Trigger Investigation Log =

Document revision: {{#time:Y-m-d|{{REVISIONTIMESTAMP}}}}  
Author: {{REVISIONUSER}}

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:

<pre>
getenforce
sudo setenforce 0   # temporary permissive mode
sudo setenforce 1   # restore enforcing mode
</pre>

Conclusion:

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

[[Category:Asset]]
[[Category:Development Log]]