Jump to content

ICT:HELP-Project:Asset v2 – Trigger Investigation Log

From Costa Sano MediaWiki
Revision as of 21:33, 20 February 2026 by Mngr (talk | contribs) (Created page with "= 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...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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:

  1. Fresh eyes
  2. Re-testing triggers using LocalSettings.php only
  3. Verifying Cargo hooks (e.g. CargoAfterStoreData) in isolation
  4. 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