User:AccountManager

File:FA user icon.svg User data
Registered 2021

This account is a technical account used for the management, maintenance, and testing of the wiki.

Admin Wiki

Statut Semantic MediaWiki

Série SMW Statut PHP MediaWiki Notes
6.0.x Stable 8.1 – 8.4 1.43 – 1.44 Série actuelle
5.1.x Obsolète 8.1 – 8.4 1.39 – 1.43.1 MediaWiki 1.43.1 est la dernière version supportée par SMW 5.x

Décision actuelle : Le wiki est maintenu volontairement sur une version compatible **SMW 5.1.x / MediaWiki ≤ 1.43.1** afin de préserver la compatibilité des extensions et patches existants.

Toute montée vers MediaWiki 1.44+ impliquera une migration complète vers **SMW 6.x** et une réévaluation des extensions.

Note d’administration

La série SMW 5.x est considérée comme obsolète mais reste fonctionnelle. Elle constitue un socle stable pour les wikis existants disposant d’extensions personnalisées ou patchées.

Intention : maintien en production tant que SMW 6.x n’est pas validé avec l’ensemble des extensions.
État documenté le : 22 décembre 2025.

Procédure de purge et synchronisation des caches

Cette procédure doit être appliquée après :

  • la mise à jour simultanée de plusieurs modèles (Template:)
  • la modification ou l’import de modules Lua (Module:)
  • des changements sur des gadgets JavaScript
  • l’apparition d’erreurs transitoires (UseResource errors, catégories vides, affichage incohérent)
  • import ou modification de pages MediaWiki: (Common.js, gadgets)

Ces anomalies sont généralement dues à une désynchronisation temporaire des caches MediaWiki.

Caches concernés

MediaWiki utilise plusieurs niveaux de cache pouvant devenir incohérents lors de mises à jour rapides :

  • Parser cache (modèles, catégories, pages traduites)
  • Scribunto / Lua cache (résultats des modules Lua)
  • ResourceLoader (gadgets, MediaWiki:Common.js, modules JS)
  • Cache PHP (OPcache / APCu) (selon l’infrastructure)

Procédure standard (sans accès serveur)

1. Invalider le cache global 

/index.php?title=Special:InvalidateCache

2. Purger les pages clés

  • Pages utilisant les nouveaux modèles
  • Pages de catégories affectées
?action=purge

3. Purger le cache Scribunto

  • Aller sur :
Special:Scribunto
  • Utiliser l’option Clear module cache si disponible

4. Forcer le rechargement ResourceLoader

  • Ouvrir une page avec :
?debug=true
  • Recharger la page

5. Vider le cache navigateur

  • Ctrl + F5
  • ou navigation privée

Procédure avancée (avec accès SSH)

À utiliser après des mises à jour massives ou une migration. 

php maintenance/purgeParserCache.php
php maintenance/rebuildLocalisationCache.php
php maintenance/runJobs.php

Si APCu ou OPcache est activé :

  • redémarrage PHP recommandé si possible
Méthodes accessibles sans accès root

a) Forcer l’expiration naturelle (méthode passive)

  • OPcache et APCu expirent automatiquement :
    • après un délai d’inactivité
    • lors d’un dépassement mémoire
  • Cette méthode est non immédiate mais sans risque

b) Invalidation par modification de fichier OPcache invalide un script lorsque son horodatage change. Actions recommandées :

  • modifier et sauvegarder :
  • LocalSettings.php

ou un fichier inclus fréquemment (commentaire suffisant) Exemple : 

// cache touch 2025-03-xx

Cela force PHP à recharger les scripts.

c) Redémarrage du pool PHP via cPanel (si disponible) Certains hébergeurs permettent :

  • cPanel → Select PHP Version
  • changer temporairement de version PHP (ex. 8.1 → 8.0 → 8.1)

Effet :

  • redémarrage du pool PHP
  • purge OPcache / APCu

⚠️ À utiliser uniquement si la compatibilité est confirmée.

d) Tâche CRON forcée Créer une tâche CRON exécutant un script PHP minimal peut forcer un rafraîchissement partiel du cache. Exemple : 

<?php
echo time();

Effet :

  • recharge du moteur PHP
  • purge partielle possible selon l’hébergeur
Méthodes non disponibles en mutualisé

Les actions suivantes sont impossibles en hébergement mutualisé standard : 

  • systemctl restart php

  • service php-fpm restart

  • opcache_reset()
    depuis MediaWiki (désactivé pour sécurité)
  • accès root ou sudo
Indicateurs d’un cache PHP bloqué
  • comportements incohérents persistants malgré purge MediaWiki
  • erreurs apparaissant/disparaissant après plusieurs minutes
  • code corrigé mais ancien comportement toujours visible

Dans ce cas, la seule solution est :

  • attendre l’expiration automatique
  • ou contacter l’hébergeur
Recommandation pratique

Sur hébergement mutualisé :

  • considérer APCu / OPcache comme semi-maîtrisable
  • toujours purger MediaWiki avant de suspecter PHP
  • documenter les anomalies transitoires dans le carnet technique

Bonnes pratiques lors des mises à jour

  • Importer tous les modèles et modules dépendants avant de tester
  • Éviter de tester pendant l’import
  • Attendre 1 à 2 minutes après la dernière modification
  • Appliquer ensuite la procédure de purge complète
  • Tester dans une fenêtre privée

Tester dans une fenêtre privée signifie ouvrir le wiki dans une session de navigation sans cache ni cookies existants (navigation privée / incognito). Cette étape permet de s’assurer que l’affichage observé ne dépend pas d’anciens fichiers JavaScript, CSS ou cookies conservés par le navigateur, et qu’un visiteur non connecté obtient le même résultat.

Indicateurs d’un problème de cache (non critique)

  • erreurs intermittentes disparaissant seules
  • catégories affichant temporairement 0 page
  • gadgets chargés partiellement
  • erreurs UseResource non persistantes

Ces symptômes ne traduisent pas un bug fonctionnel tant qu’ils disparaissent après purge.

Extensions

⚠️ Documentation – le code effectif est dans LocalSettings.php

CollapsibleSections

wfLoadExtension( 'CollapsibleSections' );

$wgCollapsibleSectionsCollapsedByDefault = 'true';
$wgCollapsibleSectionsEnableDesktop = 'true' ;
$wgCollapsibleSectionsTag ='h3';

GoogleTranslation and HTML Purifier

# Charger l'extension GoogleTranslate
wfLoadExtension( 'GoogleTranslate' );

// Change this to enable translation saving
$wgGoogleTranslateSave = true;
// Percentage of the page that needs to be translated before it gets saved (0.9 means 90%)
$wgGoogleTranslateSaveTreshold = 0.9;
// Change this to save the translated title in {{DISPLAYTITLE}}
// Enable $wgRestrictDisplayTitle to show the translated title
$wgRestrictDisplayTitle = true;
$wgGoogleTranslateSaveTitle = true;
// Change this to add translations to the same categories as the original page
$wgGoogleTranslateSaveCategories = true;
// Name of a template to prepend to every translation
$wgGoogleTranslateSaveNotice = 'Template:Automatic translation notice';
// Change this to set the language of the translations from the subpage name
// Note that $wgNamespacesWithSubpages needs to be enabled for this to work
# Enable subpages in the main namespace
$wgNamespacesWithSubpages[NS_MAIN] = true;
// Alternatively, enable $wgPageLanguageUseDB to allow this extension
$wgPageLanguageUseDB = true;
$wgGroupPermissions['sysop']['pagelang'] = true;
$wgGroupPermissions['bot']['pagelang'] = true;
// to set the language of the translation pages directly
$wgGoogleTranslateSubpageLanguage = true;
// Name of the system account that will do the saving
$wgGoogleTranslateSystemAccount = 'Translations bot'; 

# Charger l'extension HTMLPurifier
wfLoadExtension( 'HTMLPurifier' );
  • **GoogleTranslate** — actif, pages /fr OK

ReplaceText

wfLoadExtension( 'ReplaceText' );
$wgGroupPermissions['sysop']['replacetext'] = true;

SemanticAppropedia

Appropedia extension modified locally to remain compatible with Semantic MediaWiki ≥ 5.1.

A patch has been applied to:

  • replace old pre-5.x SMW references,
  • ensure loading without fatal errors under PHP 8.1,
  • avoid warnings related to internal SMW changes.

This extension is **not strictly upstream** and should be considered:

  • locally patched,
  • to be checked before any major SMW version upgrade.

Version displayed on Special:Version:

  • 9.1 with Patch SMW 5.1

SemanticMediaWiki

  • **SemanticMediaWiki** — actif, cœur du wiki
wfLoadExtension( 'SemanticMediaWiki' );
enableSemantics( 'wiki-shangri-la.org' );

wfLoadExtension( 'SemanticResultFormats' );

État : actif – SMW 5.1 / cible 6.x Voir également :

SemanticRESTAPI

  • **SemanticRESTAPI** — désactivée (non utilisée)

SyntaxHighlight_GeSHi

  • Terminal : check permissions
chmod +x /home/XXXXXXXXXX/public_html/mw19/extensions/SyntaxHighlight_GeSHi/pygments/pygmentize
  • Then add in LocalSettings :
$wgPygmentizePath = "$IP/extensions/SyntaxHighlight_GeSHi/pygments/pygmentize";

Infrastructure

Server Cache (APCu)

Objective: To improve performance despite known issues with APCu in a shared hosting environment.
Technical Requirements:

  • Shared hosting (cPanel)
  • APCu available but not guaranteed
  • Semantic MediaWiki enabled
# ===============================
# Cache serveur (APCu sécurisé)
# ===============================
if ( extension_loaded( 'apcu' ) && ini_get( 'apc.enabled' ) ) {
    $wgMainCacheType = CACHE_ACCEL;
    $wgParserCacheType = CACHE_ACCEL;
    $wgSessionCacheType = CACHE_DB;

    $wgObjectCaches['apcu'] = [
        'class' => 'APCUBagOStuff',
        'reportDupes' => false,
    ];
} else {
    $wgMainCacheType = CACHE_DB;
    $wgParserCacheType = CACHE_DB;
}
# ===============================

Justification:

  • APCu can be disabled by the hosting provider without prior notice
  • Preliminary testing via extension_loaded() and ini_get()
  • Sessions are stored in the database (CACHE_DB) to prevent any loss

SMW Impact:

  • Improves semantic parser performance
  • Reduces the cost of repeated queries
  • Does not introduce any critical dependencies

WebSiteAccelerator

Présentation

Description du fonctionnement Astral

Website Accelerator chez Astral est attaché au serveur d'hébergement mutualisé, pas prioritairement à un site en particulier. Les sites à forte affluence bénéficient donc mécaniquement d’un meilleur taux de cache “chaud”, indépendamment de la configuration locale du site. Dans ce contexte, il faut choisir un niveau qui n’entre pas en conflit avec :

  • MediaWiki 1.43 + Semantic MediaWiki 5.1 (contenu dynamique, parsing coûteux)
  • Cloudflare gratuit (cache edge + règles simples)
  • APCu + OPcache (cache PHP interne déjà très efficace)
Niveaux de cache disponibles dans Website Accelerator (WSA) d'Astral Internet
❌ Niveaux très agressifs

(2 jours / 3 semaines de cache dynamique serveur) À exclure pour MediaWiki

  • Cache serveur HTML long (2 jours / 3 semaines)
  • Incompatible avec :
    • éditions fréquentes
    • SMW
    • purges MediaWiki
  • Risque réel de pages obsolètes

👉 À ne pas utiliser, même avec Cloudflare.

⚠️ Niveau “1 heure de cache dynamique serveur”
  • 1h de cache HTML serveur
  • Correct pour des CMS simples
  • Encore trop agressif pour MediaWiki + SMW

👉 Possible seulement pour un wiki quasi figé, ce qui n’est visiblement pas votre cas.

Niveau “5 secondes de cache dynamique serveur”

C’est le premier niveau réellement intéressant :

  • 5 secondes de cache serveur HTML
  • Soulage Apache/PHP sur les rafales
  • Faible risque de contenu obsolète
  • Compatible avec MediaWiki

Cloudflare peut absorber le reste

👉 Bon compromis, surtout sur serveur mutualisé.

Niveau "Aucun cache serveur pour le contenu dynamique"

Cache navigateur + cache statique serveur

Typiquement :

  • ❌ Pas de cache serveur HTML dynamique
  • ✅ Cache serveur pour :
    • images
    • fichiers statiques
    • éventuellement JS/CSS
  • ✅ Cache navigateur :
    • JS/CSS : 1–8 semaines
    • images : long
  • Cloudflare fait le cache edge
  • APCu + OPcache font le cache PHP

👉 C’est le plus sûr et le plus propre pour MediaWiki + SMW.

risques pour MediaWiki/SMW

MediaWiki n’est pas un CMS “statique” :

  • pages dynamiques
  • dépendance forte aux droits utilisateurs
  • purge fréquente du cache lors des éditions
  • Semantic MediaWiki ajoute des requêtes complexes

👉 Un cache serveur trop agressif sur le HTML dynamique est risqué (staleness, pages non mises à jour, incohérences SMW).

Niveau recommandé

Pas de cache dynamique ou 5 secondes maximum

Option 1 (la plus sûre, recommandée)
  • ✔ Pas de cache serveur pour le contenu dynamique
  • ✔ Cache serveur statique (images, fichiers)
  • ✔ Cache navigateur actif
  • ✔ Cloudflare gratuit activé
  • ✔ APCu + OPcache actifs

➡️ Zéro conflit, stabilité maximale

Option 2 (si le serveur est sous forte charge)
  • ✔ Cache dynamique serveur 5 secondes maximum
  • ✔ Cache statique serveur
  • ✔ Cache navigateur
  • ✔ Cloudflare

➡️ Gain léger de perf sans casser MediaWiki

Procédure de test de performance (nouvelle)

  • Objectif : Mesurer temps de chargement et efficacité du cache serveur + Cloudflare edge.
  • Outils : WebPageTest, GTmetrix, curl.
  • Cold cache : Purge Cloudflare + cache serveur, vider navigateur, attendre 1–2 minutes, lancer test.
  • Warm cache : Recharger page pour chauffer cache edge Cloudflare, attendre 5–10 minutes, lancer test.
  • Indicateurs à noter : TTFB, Load time, CF-Cache-Status, cache navigateur, cache serveur.
  • Interprétation : Comment lire les résultats pour ajuster le niveau Website Accelerator.
1️⃣ Préparation
  1. Mode de test' : utilisez un outil fiable comme WebPageTest ou GTmetrix ou curl en ligne de commande pour des tests rapides
  2. Navigateur : videz le cache, cookies et disable cache dans DevTools.
  3. Cloudflare : notez l’état de vos règles (caching niveau “Standard” ou “Bypass”), désactivez éventuellement le Development Mode.
  4. Astral Website Accelerator : laissez le niveau recommandé (pas de cache serveur dynamique ou 5s max).
2️⃣ Test Cold Cache (cache vide)

Objectif : mesurer le temps de chargement lorsque Cloudflare et Website Accelerator n’ont jamais servi la page.

  1. Videz le cache Cloudflare pour la page test : Cloudflare → Caching → Purge → URL spécifique
  2. Videz le cache navigateur ou utilisez un private window.
  3. Attendez 1–2 minutes pour que le cache serveur Astral soit purgé.
  4. Testez la page avec votre outil (WebPageTest ou curl).
  5. Notez :
    1. TTFB (Time To First Byte)
    2. Load Time
    3. Cache status (Cloudflare : CF-Cache-Status: MISS)
3️⃣ Test Warm Cache (cache déjà servi)

Objectif : mesurer le temps lorsque Cloudflare et serveur ont déjà mis en cache la page.

  1. Rechargez la page une fois pour “chauffer” le cache edge Cloudflare.
  2. Attendez 5–10 minutes pour que Cloudflare serve la page depuis ses POP.
  3. Testez à nouveau avec le même outil.
  4. Notez :
    1. TTFB
    2. Load Time
    3. Cache status (Cloudflare : HIT)

Astuce : testez depuis plusieurs localisations pour voir la propagation edge (WebPageTest permet de choisir la ville).

4️⃣ Tests complémentaires
  • JS/CSS/Images : vérifiez les headers Cache-Control et CF-Cache-Status.
  • Pages dynamiques avec SMW : éditez une page, rechargez, vérifiez que la page se purge correctement et que le TTFB reste correct.
  • Variation Astral Website Accelerator : si vous voulez tester 5s vs aucun cache serveur, refaites le cold/warm test et comparez.
5️⃣ Interprétation
  • Cold cache très lent : serveur ou SMW nécessite optimisation (OPcache/APCu ou requêtes SMW complexes).
  • Warm cache rapide (<500ms TTFB) : configuration Astral + Cloudflare efficace.
  • Cloudflare HIT mais TTFB long : bottleneck côté serveur (PHP/DB).

Cache Astral vs Cloudflare : avec 5s cache serveur dynamique, gain modeste mais sûr pour MediaWiki.

Tableau de suivi des tests mensuels

Date Page test Cold Cache TTFB Cold Load Time CF Cache Status (cold) Warm Cache TTFB Warm Load Time CF Cache Status (warm) Notes / Observations
2025-12-25 Page d'accueil 1.2s 3.5s ❌ MISS 0.4s 1.1s ✅ HIT Temps correct, cache Astral OK

💡 Légende / guide pour remplir chaque colonne

  • Date : jour du test.
  • Page test : URL ou nom de la page testée.
  • Cold Cache TTFB : Time To First Byte pour le premier chargement (cache serveur et Cloudflare vide).
  • Cold Load Time : temps total de chargement pour le cold cache.
  • CF Cache Status (cold) : MISS attendu pour le cold cache.
  • Warm Cache TTFB : TTFB pour la page servie depuis cache Cloudflare et serveur.
  • Warm Load Time : temps total de chargement pour le warm cache.
  • CF Cache Status (warm) : HIT attendu pour le warm cache.
  • Notes / Observations : remarques, problèmes, actions à envisager.

Bonnes pratiques / recommandations

  • Ne pas augmenter le cache serveur dynamique pour MediaWiki >5s pour éviter les pages obsolètes.
  • Toujours tester après purge de Cloudflare pour connaître le temps réel “cold cache”.
  • Utiliser ce tableau pour suivre l’évolution des performances et ajuster le niveau Website Accelerator si nécessaire.
  • Pour sites très actifs, privilégier des tests réguliers plutôt qu’un cache serveur long.
Retrieved from "https://www.wiki-shangri-la.org/mw19/index.php?title=User:AccountManager&oldid=7138"