Table des matières de l'article :
La récente conflit entre WordPress et WP Engine a attiré l'attention de la communauté de développement WordPress à l'échelle mondiale. Au centre de la polémique se trouve le plugin Champs personnalisés avancés (ACF), un outil fondamental pour personnaliser les pages d'édition WordPress. Cet article examinera les détails de l'histoire, analysant le contexte, les motivations derrière l'action de WordPress et les implications plus larges pour la communauté des développeurs et des utilisateurs de WordPress.
La naissance du conflit entre WordPress et WP Engine
La polémique est née dans le contexte d'un litige juridique entre Matt Mullenweg, fondateur de WordPress et PDG d'Automattic, et WP Engine, un important fournisseur d'hébergement WordPress. Le centre du différend semble tourner autour d’une série de procès mutuels, d’allégations de confusion en matière de marque et de revendications de droits sur la marque « WordPress ».
Matt Mullenweg a publiquement critiqué WP Engine dans un article de blog, qualifiant l'entreprise de « cancer sur WordPress ». Parmi les critiques soulevées figuraient le manque de prise en charge de l’historique et de la gestion des révisions qui, selon Mullenweg, pourraient faire croire aux utilisateurs que WP Engine était officiellement affilié à WordPress.
Un aspect crucial du litige était la menace de Mullenweg d'intenter une action en justice si WP Engine ne payait pas pour obtenir une licence d'utilisation de la marque WordPress. WP Engine, à son tour, a répondu par ses propres lettres de cessation et d'abstention, augmentant encore la tension entre les parties.
La fourchette des champs personnalisés avancés et la naissance des champs personnalisés sécurisés
Au centre de ce différend se trouve le plugin Champs personnalisés avancés (ACF), une extension fondamentale de l'écosystème WordPress qui a eu un impact énorme sur la capacité des développeurs à personnaliser la plateforme. ACF a été développé par Elliot Condon et lancé pour la première fois en 2011 en tant qu'outil visant à étendre la flexibilité de WordPress en permettant aux développeurs d'ajouter des champs personnalisés aux pages d'édition WordPress. Cela a transformé la façon dont les utilisateurs et les développeurs gèrent le contenu dans WordPress, offrant un niveau de contrôle bien plus élevé sur les données et les informations affichées sur leurs sites.
Qu'est-ce qu'ACF et pourquoi est-il important
ACF se distingue par sa facilité d'utilisation et sa capacité à étendre considérablement les fonctionnalités natives de WordPress, permettant aux développeurs de créer facilement des champs personnalisés pour les types de publications, les pages et les taxonomies. Avant l’avènement d’ACF, WordPress prenait déjà en charge les « champs personnalisés » de manière native, mais l’interface et les fonctions disponibles étaient limitées et peu intuitives pour la plupart des utilisateurs. ACF a comblé cette lacune en fournissant une solution plus robuste et plus conviviale, facilitant l'ajout de champs tels que :
- Texte
- Textarea
- Imagerie
- Fichier
- Sélecteurs de dates
- Déroulante
- Champs du répéteur
Ces champs personnalisés peuvent être utilisés n'importe où sur le site, du backend à l'interface utilisateur. L’adoption d’ACF a permis aux propriétaires, développeurs et concepteurs de sites Web WordPress de créer des solutions hautement personnalisées sans avoir à écrire de code complexe. Cela a fait d'ACF un outil clé pour les agences numériques, les indépendants et les sociétés de développement qui avaient besoin de flexibilité et de personnalisation sans avoir à réinventer la roue.
Le succès d’ACF et le rôle de WP Engine
Au fil des années, ACF a connu une croissance exponentielle et a attiré une communauté dévouée de développeurs et d'utilisateurs. La simplicité avec laquelle il vous permet de personnaliser WordPress a fait qu'il est devenu l'un des plugins les plus utilisés et appréciés, à tel point qu'il a conduit à la création d'une version "Pro", avec des fonctionnalités supplémentaires telles que des champs de répéteur et des fonctionnalités avancées. galeries d'images. L'importance d'ACF pour les développeurs ne peut être sous-estimée, car elle a ouvert de nouvelles possibilités de développement et de conception pour des sites Web complexes, notamment des solutions avancées de commerce électronique, des portails de contenu et des plateformes de gestion de données.
En 2022, WP Engine a acquis ACF ainsi que d'autres plugins populaires, tels que Migrer WP e Média de déchargement WP, apportant avec lui l’expérience acquise dans le secteur de l’hébergement WordPress premium. Cette acquisition marque une étape stratégique importante pour WP Engine, qui consolide sa position de leader non seulement dans l'hébergement, mais aussi dans la gestion des plugins clés de l'écosystème WordPress. Cependant, cela a également apporté une nouvelle dimension au conflit entre WP Engine et WordPress, alimenté par des inquiétudes liées à la concurrence commerciale.
L'intervention WordPress : la création de champs personnalisés sécurisés
Alors que les tensions juridiques entre Matt Mullenweg et WP Engine s’aggravaient, WordPress a décidé de prendre des mesures directes contre ACF, une décision qui a surpris de nombreux membres de la communauté. Mullenweg a annoncé la création d'un fork du plugin ACF, appelé Champs personnalisés sécurisés, justifiant l'action comme une étape nécessaire pour supprimer les références commerciales du plugin et résoudre les prétendus problèmes de sécurité. Bien qu'aucun détail précis n'ait été fourni sur les problèmes de sécurité identifiés, Mullenweg a fait référence au « point 18 » des directives du référentiel de plugins WordPress, qui accorde à WordPress.org le pouvoir de supprimer ou de modifier un plugin sans le consentement du développeur en cas de problèmes de sécurité ou d'intérêt public.
Selon Mullenweg, WP Engine utilisait ACF comme une opportunité pour générer des ventes supplémentaires, contrairement aux principes de WordPress, qui privilégient une approche moins commerciale. Bien que les raisons de sécurité n’aient pas été clairement énoncées, il est clair que WordPress souhaitait limiter l’influence commerciale qu’exerçait WP Engine via le plugin. Cette intervention a donc conduit à la naissance de Champs personnalisés sécurisés, une version alternative du plugin, gérée directement par WordPress et sans finalité commerciale.
Ci-dessous la traduction de communiqué de presse officiel de Matt Mullenweg :
Au nom de l'équipe de sécurité de WordPress, j'annonce que nous invoquons le point 18 des directives du répertoire des plugins et que nous incorporons les champs personnalisés avancés (ACF) dans un nouveau plugin, Secure Custom Fields (SCF). SCF a été mis à jour pour supprimer les promotions commerciales et résoudre un problème de sécurité.
Le 3 octobre, l'équipe ACF a annoncé que les mises à jour du plugin ACF seraient disponibles directement depuis leur site Web. Cela a également été communiqué via un avis de support sur le forum WordPress.org le 5 octobre. Les sites qui ont suivi les instructions de l'équipe ACF sur « Comment mettre à jour ACF » continueront à recevoir les mises à jour directement de WP Engine. Le 1er octobre 2024, WP Engine a également mis en place sa propre solution de mises à jour et d'installations de plugins et de thèmes sur les sites de ses clients, en remplacement du service de mise à jour WordPress.org.
Les sites qui continuent d'utiliser le service de mise à jour de WordPress.org et qui n'ont pas choisi de passer aux mises à jour ACF à partir de WP Engine peuvent cliquer pour mettre à niveau et passer aux champs personnalisés sécurisés. Dans les cas où les sites ont activé les mises à jour automatiques des plugins via WordPress.org, ce processus de mise à jour les déplacera automatiquement des champs personnalisés avancés vers les champs personnalisés sécurisés.
Cette mise à jour est aussi minimale que possible pour résoudre le problème de sécurité. Désormais, Secure Custom Fields sera un plugin non commercial, et si des développeurs souhaitent participer à sa maintenance et à son amélioration, ils sont invités à nous contacter.
Des situations similaires se sont produites dans le passé, mais pas à cette échelle. Il s'agit d'une situation rare et inhabituelle causée par les attaques juridiques de WP Engine, et nous ne nous attendons pas à ce que cela se produise avec d'autres plugins.
WP Engine a publié des instructions sur la façon d'utiliser sa version de Advanced Custom Fields qui utilise son serveur de mise à jour. Vous disposez donc de cette option, bien que l'équipe de sécurité de WordPress ne la recommande pas tant que les problèmes de sécurité ne sont pas résolus. Vous pouvez désinstaller Advanced Custom Fields et activer Secure Custom Fields à partir du répertoire des plugins sans aucun problème.
Il y a aussi d'autres nouvelles distinctes, mais pas directement liées : Jason Bahl a quitté WP Engine pour travailler avec Automattic et fera de WPGraphQL un plugin communautaire canonique. Nous espérons que d’autres suivront.
La réaction de WP Engine
WP Engine n’a pas tardé à réagir à cette décision. L'équipe d'ACF a exprimé sa déception sur les réseaux sociaux, affirmant que WordPress avait pris « de force et unilatéralement » le contrôle du plugin sans leur consentement, ce qui, selon eux, ne s'était jamais produit au cours des 21 ans d'histoire de WordPress.
Cette déclaration a suscité des réactions mitigées au sein de la communauté WordPress, certains développeurs remettant en question la légitimité de l'action de WordPress, tandis que d'autres ont soutenu que, compte tenu de la nature open source de la plateforme, WordPress avait le droit de prendre cette décision dans l'intérêt du public. sécurité.
Dans ce cas également, voici la traduction italienne du Communiqué de presse du moteur WP et plus particulièrement l'équipe Advanced Custom Fields :
Nous sommes profondément attristés et consternés par les actions de Matt Mullenweg ce matin, qui s'est approprié le plugin Advanced Custom Fields, que notre équipe ACF développe activement pour la communauté WordPress depuis 2011.
Advanced Custom Fields est un plugin sophistiqué avec plus de 200.000 15 lignes de code, que nous continuons à développer, améliorer, prendre en charge et dans lequel nous investissons pour répondre aux besoins de nos utilisateurs sur WordPress. Au cours des deux dernières années, depuis que nous avons rejoint WP Engine, nous avons publié plus de XNUMX mises à jour et ajouté des fonctionnalités importantes au plugin gratuit, améliorant constamment les performances ainsi que nos pratiques de sécurité et de test pour garantir à nos utilisateurs le niveau « entreprise » qu'ils méritent.
Le changement dans notre distribution publiée, et sous notre « slug » qui identifie de manière unique le plugin ACF et le code sur lequel nos utilisateurs s'appuient dans le référentiel WordPress.org, est incompatible avec les valeurs et les principes de l'open source. La modification apportée par Mullenweg est utilisée de manière malveillante pour mettre à jour des millions d'installations ACF existantes avec du code non approuvé et non fiable par l'équipe Advanced Custom Fields.
Nous pouvons protéger directement les clients WP Engine, Flywheel Hébergement et ACF PRO : vous n’êtes pas impacté et n’avez aucune démarche à entreprendre. Vous continuerez à recevoir les dernières innovations et mises à jour des experts de l’équipe ACF. Le code ACF sur wordpress.org n'est plus contrôlé par l'équipe ACF.
Si vous disposez d'un site géré ailleurs à l'aide de la version gratuite d'ACF, pour obtenir de véritables mises à jour d'ACF, vous devez effectuer un téléchargement unique de la version 6.3.8 via advancedcustomfields.com pour rester en sécurité à l'avenir. Après ce téléchargement unique, vous pourrez mettre à jour comme d'habitude via votre panneau d'administration WordPress.
Vous pouvez suivre la même démarche si votre site a déjà été mis à jour vers le plugin « Secure Custom Fields » modifié, pour revenir à une version authentique d'ACF.
Les actions de Mullenweg sont extrêmement préoccupantes et présentent un risque grave de perturber et d'endommager irrémédiablement l'ensemble de l'écosystème WordPress. Sa tentative de prendre unilatéralement le contrôle de cette plateforme ouverte, sur laquelle nous et de nombreux autres développeurs et contributeurs de plugins nous sommes appuyés dans un esprit de partage des plugins pour tous, fournit une preuve supplémentaire de son grave abus de confiance, de ses nombreux conflits d'intérêts et de sa violation des des promesses d’ouverture et d’intégrité au sein de la communauté.
L'impact pour les utilisateurs d'ACF
L’un des aspects les plus controversés de cette histoire concerne l’impact sur les utilisateurs du plugin ACF. Avec WordPress reprenant ACF et créant des champs personnalisés sécurisés, les utilisateurs devront choisir entre deux versions du plugin : la version originale, maintenue par WP Engine, et la nouvelle version forkée gérée par WordPress.
Pour les utilisateurs de la version gratuite d'ACF, WP Engine a publié une solution temporaire qui vous permet de télécharger manuellement la dernière version du plugin d'origine (6.3.8) depuis le site ACF. Cependant, les utilisateurs Pro continueront de recevoir les mises à jour directement de WP Engine, créant un fossé potentiel entre ceux qui utilisent la version gratuite et ceux qui utilisent la version payante.
Les implications pour la communauté WordPress
Cet événement a ouvert un débat important au sein de la communauté WordPress sur plusieurs sujets, notamment la gouvernance des plugins, le rôle des développeurs commerciaux et la protection des utilisateurs. L’un des aspects les plus discutés est de savoir si WordPress devrait avoir le pouvoir de prendre des décisions unilatérales concernant les plugins développés par des tiers, en particulier lorsqu’il s’agit de développeurs commerciaux comme WP Engine.
D'une part, l'action de WordPress peut être considérée comme une démarche nécessaire pour protéger les utilisateurs contre d'éventuelles vulnérabilités de sécurité et pour préserver la philosophie open source de la plateforme. En ce sens, la suppression des ventes supplémentaires au sein d’un plugin gratuit peut être interprétée comme une tentative de garantir une expérience utilisateur cohérente et transparente, exempte de poussées commerciales qui pourraient fausser l’approche libre et collaborative sur laquelle repose WordPress. La décision de créer un fork d'ACF sous le nom de « Secure Custom Fields » pourrait se justifier, selon WordPress, par la nécessité de fournir un plugin sécurisé, sans liens commerciaux, qui puisse être géré et maintenu par la communauté.
D’un autre côté, cependant, de nombreux développeurs considèrent cette action comme non provoquée et politiquement motivée. La perception est qu'il s'agit d'une tentative de boycott de WP Engine, notamment suite au conflit concernant la demande d'une redevance de 8% du chiffre d'affaires en guise de paiement pour continuer à maintenir le plugin ACF dans le référentiel officiel WordPress. Cet événement suscite des inquiétudes non seulement pour WP Engine, mais aussi pour l’ensemble de la communauté des développeurs. Beaucoup se demandent si ce type d’intervention de WordPress pourrait créer un précédent pour de futurs cas d’interférence, notamment lorsque des plugins ou des développeurs ayant des intérêts commerciaux sont impliqués.
La principale préoccupation des critiques de cette décision est que WordPress pourrait commencer à exercer trop de contrôle sur la façon dont les plugins sont gérés, distribués et commercialisés au sein de la plateforme. Bien que la protection de la sécurité et le respect des principes de l'open source soient essentiels, on craint que la liberté des développeurs d'innover, de monétiser et de distribuer leurs produits ne soit compromise. La communauté se demande si de telles interventions pourraient se transformer en une forme de contrôle centralisé, mettant à mal l’indépendance sur laquelle WordPress a bâti sa réputation. Si WordPress peut intervenir unilatéralement dans un cas comme ACF, il pourrait le faire à nouveau, introduisant une incertitude pour les développeurs qui fondent leur travail sur cette plateforme.
Conclusions
Le différend entre WordPress et WP Engine au sujet d’ACF représente un moment charnière pour tout l’écosystème WordPress, avec des implications qui vont bien au-delà de la gestion d’un seul plugin. La décision de WordPress de forcer un fork du plugin ACF, en créant des champs personnalisés sécurisés, ouvre une série de questions fondamentales liées à la gouvernance de la plateforme, à la sécurité et aux droits des développeurs. Cependant, la portée de cette action doit également être considérée à la lumière des conséquences potentielles pour les autres acteurs commerciaux opérant au sein de l’écosystème WordPress.
WP Engine n'est pas seulement un développeur de plugins, mais un véritable acteur majeur du secteur de l'hébergement WordPress, avec une position de premier plan qui a peut-être attiré l'attention d'Automattic en raison de son influence croissante et de ses litiges juridiques. Ce rachat du plugin ACF par WordPress pourrait créer un précédent pour d’autres situations similaires à l’avenir, et d’autres acteurs commerciaux pourraient se retrouver dans une position vulnérable s’ils venaient à entrer en conflit avec WordPress ou Automattic.
Prenez, par exemple, des plugins commercialement pertinents comme WP Rocket, un plugin d'optimisation de cache largement utilisé, ou Elementor, le constructeur de pages populaire qui a construit tout un écosystème de produits et de services autour de WordPress. Elementor lui-même propose une solution d'hébergement appelée Elementor Hosting, qui pourrait être perçue comme un concurrent potentiel des services d'hébergement d'Automattic, tels que WordPress.com, WP VIP, et de la partie moins connue mais toujours stratégique du portefeuille d'hébergement d'Automattic, Pressable.
Si WordPress décide d’appliquer le même traitement accordé à WP Engine à d’autres sociétés, cela pourrait conduire à une situation où Automattic et WordPress.org utiliseraient leur pouvoir pour intervenir dans des plugins et des services commerciaux perçus comme des menaces concurrentielles. Elementor lui-même pourrait être considéré comme un concurrent direct des constructeurs de pages intégrés et des services d'hébergement Automattic de WordPress. Il en va de même pour WP Rocket, qui pourrait un jour être confronté à un « fork » similaire ou à d’autres actions limitant son potentiel commercial.
Le plus gros problème est que ce type d’actions unilatérales risque de décourager l’innovation et de créer une culture d’incertitude parmi les développeurs de plugins et les entreprises qui créent des services autour de l’écosystème WordPress. La perception selon laquelle WordPress peut prendre le contrôle de projets réussis sans le consentement du développeur remet en question la confiance de ceux qui ont contribué à rendre la plateforme si polyvalente et si populaire à ce jour. Si ces décisions étaient appliquées plus largement, elles pourraient déstabiliser l’écosystème WordPress, entraînant des conflits entre la communauté open source et les entreprises qui bâtissent leurs activités sur la plateforme.
Il est donc vital que la communauté WordPress réfléchisse attentivement à ces évolutions. Il ne s'agit pas seulement de protéger la plateforme et ses utilisateurs contre d'éventuels problèmes de sécurité, mais aussi de préserver les principes de l'open source, où la collaboration et l'innovation doivent être soutenues sans risque d'interférence commerciale. Si la gouvernance de WordPress devient trop centralisée, cela pourrait créer un environnement dans lequel seuls les acteurs affiliés à Automattic seraient libres d’opérer sans souci, limitant ainsi la liberté d’innovation des autres développeurs et entreprises.
Il faudra attendre les prochains mois pour comprendre à quel point cette action a été néfaste pour l'ensemble de l'écosystème et de la communauté WordPress, sans oublier de suivre le dossier juridique opposant WP Engine à Automattic, au vu de ce qui apparaît à toutes fins utiles comme une extorsion. tentative d'Automattic contre WP Engine.
