Plugin SVN & update API - comment les plugins sont-ils identifiés?


11

Une chose qui n'a jamais été claire pour moi (surtout depuis que je n'ai pas soumis de plugin au référentiel) est de savoir comment "l'ID" unique du plugin (slug) est généré (c'est -à- dire cette liste ).

  1. Est-ce un choix de l'auteur au moment de la soumission de SVN, ou par un modérateur?
  2. Est-ce le nom (titre) du plugin aseptisé?
  3. Est-ce le plugin_basename?
  4. S'agit-il du fichier plugin principal (sans le nom du répertoire)?
  5. Autre chose?

Je suis curieux de savoir quel (s) attribut (s) d'un plugin le lier à son homologue SVN (s'il en a un) pour l'API de mise à jour du plugin?

Je demande, en partie hors de ma nature de vouloir savoir, mais aussi comment m'assurer (dans une certaine mesure), mes propres plugins uniques ne seront pas en conflit avec un dans le SVN.

Par exemple, si ce n'était que 3) , je pourrais utiliser un nom de répertoire très unique, mais garder mon nom de plugin (titre) court et doux.


NB Bien que la convention de dénomination de fichier "standard" semble être [my-plugin-name]/[my-plugin-name].php, je suis devenu amoureux de [my-plugin-name]/plugin.php.

Cela donne à tous mes plugins une certaine cohérence, il est clair que c'est le fichier "bootloader" (principal), et d'un petit point de vue, je déteste la répétition du nom du répertoire.

C'est une autre raison pour laquelle je pose la question, car 4) me ferait chier. De plus, j'aimerais aussi avoir votre avis sur cette "norme" :)


Réponses:


6

Lors de la soumission d'un plugin, le slug devient le nom du plugin aseptisé, tel que soumis. Le "Nom" du plugin peut changer après cela, mais le slug reste toujours le même.

Lorsque WordPress doit rechercher une mise à jour du plug-in, il obtient toutes les informations d'en-tête du plug-in et le nom du répertoire dans lequel se trouve le plug-in, et les envoie à WordPress.org.

Trois facteurs sont actuellement utilisés pour essayer de faire une correspondance avec les plugins du répertoire. Notez que je dis "actuellement", car cela change de temps en temps lorsque nous essayons d'améliorer les algorithmes de correspondance.

  1. Le nom du répertoire du plugin est souvent le "slug" du plugin. Au moins, c'est si vous l'avez installé à partir du répertoire pour commencer. Nous recherchons donc un slug avec ce nom de répertoire. Ce n'est pas un bon indicateur, mais cela aide.

  2. Le "Nom" dans l'en-tête du plugin est également recherché, car le nom doit être unique dans le répertoire du plugin. S'il n'y a pas de correspondance sur ce nom exact, le nom est aseptisé pour produire une limace, et nous recherchons également cette limace, juste au cas où. Cela ne fonctionne pas toujours.

  3. L'URI du plugin dans l'en-tête est également vérifié pour une correspondance. Puisque nous connaissons cette valeur pour tous les plugins du répertoire, cela peut être considéré comme raisonnablement unique pour chaque plugin. Ainsi, les auteurs de plugins sont bien avisés de mettre un URI de plugin qui pointe vers un domaine qu'ils contrôlent et une URL unique pour le plugin.

Ces trois facteurs sont ensuite pondérés et le résultat supérieur est renvoyé. Les pondérations utilisées pour chacun des trois reflètent un niveau de confiance dans l'exactitude des données. Par exemple, Name est plus lourd que le plugin-directory-as-slug, car la plupart des auteurs ne changent pas très souvent les noms de plug-in, et plugin-directory peut en fait être n'importe quoi si l'utilisateur l'a installé manuellement ou quelque chose.

Plus la correspondance avec ces trois éléments est proche, plus il est probable que cela corresponde au plugin. Mais au moins une correspondance exacte doit être trouvée pour que tout résultat soit renvoyé.

Pour les plugins personnalisés uniques, j'ai tendance à utiliser le nom du site dans le nom du plugin lui-même. Cela m'aide aussi avec l'organisation. Donc, mon nom de plugin unique pourrait être "ottopress.com - Résoudre le problème avec quoi que ce soit". Il est peu probable qu'un plugin de l'annuaire corresponde à votre domaine.


Impressionnant! Je ne pense pas que je serai le seul à apprécier cette réponse;)
TheDeadMedic

2

Étant donné que l'entrée SVN est évidemment créée avant de valider votre plug-in pour la première fois - elle est basée sur votre demande d'entrée initiale. Je ne sais pas si le processus est technique ou manuel, probablement un peu des deux.

À des fins de mise à jour, un tas d'informations est soumis et le référentiel essaie de déterminer la correspondance - en fonction du nom du plugin, du nom du répertoire, de la version actuelle et éventuellement plus. Je ne sais pas si l'algorithme exact a été publié.


1
Je me souviens de @ otto42 dans le passé, indiquant que AuthorURI est utilisé comme un jeton unique dans ce processus, car, bien que le plugin Slug puisse se heurter, la combinaison de Plugin slug et AuthorURI ne le sera presque jamais.
Chip Bennett

Bravo les gars - il est donc assez clair que ce n'est pas simplement un attribut particulier. Ce serait quand même un aperçu de voir l'algorithme. Des réflexions sur ma convention de dénomination de fichier?
TheDeadMedic

Le nom de fichier @TheDeadMedic n'a pas beaucoup d'importance en général, je ne pense pas qu'il suffirait à lui seul de confondre la logique de mise à jour.
Rarst
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.