Nous continuions notre série de tutoriel sur la configuration du plugin W3TC. A titre de rappel, W3TC est l’abréviation du nom « W3 Total Cache », qui est un célèbre plus pour mettre en cache on blog. Mettre en cache un blog signifie rendre des données identiques facilement accessible pour le serveur.

Vous pouvez lire nos précédents tutoriels sur le sujet pour en savoir plus.

La page de configuration de la mise en cache de la base de données menu comporte deux sections: Général et avancée .

database-general-mise-en-cache-de-la-base-de-donnees

Le section « General » a juste une option: une case à cocher, cochée par défaut, qui permet de ne pas mettre en cache les requêtes effectuées pour les utilisateurs connectés. Ce que cela signifie, c’est que si un utilisateur est connecté, ils n’auront pas les données provenant du cache. La raison est que les utilisateurs connectés vont interagir avec le site au cours de leurs sessions. Ils ont donc besoin de recevoir les données actualisées.

Une exception à ceci, serait lorsqu’un contenu est caché derrière un « paywall », qui ne change pas avec l’ouverture de l’utilisateur connecté. Dans ce cas, la base de données mise en cache est utilisée car les utilisateurs sont connectés juste pour accéder au contenu et non pour réellement interagir avec ou modifier tout le contenu du site.

La section « Avancé » dans le menu de la base de données permet d’affiner le cache de base de données. Vous pouvez attribuer une vie à des objets dans le cache avec une valeur par défaut étant de 180 secondes, et de déterminer la durée après laquelle les objets périmés doivent être retirés.

configuration-avancees-du-cache-w3tc

Si vous utilisez la mise en cache de la base de données, respectez les valeurs par défaut à moins que le cache de la base de données ne devienne trop important. Si cela se produit, réduisez la durée de vie des objets du cache ou l’intervalle de collecte des déchets pour réduire la quantité d’espace occupé par le cache de la base de données.

Vous pouvez également spécifier des pages spécifiques où les données de la base de données mises en cache ne seront pas utilisées dans les pages suivantes. C’est particulièrement utile si vous faire des requêtes de cache pour les utilisateurs connectés mais qu’il y a quelques pages où vous ne souhaitez pas que les données du cache soit pris en charge.

mise-en-cache-de-la-base-de-donnees

Le champ suivant dans la avancée section vous permet de spécifier les tiges requête de base de données qui sera ignoré – qui est, pas mis en cache par le cache de base de données. Utilisez ce champ si vous utilisez des plugins qui dépendent de l’interrogation de la base de données.

Par exemple, le champ est prérempli avec trois valeurs: gdsr_, wp_rg_, et _wp_session. Ces trois requêtes correspondent aux plugins GD Rating System, Gravity Forms, et WP Session Manager. Ce sont trois plugins communs qui ont besoin d’interroger directement la base de données chaque fois qu’une page est chargée, pas une version en cache de la base de données. Donc, l’ajout de ces requêtes à la liste ignorée permet d’éviter que ces requêtes ne soient mises en cache.

Si vous avez le cache de la base de données activé et remarquez qu’un plugin spécifique ne fonctionne pas normalement, vous aurez besoin d’identifier la requête associée soit en creusant dans le code du plugin ou en demandant à l’auteur du plugin.

Le champ intitulé « Rejet Query » permet d’identifier des types spécifiques de requêtes qui ne doivent pas être mis en cache. Sauf si vous êtes un administrateur de la base de données, laissez ce champ tel qu’il est.

C’est tout pour la configuration du cache de la base de données sur W3TC. N’hésitez pas à nous poser des questions si vous ne comprenez pas un point.