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
There should probably be some method of expiration of cache pages, particularly for pages containing variables (it is X date, we have X articles, etc).

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. Browsers that advertise support for gzip in their Accept-Encoding field will be given the gzipped version straight; for those browsers that don't, we unzip the data on the fly and send them the plaintext.

A "Vary: User-agent" header will be sent to tell proxy caches to be more careful about who it resends data to. ("Vary: Accept-encoding" would be more appropriate, but Internet Explorer refuses to cache pages so marked.)

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
 * redirect pages are not cached, so clicking a link to a redirect doesn't go through to the final destination
 * 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). One should also ensure that the appropriate Vary header gets sent:

Header append Vary Cookie

Also note that, since this redirect trick bypasses MediaWiki entirely, it won't respect. You may need to clear or rebuild the cache manually as needed instead.

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;
 * your cache folder is inside your MediaWiki folder (default);
 * you're already proxying *.php files to php-fpm (or whatever) in the last location block.

Et voici les limitations :
 * as with the Apache solution, you have to run a cron job or manually rebuild the cache files when they change;
 * pages whose title include non-ASCII characters are served through PHP (which should be transparent to the user anyway).

Modifier les chemins si nécessaire.