ICT:Dashboard autopurge architecture

ICT: Dashboard Auto‑Purge Architecture

This page documents why dashboards in this wiki require an automatic purge after saving a Page Forms form, why several intuitive approaches fail, and why the final solution works reliably. It is written for future administrators and maintainers of the Costa Sano Research infrastructure.

1. The Problem

Dashboards such as Dashboard:Place display data stored in Cargo tables. After saving a form, the updated Cargo data does not appear immediately because:

• Cargo updates are asynchronous
• MediaWiki caches parser output
• APCu/object cache may serve stale HTML
• Reverse proxies may cache responses
• Page Forms redirects do not trigger a purge

Users therefore see outdated dashboard data unless the page is manually purged.

A reliable, automatic purge mechanism is required.

2. Why Simple Solutions Do Not Work

2.1. HTML <meta> refresh

MediaWiki sanitizes <meta> tags, even inside #tag:html. The tag is displayed as text and never executed.

Conclusion: HTML refresh cannot be used.

---

2.2. Redirecting to ?action=purge

A redirect to:

?action=purge

always triggers MediaWiki’s confirmation dialog:

> Do you want to purge this page?

This dialog cannot be suppressed via GET requests.

Conclusion: GET‑based purge is never silent.

---

2.3. Page Forms limitations

Page Forms does not provide:

• after‑save hooks
• post‑redirect callbacks
• purge triggers
• button overrides

There is no way to attach purge logic to the Save button.

Conclusion: Page Forms cannot trigger a purge.

---

2.4. JavaScript redirect loops

If JavaScript redirects to ?action=purge:

1. The purge dialog appears
2. After confirmation, the page reloads
3. The JS sees no marker indicating purge completion
4. JS redirects again
5. Infinite loop

Conclusion: Redirect‑based purge is unstable.

---

2.5. Query parameters being stripped

Reverse proxies, skins, and canonical URL rewrites may strip unknown parameters such as:

?purged=1

This causes loops because the JS cannot detect that the purge already happened.

Conclusion: Only parameters MediaWiki preserves can be used as markers.

3. Requirements for a Working Solution

A correct solution must:

• purge silently (no dialog)
• avoid loops
• work for all dashboards
• survive reverse proxies and canonicalization
• be centralized
• be successor‑friendly

This leads to the final architecture.

4. The Final, Working Solution

4.1. Purge via the MediaWiki API

MediaWiki performs a silent purge only when:

• the request is a POST
• it includes a valid CSRF token
• it uses the API module

This avoids the confirmation dialog entirely.

---

4.2. Use a preserved query parameter

MediaWiki never strips parameters beginning with mw_. We use:

?mw_purged=1

to mark that the purge has already occurred.

---

4.3. Centralize logic in MediaWiki:Common.js

This ensures:

• all dashboards benefit
• no per‑page hacks
• predictable behaviour

5. The Working Code (Common.js)

$(function () {
    const title = mw.config.get('wgPageName');

    if (title && title.startsWith('Dashboard:')) {

        // Only purge once
        if (!location.search.includes('mw_purged=1')) {

            new mw.Api().get({
                action: 'query',
                meta: 'tokens',
                type: 'csrf'
            }).done(function (data) {

                const token = data.query.tokens.csrftoken;

                new mw.Api().post({
                    action: 'purge',
                    titles: title,
                    token: token
                }).always(function () {

                    // Reload the dashboard normally, marked as purged
                    const url = mw.util.getUrl(title, { mw_purged: 1 });
                    location.replace(url);
                });
            });
        }
    }
});

6. Why This Works

Silent purge

• API POST + CSRF token
• No confirmation dialog
• No user interaction

No loops

• mw_purged=1 is preserved by MediaWiki
• JS sees the marker and does not purge again

Works for all dashboards

• Uses wgPageName
• No hardcoded page names

Infrastructure‑safe

• Survives reverse proxies
• Survives canonical URL rewrites
• Survives short URLs
• Survives caching layers

Successor‑friendly

• One central rule
• No per‑page code
• Easy to understand and maintain

7. Summary

The final solution works because it respects all of MediaWiki’s constraints:

• Purge must be done via API POST
• CSRF token is required
• GET purge always shows a dialog
• Page Forms cannot trigger purge
• Unknown query parameters may be stripped
• Only mw_* parameters survive reliably

By combining these insights, we achieve a stable, silent, automatic purge mechanism for all dashboards.