Manual:File cache/fr

MediaWiki possède un schéma simplifié optionnel pour enregitrer le HTML généré des pages d'articles dans le cache.

Opération et utilisation
Le cache des fichiers est activé en initialisant ces variables dans LocalSettings.php :

= true; /* par défaut : false */ = "$IP/cache"; # ou en laissant la valeur par défaut : "{$wgUploadDirectory}/cache" qui vaut "$IP/images/cache" par défaut

Ceci a pour conséquence que la page web HTML générée pour chaque page du wiki, sera rangée dans un fichier dédié sur le disque dur. Toute les demandes ultérieures émanant d'utilisateurs anonymes sont répondues non pas en générant de nouveau la page mais simplement en renvoyant la version du fichier HTML qui a été enregistré sur le disque. Ceci permet de gagner du temps.

Le texte web HTML généré est mis sur le disque dans les répertoires sous  et ressemble à ceci :

 -rw-r--r-- 1 apache apache 57421 Jan 7 01:58 cache/0/04/P%C3%A1gina_principal.html -rw-r--r-- 1 apache apache 29608 Jan 4 16:37 cache/1/17/P%C3%A1gina_Riscada.html -rw-r--r-- 1 apache apache 21592 Jan 3 07:27 cache/1/1c/P%C3%A1gina_Duplicada.html -rw-r--r-- 1 apache apache 36088 Jan 7 02:03 cache/2/24/P%C3%A1gina_principal_alternativa.html -rw-r--r-- 1 apache apache 44205 Jan 7 06:10 cache/a/a4/P%C3%A1gina_linkada.html -rw-r--r-- 1 apache apache 24686 Jan 3 07:27 cache/d/db/P%C3%A1gina_Invertida.html -rw-r--r-- 1 apache apache 17222 Jan 3 06:28 cache/f/f0/P%C3%A1gina_n%C3%A3o_encontrada.html

Dans cet exemple, le répertoire du cache des fichiers est cache/ et les pages du wiki sont enregistrées dans chaque fichier Página ..., avec une correspondance d'un fichier Página_....html pour une page du wiki. Ces fichiers sont créés au fur et à mesure que les utilisateurs visitent les articles du wiki; vous pouvez tous les créer en une seule passe avec le script de maintenance rebuildFileCache.php.

Le cache des fichiers se comporte plutôt brutalement; il n'y a pas de durée limite de présence dans le cache pour les pages générées et elles sont mises en cache inconditionnellemnt, même si elles contiennent des variables, des extensions, et d'autres sorties variables. Certaines extensions suppriment la mise en cache pour les pages ayant un contenu dynamique.

Pour un résultat plus parlant, considerez l'utilisation de $wgUseGzip à la place de (ou combiné avec).

Pour des sites plus gros, l'utilisation d'un cache externe tel que Squid ou Varnish est préférable pour l'activation du cache des fichiers.

Si le cache des fichiers semble ne pas fonctionner, assurez-vous que le serveur web a la permission d'écrire dans le répertoire que vous avez choisi.

Limitations
Les noms de fichier des fichiers du cache sont définis en fonction du titre des pages. En fonction de la langue utilisée pour le titre des pages, certains caractères du nom de fichier devront être encodés pour obtenir un nom de fichier compatible avec le système de fichiers. Pour les langues telles que l'arabe, le chinois et autres, cela peut se traduire par l'avertissement PHP suivant :

PHP Warning: file_put_contents(cache/......html.gz): failed to open stream: File name too long in includes/cache/FileCacheBase.php on line 171

Ceci est une limitation connue. Voir.

Les pages des catégories et les descriptions des images ne sont pas effacées du cache. Par exemple, l'ajout ou la supression d'une page dans une catégorie ne met pas à jour la page de catégorie, ce qui fait que les utilisateurs non connectés ne voient pas les modifications de cette dernière. Ceci est une limitation connue. Voir

Domaine et intervalle
L'utilisation du cache ne se fait que pour les utilisateurs qui :
 * ne sont pas connectés.
 * qui n'ont pas leur indicateur user_newtalk d'activé.

Les pages qui entrent dans le cache :
 * ne sont pas des pages spéciales.
 * ne sont pas des redirections.
 * sont affichées dans leur version actuelle, vue simple, sans paramètres d'URL

Ceci couvre la majorité des requêtes du wiki, mais il est encore important de configurer le bytecode et le cache des applications pour gérer tout le reste.

Validation
La date de modification du fichier en cache est comparée avec la date se trouvant dans la variable globale  initialisée dans  à chaque visualisation.

Si le fichier est au moins aussi récent que ces deux dates, il est considéré comme valide et envoyé directement au client. S'il est plus ancien, ou n'existe pas, l'analyse syntaxique de la page et sa génération continuent et les résultats sont sauvegardés pour une utilisation ultérieure.

Invalidation
Le cache entier peut être invalidé en initialisant  à l'heure actuelle, ou en supprimant tous les fichiers du cache.

Les pages individuelles sont invalidées en initialisant leur champ page.page_touched par l'appel pratique de. Ceci doit être fait à la création de l'article, à l'enregistrement des modifications, au renommage, et à la création et la suppression des articles liés (pour mettre à jour les liens modifiés). Les opérations d'invalidation qui apparaissent lors de la modification des modèles par exemple, le contole des pages qui utilisent le modèle pour comparer la date en cache avec page_touched.

Certains cas ne sont pas encore bien gérés, ce qui inclut probablement :


 * 'reload' ou 'refresh' du navigateur (ne recharge que la page en cache sans en faire la mise à jour)
 * les variables de sortie des extensions telles que Extension:DynamicPageList désactivent la mise en cache de ces pages afin d'éviter d'avoir des données périmées. Celles qui ne le font pas, retournent les données périmées même lors du rechargement de la page par le navigateur.
 * certain longs messages d'erreur peuvent être mis en cache indéfiniment comme s'ils étaient du contenu valide de page; seulement  va les supprimer du cache après qu'il y auront été enregistrés. Un seuil de taille minimale des sorties est utilisé pour éviter la mise en cache de la plupart des errreurs, comme les erreurs PHP fatales.

Voir aussi :.

Expiration
Le méthodes d'expiration des pages du cache doivent probablement exister, particulièrement pour les pages qui contiennent des variables (la date: nous sommes le XXXX, des valeurs: nous avons XXXX articles, ...).

Si  vaut , la mise en cache des fichiers sera désactivée pour la sortie de la page. Aucune disposition ne permet de définir une date d'expiration. Par conséquent, l'ensemble du code HTML de toutes les pages est mis en cache pour toujours. An explicit  command (or an edit to the page) will regenerate that one page, but neither the MediaWiki internal no-cache flags nor the browser refresh will remove outdated extension output once it has been stored as part of a file-cached page.

Onglet de rafraichissement
Il est possible d'ajouter un onglet pour forcer une page individuelle à devenir non-valide et la rafraîchir, en utilisant  et l'extension Purge page.

Compression
Optionnellement, le cache peut être compressé pour économiser de la place et de la largeur de bande. (Ceci nécessite que zlib soit activé dans le PHP config.)

Si la compression est activée, les fichiers en cache sont sauvegardés avec l'extension. Les navigateurs qui annoncent la prise en charge de gzip dans leur champ Accept-Encoding recevront directement la version compressée; pour les navigateurs qui ne le font pas, nous décompressons les données à la volée et nous leur envoyons le texte en clair.

Un entête "Vary: User-agent" sera envoyé pour dire au cache du proxy de faire plus attention à qui il renvoie les données. (« Vary: Accept-encoding » serait plus approprié, mais Internet Explorer refuse de mettre en cache les pages marquées ainsi.)

Repli d'urgence
If the wiki can't contact the database server, it will try to show the cached version of whatever page was requested, regardless of whether it may be current or not, with a "database is down" message tacked into it.

Ceci possède quelques limitations :
 * les pages spéciales ne sont pas couvertes, en aucune manière, il y a juste un message d'avertissement
 * les pages de redirection ne sont pas mises en cache, donc un clic sur un lien de redirection ne mène donc pas à la destination finale.
 * pages with colons in the title (other than for a valid namespace) may still fail due to MediaWiki checking the DB to see if the title has a valid interwiki prefix. This occurs only if there is no interwiki cache entry for the page's prefix (see ) or   is falling back (or set to).
 * attempts to use non-view actions result in a plain page view, which may be confusing
 * there may be issues with the MySQL connection timeout which make it take prohibitively long before giving up, particularly if using persistent connections and the db dies later. Adjust mysql.connect_timeout (set to 3 or more) in php.ini to deal with this. Edit the webserver's php.ini not the cli php.ini.
 * fallback may fail if  is not   due to attempting a DB query
 * fallback may fail if  is set to   and   is falling back (or set to) DB_CACHE

Répondre directement avec les pages du cache
By default, MediaWiki passes cache page with php. Here is how we use webserver configuration tricks to serve cached files directly without invoking MediaWiki or PHP at all.

First, setting. Then we add rewrite rules. See below.

Apache
The following mod_rewrite rule has been found to work in an .htaccess file on a shared webhost running Apache 2.2:

 RewriteBase / RewriteCond %{HTTP_COOKIE} !UserID= RewriteCond %{QUERY_STRING} !. RewriteCond %{DOCUMENT_ROOT}/w/html_cache/$1.html -s RewriteRule ^wiki/(.+)$ /w/html_cache/$1.html [B,L,NS]
 * 1) If a cached page exists under /w/html_cache, do an internal redirect to it:

However, this rewrite rule won't work properly for pages whose titles contain punctuation or non-ASCII characters. A tidy solution would be to use a RewriteMap, but this is not supported in .htaccess context. Instead, the following trick can be used to handle non-ASCII titles by pulling the URL-escaped title directly from the raw request line:

 RewriteBase / RewriteCond %{HTTP_COOKIE} !UserID= RewriteCond %{QUERY_STRING} !. ReWriteCond %{THE_REQUEST} ^GET\x20/wiki/([^\x20/]+)\x20HTTP RewriteCond %{DOCUMENT_ROOT}/w/html_cache/%1.html -s RewriteRule ^wiki/(.+)$ /w/html_cache/%1.html [B,L,NS]
 * 1) If a cached page exists under /w/html_cache, do an internal redirect to it:

This will still not match titles containing periods, slashes or other punctuation which the file cache escapes but browsers don't (or vice versa). Il faut aussi s'assurer que l'entête Vary ad'hoc a été envoyée :

Header append Vary Cookie

Notez aussi que, comme cette astuce de redirection contourne complètement MediaWiki, elle ne respectera pas. Il est possible à la place, que vous deviez effacer ou reconstruire le cache manuellement si besoin.

Nginx
Since the nginx configuration language is pretty limited (it doesn't allow nested if statements, for example), it requires the ngx_lua module.

The following conf should be integrated inside your server block, and it assumes that:
 * you're using fancy urls like example.com/Page;
 * votre dossier de cache est à l'intérieur de votre dossier MediaWiki (par défaut);
 * vous envoyez déjà les fichiers *.php par proxy à php-fpm (ou autre) dans le dernier bloc d'emplacement.

Et voici les limitations :
 * comme avec la solution Apache, vous devez exécuter une tâche  ou reconstruire les fichiers du cache manuellement lorsqu'ils sont modifiés;
 * les pages dont le titre contient des caractères non-ASCII sont servies via PHP (ce qui devrait être transparent pour l'utilisateur de toute façon).

Modifier les chemins si nécessaire.