WordPress, ça craint, ça attire votre attention ? N'est-ce pas, vous pourriez penser que c'est un peu provocateur, mais autant j'aime WordPress, et je suis sûr que vous aussi. Il y a beaucoup de choses qui sont vraiment nulles avec WordPress. Ce ne sera pas un discours sarcastique, mais il est temps d'enlever nos lunettes de couleur rose et de jeter un coup d'oeil à certaines des choses qui font que WordPress craint.
Mais d'abord, qui suis-je ? Et quels droits ai-je de dire que WordPress est nul. Euh, je m'appelle Cameron Jones. Je suis un développeur WordPress de Victor Harbor en Australie, et je construis des sites WordPress depuis 2014. Et je dirige également le marché des mangoustes de plugin store, euh, avant de commencer, je voudrais juste dire que je peux couvrir des sujets délicats et que toutes les opinions sont purement les miennes.
Maintenant, plongeons.
Nous commencerons par examiner la structure de la base de données. Lorsque WordPress a été développé pour la première fois, il s'agissait purement d'une plateforme de blogage. Et en tant que telle, elle n'avait que des articles, car elle a grandi pour inclure des pages et des types d'articles personnalisés. Ces nouveaux types de contenu n'étaient que des extensions d'un article à son cœur, une page est un article, un produit est un article, une commande est un article.
Et ils sont tous stockés dans la même écurie de poste. Cela pose deux problèmes principaux le premier est qu'il est très difficile de fusionner des contenus entre plusieurs environnements. Ce n'est pas si mal pour les sites essentiellement statiques. Mais pour les sites très actifs comme les magasins de commerce électronique et les forums, cela peut devenir un cauchemar.
Si vous créez un nouveau poste dans un environnement de mise en scène, par exemple, on lui donnera une identité, mais dans un environnement de production, les postes ayant la même identité, il pourrait s'agir de quelque chose de complètement différent, comme une image de commande ou même une révision. L'équipe de Delicious Brains a essayé de mettre au point une solution pour ce bot de fusion, mais elle a fini par abandonner le projet.
S'ils ne parviennent pas à trouver une solution au problème des idées contradictoires, ce n'est probablement pas possible dans l'état actuel de la structure de la base de données. L'autre problème est qu'avec tous les types de messages qui partagent la table des messages, il n'est pas possible de personnaliser les colonnes de la table pour les différentes données dont chaque type de message a besoin.
D'une certaine manière, tout va donc dans le méta-tableau des postes. Le fonctionnement du post-métal est excellent car il est flexible et particulièrement facile de stocker des contenus répétitifs. Cependant, comme chaque élément de post-métal occupe une rangée dans le tableau, il peut être très rapidement gonflé. Cela signifie également que vous ne pouvez pas définir l'indexation des requêtes sur une colonne spécifique, ce qui accélérerait les requêtes.
Combiné, cela signifie que les requêtes d'articles de WordPress seront généralement plus lentes qu'elles ne le devraient pour un simple site statique. Cela ne serait pas perceptible, mais sur des sites de cette taille, cela peut être assez inhibitif. La base de données est assez rigide car une grande partie du fonctionnement de WordPress repose sur sa configuration actuelle, mais il y a quelques petites choses que vous pouvez faire pour aider à atténuer ces problèmes.
Si vous avez le contrôle sur les types de contenu mis en place pour enregistrer vos propres types de messages personnalisés, vous pouvez utiliser des pods, des types de contenu personnalisés, qui établissent leurs propres tables pour chacun des types de contenu. Mais cela ne fonctionnera pas pour une application comme WooCommerce, qui est intégrée avec ses propres types d'articles personnalisés.
Si vous avez le contrôle des champs de méta-écriture utilisés, vous pouvez les stocker tous dans un seul tableau sérialisé, ce qui signifie qu'il n'y aura qu'une seule ligne de méta-écriture pour chaque article dans la base de données. Il est cependant plus difficile d'interroger les messages par un champ méta spécifique. Et encore une fois, si vous utilisez des plugins qui ont leurs propres types d'articles personnalisés, il n'y a rien que vous puissiez faire avec ceux-là dans un monde idéal, l'enregistrement d'un type enregistrerait une nouvelle table spécifiquement pour ce type d'article.
Et vous avez la possibilité d'ajouter des colonnes personnalisées pour les posts meta lorsque vous avez enregistré ce type de post, mais cela nécessiterait malheureusement beaucoup de modifications de base.
Comme nous avons déjà en quelque sorte couvert un type de contenu personnalisé, tel qu'un produit, ne devrait pas vraiment être une extension d'un poste. Il y a à la fois des colonnes dans le tableau des messages et des propriétés dans l'objet de message WP dont vous n'avez probablement pas besoin, comme les champs pour les commentaires et les ping backs. En plus de cela, il y a probablement d'autres propriétés que vous voulez stocker pour chaque message de votre type de message personnalisé que vous devrez stocker en tant que méta message, ce qui peut être loin d'être idéal.
En outre, il y a certains aspects que les messages ont les autres types de messages ne peuvent pas par exemple, les types de messages personnalisés ne peuvent pas avoir de messages collants. Il est possible de recréer la fonctionnalité des messages collants en utilisant un champ Postmate et en filtrant la requête. Mais. Et il semble qu'il y ait des plugins qui peuvent résoudre ce problème.
Cependant, il s'agit d'une des incohérences entre les messages et les types de messages personnalisés : les messages peuvent avoir l'archive comme page d'accueil ou être assignés à une page publiée, mais les types de messages personnalisés n'ont pas cette possibilité. Ils ne peuvent avoir qu'une archive générée dynamiquement ou aucune archive du tout. Cela signifie que sans code, vous ne pouvez pas modifier le permalien d'une archive de type d'article personnalisé ou la définir comme page d'accueil.
Il peut être très frustrant d'essayer de créer un site web alors que différents types de contenu peuvent avoir des mises en œuvre si différentes, même s'ils sont si similaires.
WordPress a longtemps tenu un standard élevé pour maintenir la rétrocompatibilité. Non seulement WordPress, sa propre architecture, mais aussi les versions PHP. Ce n'est que très récemment que WordPress a officiellement abandonné le support de PHP 5.4 alors que d'une part. C'est une bonne chose pour la rétrocompatibilité. D'autre part, cela signifie que les hébergeurs n'ont pas été très motivés pour maintenir les serveurs à jour.
Ces derniers temps, WordPress a introduit des moyens pour que les plugins exigent une version minimale de WordPress et une version minimale de PHP car les plugins augmentent les exigences minimales pour leur installation. Certains hôtes bon marché ont été laissés pour compte. Les sites Web vivants sont bloqués avec des plugins qui ne peuvent pas être mis à jour si ces plugins présentent des bogues ou des vulnérabilités dans les versions précédentes qui pourraient laisser les sites cassés ou vulnérables aux pirates.
L'engagement de WordPress en faveur de la rétrocompatibilité a conduit à la complaisance de certains hébergeurs. Malheureusement, aujourd'hui plus que jamais, il est important d'investir dans un hébergement de qualité.
Arrêtez. Nous allons jeter un coup d'oeil à la base du code. WrodPress est ancien, ayant été fondé en 2003. Cela fait donc presque 18 ans. Il existe depuis lors, car les temps ont changé et les normes de codage s'améliorent. Il en va de même pour la base de code de WordPress, dont beaucoup de fonctions sont dépréciées au profit de meilleures. Mais avec leur engagement à la rétrocompatibilité, la plupart, sinon toutes ces fonctions dépréciées le restent, elles sont toujours présentes dans la base de code au cas où un très vieux site les utiliserait encore.
Je ne dirais pas que WordPress est gonflé, mais il y a beaucoup de code là-dedans qui devrait probablement être supprimé. C'est l'une des choses que ClassicPress a fait, étant un fork dur de WordPress 4.9, ils ont supprimé de nombreuses fonctions obsolètes et du vieux code qui n'est plus nécessaire.
Tout ne s'est pas amélioré, cependant, WordPress s'appuie fortement sur des variables globales, ce qui pollue l'espace de noms global. Vous devrez donc faire attention à la façon dont vous appelez vos variables, en particulier dans les fonctions qui utilisent des crochets. La meilleure façon de le vérifier est d'utiliser les normes de codage PHP de WordPress, qui mettront en évidence les variables que vous utilisez et qui peuvent entrer en conflit avec certaines des variables globales de base.
Vous avez probablement déjà vu ce modèle de diagramme de hiérarchie. C'est un merveilleux mélange de spaghettis. Cela a beaucoup de sens. Une fois que vous avez construit quelques sites. Le problème est qu'il ne reflète pas vraiment la façon dont les modèles devraient fonctionner pour la plupart des sites web sur différentes pages. Il s'agira presque toujours d'un ensemble d'éléments globaux qui seront présents sur chaque page.
Oui. WordPress a des fonctions comme la partie "obtenir un modèle". Mais vous finirez toujours par vous répéter dans les nombreux fichiers de modèles différents, ce qui rendra les choses vraiment difficiles. Si vous avez besoin d'apporter un changement significatif à tous les niveaux, la meilleure façon de contrer cette hiérarchie inefficace des modèles est d'essayer de créer une fonction de "template wrapper".
Il y a quelques thèmes, comme les racines qui ont compris comment le faire vraiment bien. J'ai d'ailleurs fait une conférence il y a quelques années pour montrer comment faire. Et si vous voulez approfondir ce sujet, il y a un lien à l'écran.
WordPress a naturellement un lien très étroit avec wordpress.org, mais d'une certaine manière, il est allé trop loin. WordPress suppose que chaque plugin d'un site a été installé à partir de wordpress.org. Cela signifie que si vous avez l'intention de développer un plugin ou un thème personnalisé, vous devez faire attention au nom du dossier, sinon WordPress pourrait essayer de le remplacer par le plugin ou le thème du même nom.
Il est hébergé sur wordpress.org. Si vous souhaitez que votre plugin ou thème personnalisé soit hébergé ailleurs, pour quelque raison que ce soit, comme sur GitHub, vous devrez utiliser des filtres pour changer l'endroit où WordPress recherche le plugin à héberger. Il existe des moyens de faciliter cette opération, comme la classe de licence edd, si vous distribuez vos plugins ou vos thèmes avec des téléchargements numériques faciles.
Je crois que Fremius a quelque chose de similaire. Et puis il y a aussi des classes mises à jour par GitHub. Cependant, ce n'est pas infaillible car il faut que le plugin ou le thème soit actif pour que le filtre fonctionne. Par exemple, au lieu de quelque chose de plus logique, comme une option dans un en-tête de fichier. Cela nous amène à la question de savoir pourquoi des éléments comme EDD ou Fremius sont nécessaires.
Et c'est parce que vous ne pouvez pas avoir de plugins ou de thèmes payants sur WordPress.org, ils sont tous gratuits à télécharger. C'est très bien. Si vous n'avez qu'un plugin ou un thème comme passe-temps, mais que votre plugin se développe, il peut être difficile de le maintenir, de répondre aux changements du noyau de WordPress et de gérer les demandes d'assistance et surtout, si vous ne tirez aucun profit financier de votre plugin, mais que vous comptez continuer à travailler dessus, de nombreux plugins ont choisi d'opter pour la voie du freemium avec un plugin gratuit sur wordpress.org et de vendre une version premium avec plus de fonctionnalités en dehors de WordPress.
Je pense qu'il va sans dire que le fait de ne pas avoir de plugins et de thèmes payants sur WordPress.org a rendu plus difficile pour les gens de gagner leur vie en construisant des produits WordPress et a diminué la qualité des plugins et des thèmes disponibles sur WordPress.org.
WordPress utilise le SVN pour le contrôle des versions du noyau et des thèmes et plugins. SVN est un système de contrôle de version centralisé, ce qui signifie qu'il n'est vraiment qu'à un seul endroit. J'aimerais que WordPress utilise Git, et ils utilisent GitHub pour des projets plus modernes comme Gutenberg, mais WordPress existe en fait depuis plus longtemps que Git.
Il n'y avait donc même pas d'option à l'époque, contrairement à ce qui se passe avec le SVN, où vous pouvez commiter localement et pousser vos commits vers le serveur, un commit est un commit direct vers le serveur. Il peut être assez pénible à utiliser. Surtout si vous avez l'habitude de traiter avec Git, si vous avez un plugin hébergé sur wordpress.org et que vous ne voulez pas traiter avec le SVN, vous pouvez utiliser quelque chose comme Absera pour gérer le côté SVN pour vous tout en ne traitant avec Git que vous-même.
WordPress est sous licence GPL, qui est en fait une licence de gauche d'auteur. Cela signifie que tout le monde peut utiliser WordPress. Cependant, ils aiment. C'est cool, mais cela signifie aussi que tout travail dérivé hérite de la licence, et cela signifie les thèmes et les plugins. D'une certaine manière, c'est une bonne chose car cela facilite l'utilisation des plugins et les rend meilleurs, comme la façon dont nous faisons du commerce est une bifurcation de Gigoshop.
Mais cela signifie aussi que. Les gens sont plus que bienvenus pour redistribuer votre travail comme s'il leur appartenait, y compris le travail rémunéré. De nombreux clubs GPL ont ainsi vu le jour et ont revendu des plugins de qualité supérieure à des prix très bas. Techniquement, c'est principalement le code PHP qui hérite de la GPL, mais pas les images, les polices, etc.
De même, lhey peut être utilisé par votre plugin ou votre thème. Ils ne dépendent en aucune façon de WordPress. Il est donc tout à fait légal d'utiliser votre travail sous une licence partagée où le code est sous licence GPL et les autres ressources ne font pas l'objet d'un contrôle zélé de la part de la communauté. Si vous voulez publier votre plugin sur wordpress.org ou parler à un WordCamp, par exemple, tout doit être sous licence GPL.
Envato, par exemple, a permis aux auteurs de vendre leurs plugins ou leurs thèmes sous une licence partagée. Ainsi, tous les employés d'Envato se sont vus interdire de prendre la parole lors des rencontres WordCamps et WordPress tant qu'ils y restent employés, ce qui est franchement décevant. Heureusement, ce n'est pas un événement officiel de WordPress.
Sinon, je ne serais peut-être même pas autorisé à y faire référence dans un exposé 12 secondes plus tard.
Le nouvel éditeur de bloc n'est pas non plus sans problèmes. L'éditeur de blocs est construit en utilisant React, qui est un framework JavaScript, très différent de PHP et même de jQuery, qui a été la base de presque toutes les parties de WordPress jusqu'à ce point, React à la courbe d'apprentissage raide. Et bien que le développement d'un bloc ne nécessite pas une compréhension approfondie de React.
Il augmente considérablement la barrière d'entrée car les développeurs doivent comprendre JSX et les compilateurs tels que Webpack pour pouvoir démarrer. Et cela n'aide pas. La documentation peut parfois manquer un peu. Heureusement, il existe des options pour les développeurs traditionnels, des champs personnalisés avancés et des blocs personnalisés Genesis.
Il y en a juste quelques-uns qui vous permettent de créer des blocs personnalisés en utilisant une combinaison de PHP et d'une interface utilisateur. Il y a beaucoup d'autres problèmes avec l'éditeur de blocs, comme une mauvaise accessibilité, mais je pense qu'on pourrait en rester là pour le moment.
Je terminerai par quelques commentaires, non pas sur WordPress, le logiciel, mais sur son écosystème ; en particulier ces derniers temps, il semble y avoir une monopolisation de l'écosystème WordPress. C'est normal dans un marché capitaliste, mais il est également dommage que l'écosystème soit de moins en moins diversifié et de plus en plus contrôlé par quelques grands acteurs.
Parmi les acquisitions récentes, on peut citer Yoast qui vient d'acquérir, Duplicate Post. Automatic acquiert Prosperous, WP engine acquiert Genesis et Flywell Awesome Motive acquiert tout en un SEO, Liquid Web, acquiert The Events Calendar. Et I Themes acquérant Restrict Content Pro, il est évident qu'il n'y a aucun moyen d'en être sûr, mais je pense qu'on peut dire sans risque de se tromper que certaines de ces acquisitions ont eu lieu parce que wordpress.org n'héberge pas de produits payants.
Il y a aussi la question d'Automattic et de la marque WordPress, car Matt Mullenweg dirige à la fois Automattic et la fondation WordPress. Automattic a obtenu le droit exclusif d'utiliser la marque WordPress, se positionnant ainsi comme l'autorité officielle de WordPress, alors que ce n'est pas nécessairement le cas depuis qu'Automattic est entré dans l'espace de développement de sites web personnalisés.
Et cela a entraîné beaucoup de réactions négatives en raison de la manière dont ils sont capables de se positionner. Je pense qu'il est juste de dire que l'utilisation par Automattics de la marque WordPress nuit à la communauté WordPress. Pour ma part, j'ai été blessé lorsque WordPress m'a été recommandé pour la première fois, la première chose qui est apparue dans les résultats de recherche, lorsque je l'ai cherché, c'était wordpress.com.
Et quand j'ai vite découvert qu'il fallait payer pour même écrire des CSS personnalisés, j'ai supprimé WordPress en tant que constructeur de sites web poubelle comme Wix. Et il m'a fallu presque un an avant d'apprendre l'existence du logiciel libre sur lequel il est basé. Automattic a également un peu le monopole de la contribution au logiciel de base de WordPress.
Et cela a conduit certaines personnes à croire qu'Automattic contrôle efficacement la direction que prend WordPress au fur et à mesure que le logiciel évolue. Peut-être que c'est le cas, peut-être pas, mais ils ont certainement plus de poids que n'importe qui d'autre. Je ne dis pas ces choses pour critiquer Automattic ou Matt, mais il va sans dire qu'il y a ici un énorme conflit d'intérêt dont nous devrions tous être conscients.
Merci beaucoup de rester dans le coin. Nous espérons que vous avez maintenant une meilleure compréhension du fonctionnement de WordPress et de certaines de ses limites, ainsi que de la manière de s'y adapter. Bien sûr, cette liste n'est pas exhaustive, mais WordPress est nul. Bien sûr que non. Nous ne serions pas là si c'était le cas. Je m'appelle Camerson Jones et vous pouvez me trouver en ligne dans la plupart des endroits sous le nom de Cameron Jones web.
