Eviter les collisions de noms de plugins avec WP mise à jour
J'ai un client qui a un site WordPress qui utilise un plugin personnalisé écrit pour eux par un autre développeur. Récemment, ils ont exécuté le programme de mise à jour WordPress et l’une des mises à jour a détruit ce plugin personnalisé et l’a remplacé par un plugin du référentiel de plug-ins portant le même nom.
J'essaie de comprendre exactement ce qui doit être changé pour éviter que cela ne se reproduise à l'avenir. Le plugin en question n’avait pas d’identifiant particulièrement unique dans les noms de répertoires/fichiers principaux; imaginez que c'est comme ça:
foo/foo.php
Donc, s'il y a déjà un plugin "Foo" dans le référentiel, il est compréhensible que WP confondre les deux.
D'après ce que j'avais compris dans le passé, le moyen d'éviter ce problème était de mettre un identifiant unique dans ces noms, comme suit:
client-foo/client-foo.php
L'ajout du bit "client", pensais-je, était le moyen de réduire les risques de collision en rendant le plugin spécifique au site WordPress qui l'exécutait.
Cependant, même après avoir renommé les fichiers, j'ai constaté que le programme de mise à jour confondait toujours le plug-in avec le plug-in "foo" dans le référentiel.
Ensuite, j'ai essayé de changer le champ "Nom" dans l'en-tête du métadonnée du plugin, de
Plugin Name: Foo
à
Plugin Name: Foo (Client)
Et ceci semblait éliminer la collision; le programme de mise à jour ne l'a plus signalé comme correspondant au plugin public.
Alors maintenant, je suis confus. Est-ce vraiment le cas que la seule chose que le programme de mise à jour vérifie pour éviter les collisions est le champ de métadonnées Nom du plugin? Cela semble vraiment fragile comparé à la façon dont j'avais pensé le faire (comparer les noms de fichiers), du moins pour moi.
Quoi qu’il en soit, j’ai été incapable de trouver un mot précis sur les informations utilisées par le programme de mise à jour pour effectuer cette vérification, et même si j’ai trouvé cette question précédemment posée le fil de la réponse ne vient jamais et dit "c'est comme ça que ça marche." Alors j'ai pensé que je demanderais.
La manière dont WordPress utilise pour trouver un plugin dans le référentiel n'est pas publique, autant que je sache.
Selon la réponse d'Otto, vous avez lié le lien, il s'agit d'un en-tête d'URL de plug-in à côté du nom du plug-in.
BTW, supprimer le plugin de la liste des plugins à mettre à jour est le meilleur moyen d'éviter que ce problème ne se reproduise: une fois que la méthode de correspondance n'est plus publique, vous ne pouvez pas savoir s'il va changer à l'avenir.
Étant donné que la logique utilisée pour les mises à jour à partir des référentiels officiels est à la fois floue et que les détails exacts sont gardés secrets - il n'est pas possible de les éviter de manière fiable en manipulant simplement les détails.
Pour le moment, la seule pratique fiable consiste à filtrer les données de l'ensemble envoyé pour vérification de la mise à jour. Même cela est très gênant et doit être effectué au niveau de la requête de l'API HTTP. Un des problèmes liés est que si le plugin exclut lui-même , il ne peut pas le faire lorsque est inactif et risque toujours d'être détruit par update. dans ce cas.
Personnellement, j’ai écrit un petit assistant Update Blocker pour cela. Dans les sites plus sérieux, je recommanderais de supprimer complètement les mises à jour et de gérer le site avec Composer.
Alors que WP projet convient généralement qu'il s'agit d'un problème (qui a pris littéralement ans ), le drapeau proposant le désabonnement de l'en-tête est bloqué depuis un moment. , nécessitant des mises à jour sur le site org WordPress. Voir le ticket # 32101 dans le trac de base .