Un nettoyage wp_options • WPShout

By | novembre 5, 2019
0 Comment

tuto wordpress

Aujourd'hui, je voudrais plonger dans une sorte de sujet ésotérique: le chargement automatique des options WP. Ce n’est pas quelque chose que beaucoup de développeurs WordPress risquent de toucher ou d’avoir besoin. Mais la connaissance vague de ce sujet m'a fait gagner du temps et de la confusion pour un projet client. Je tiens donc à vous aider à comprendre comment une utilisation occasionnelle du update_option fonctionner sans comprendre WordPress chargement automatique fonctionnalité d'options peut vous causer de la douleur et le chagrin d'amour.

Résumé rapide des options, du chargement automatique et du nettoyage de WP

Avant de plonger dans mon histoire, je souhaite proposer quelques définitions pour que mon histoire ait plus de sens:

  • wp_options est une table dans la base de données WordPress. En général, les développeurs WordPress appellent les valeurs stockées ici «options», sans ajouter beaucoup plus de détails. Ces «options» sont destinées à un plugin ou à un thème pour stocker des paramètres contrôlables par l'utilisateur concernant leurs fonctionnalités. Ainsi, si vous avez la possibilité de stocker une adresse de votre boutique en ligne, elle sera généralement stockée dans une ligne de la table wp_options.
  • update_option est la fonction WordPress la plus souvent utilisée pour définir et mettre à jour les options. C’est relativement facile à utiliser: donnez un nom à votre option, puis indiquez la valeur que vous souhaitez que WordPress stocke pour elle.
  • Les «transitoires» qui sont tangents à cette histoire, mais qui constituent un problème commun dans les objectifs généraux du nettoyage des options WP, sont des valeurs de courte durée dans la table des options de certains sites WordPress. Les transitoires sont utilisés lorsque WordPress ne dispose pas d’une «mise en cache d’objets» plus complète.
  • La «mise en cache d'objet» est le moment où WordPress stocke des intermédiaires dans votre magasin de données en mémoire, comme Redis ou Memcache (d), ou dans des transitoires WordPress.. Celles-ci améliorent les performances en stockant le résultat, par exemple, d’une requête de base de données coûteuse, évitant ainsi à WordPress de procéder à un recalcul complet à chaque fois.
  • Les options de WordPress peuvent être définies sur “autoload.”Comme vous pouvez le deviner, cela signifie que WordPress aura toujours et sans exception chargé cette option pour vous lors du chargement de toutes les pages. Pourquoi et quand ne pas C'est quelque chose que nous allons aborder dans mon histoire.
  • get_option est la fonction WordPress la plus souvent utilisée pour récupérer les options stockées dans wp_option table. Le principal avantage de cette fonction est qu’elle peut utiliser la valeur mise en cache par l’objet plutôt que de créer une nouvelle requête dans la base de données, en particulier pour les options à chargement automatique.

Avec tous ces faits dans notre tête, le temps de raconter mon histoire. Ne vous inquiétez pas trop si tous ces faits n’ont pas été pleinement pris en compte, nous reviendrons sur les aspects importants de ces détails au fur et à mesure de leur pertinence.

Mon histoire à propos de WP Option Autoload

J'ai donc un client (que je ne nommerai pas ici) avec un gros site WordPress. Ils ont eu quelques petits problèmes de performances sur leur site pendant des mois, voire des années. Ils obtiennent une assez grande quantité de trafic et paient beaucoup pour l’hébergement Web afin d’assurer que leur grand site avec beaucoup de contenu continue de fonctionner.

Leur site WordPress est assez ancien et c’est aussi assez étrange. Il s’agit d’une publication qui a démarré avec un CMS Python personnalisé, puis que ces développeurs Python (plus ou moins) ont créé pour leur créer un site WordPress. Le premier site WordPress d’un développeur Python aura fait au moins quelques choix inhabituels par rapport aux normes de développement WordPress.

Ils ont donc mis toute une panoplie de fonctionnalités dans le thème WordPress. (Un problème si courant que j'ai écrit il y a quelques années contre ce thème: «thème insidieux».) Le thème utilise le système de templates Blade de Laravel et, plus important encore, comporte de nombreuses autres fonctionnalités pour le site: choix décisionnels en matière de publicité, prise en charge importante de l'AMP code et la fonctionnalité de migration. Cette fonctionnalité de migration est le code qu'ils utilisaient pour transférer le site de leur ancien composant personnalisé vers WordPress.

Comment nous avons trouvé un problème

Ce site n'a jamais été aussi rapide. C’est un site énorme avec des milliers et des milliers d’articles. Même s’il n’est pas à la limite des capacités de WordPress, il se sent parfois proche de lui.

Et ils avaient remarqué qu’il avait commencé à se comporter encore plus mal au cours des derniers mois. Il y avait une erreur aléatoire 502, et juste une lenteur générale. Un coéquipier a contacté le support d'hébergement, qui a recommandé un conseil étrange: désactiver la mise en cache des objets. N'oubliez pas: la mise en cache des objets est le nom WordPress permettant d'utiliser une couche de cache en mémoire (généralement Redis of Memcached) pour stocker les intermédiaires WordPress, comme les requêtes de base de données courantes et le chargement automatique d'options WP. Cela accélère généralement les choses. Mais en effet, l'éteindre semblait aider.

Mais pourquoi? Pourquoi tourner de une fonctionnalité censée accélérer WordPress plus rapide?

Ce qui se passait, c’est que la mise en cache d’objets de l’hôte (pour des raisons de performances raisonnables) rejette les «objets» d’une taille supérieure à 1 Mo. Et ce site Web avait récemment franchi la frontière, où un objet très important à mettre en cache avait atteint une taille de 1,1 Mo. Pour ceux qui ne parlent pas la taille des fichiers, une chaîne de texte représente généralement quelques dizaines d'octets. 1000 (ou 1024) octets est un kilo-octet, ou Ko. 1000 (ou 1024 kilo-octets) est un mégaoctet, ou Mo. Donc, il y avait quelque chose qui était assez grand.

WordPress construirait un objet représentant toutes les options-WP définies pour le chargement automatique, puis essaierait de le transmettre au calque de mise en cache des objets. Lorsque la couche de mise en cache d'objets rejetterait l'objet, WordPress recalculerait alors cette valeur. La valeur en question: ensemble d’options à chargement automatique pour l’ensemble du site. Donc, plutôt que de le regarder une fois par chargement de page, WordPress l'a regardé et l'a chargé deux fois. Et comme nous en avons discuté, il était aussi pathologiquement important.

Le mauvais code de migration

Les détails de ce qui se passait ont été révélés lorsque l’équipe de support s’est penchée sur nos wp_options table avec une petite requête de base de données:

SELECT LENGTH (valeur_option),
     option_name FROM wp_options
     WHERE autoload = 'yes'
     ORDER BY longueur (valeur_option) DESC
     LIMITE 20;

Les détails de cette syntaxe SQL ne sont pas particulièrement importants. Ce qu'il fait est trouve les valeurs les plus longues (taille la plus grande) dans votre wp_options table qui sont mis à chargement automatique.

Ce que nous avons trouvé était à la fois déroutant et évident. Nous avions sur une seule option autoloaded dans notre base de données WordPress qui faisait près de 900 Ko en taille. Pour les photos de fichiers vidéo, ce n’est pas énorme. Pour le texte ou les valeurs de base de données simples, la masse était source de confusion.

J'ai donc creusé dans ce qui était cette seule valeur pathologiquement importante. J'ai trouvé le code renseignant la valeur: une seule fonction dans le thème WordPress conçue pour effectuer la migration des données du site il y a de nombreuses années. De plus, quelque chose à propos de ce code le faisait fonctionner par intermittence, augmentant continuellement la taille de la wp_option valeur car le site a vécu plus longtemps. La raison exacte de la croissance n’était pas claire et reste floue. (Nous planifions depuis des mois d’abandonner ce thème historique et «endetté sur le plan technique», ce qui donne un sens à la valeur des petites entreprises pour nous.)

La solution: Désactiver le chargement automatique pour cette option pathologique

J’en ai assez creusé dans ce code pour comprendre une chose: il ne faisait vraiment rien d’utile pour le fonctionnement normal du site. De plus, l’option mise à jour consistait simplement à se remplir de données inutiles. Autrement dit, au lieu de stocker des données utiles, tout ce qui était stocké était un tableau PHP auquel de nouvelles paires vides clé-valeur étaient régulièrement insérées. Ce qui revient à dire: ordure inutile.

La solution était donc simple: il suffit de créer cette ligne dans WordPress wp_options table de base de données n'a pas la valeur "oui" pour chargement automatique pour cette valeur hilarante.

Qu'est-ce que ce nettoyage de la wp_options table a fait en sorte que nous puissions revenir sur la mise en cache des objets pour le site et obtenir les gains de performances attendus. C’était donc un gagnant-gagnant: nous avons rendu le site moins de problèmes de cache. Et éliminer ces problèmes signifiait réactiver le cache, il serait également plus rapide.

Leçons que cela m'a appris sur le nettoyage des options WP

Pour énoncer une chose que vous avez peut-être réalisée à ce jour, il ne s'agit pas d'un guide définitif sur le nettoyage des options WP. Si vous recherchez un guide complet sur le nettoyage des options WP, consultez ce message de Kinsta.

Je partage plutôt une histoire sur ce que je pense de la performance WordPress et de la chargement automatique valeur en wp_options m'a surpris, dans l'espoir que cela puisse vous aider un jour.

J'aimerais souligner les leçons spécifiques que cela m'a appris sur la gestion des options WordPress:

  1. Gardez vos options petites. Celui-ci est une pratique courante. Mais voir un tableau sérialisé dans la base de données WordPress avec quelques milliers de clés m'a vraiment convaincu de l'importance d'utiliser des ensembles de données simples et petits dans votre tableau WP-Options.
  2. Penser de manière critique à chargement automatique en appelant update_option. Cela signifie que si vous avez une option rarement utilisée (dites quelque chose qui n'est en fait recherché que sur des pageloads sur 20 sur votre site WordPress), ne le faites pas charger automatiquement. Vous feriez cela plutôt simplement en changeant une base update_option ('my_option', 'value'); être update_option ('my_option', 'value', 'no');. (Si vous ne spécifiez pas de valeur pour le troisième $ autoload paramètre, update_optionpar défaut à 'Oui'.)
  3. Ne mettez pas de plug-in de migration dans un thème. Ajouter du code de migration à un thème WordPress est la définition même de ce que je voulais dire par «fluage du thème WordPress». Placez ce code dans un plug-in que vous désactivez et supprimez dès que vous avez terminé la migration. Nul besoin de le garder, de courir tout le temps, quand ce n’est pas supposé faire quoi que ce soit. (Et c’est quelque chose qui va surprendre et dérouter les administrateurs du site dans trois ans.)

Je suis sûr que l’on peut tirer une autre leçon de cette histoire. Le fait que le support de notre hôte connaisse et comprenne le problème est un peu frustrant. C’est pourquoi il est toujours important de se tenir au courant des meilleurs hébergements WordPress.

Et c’est comme ça que le chargement automatique des options WP fonctionne

J'espère vous avoir aidé à comprendre un peu plus de détails étranges sur la façon dont les options WP gèrent le chargement automatique, et un cas pathologique qui peut se produire lorsque vous avez trop d'options à chargement automatique, de sorte que vous dépassez la taille acceptable pour votre cache d'objets.

Comme je l’ai dit, ce rapport aurait peut-être semé l’embarras dans la confusion si je n’étais pas déjà un peu au courant (de ce vieil article de JJJ) que wp_option Le chargement automatique peut causer des problèmes inattendus.

Bonne chance, développeurs WordPress

[ad_2]