Плагін SVN та API оновлення - як ідентифіковані плагіни?

Одне, що мені ніколи не було зрозумілим (тим більше, що я не подав плагін у сховище), - це те, як генерується унікальний "ідентифікатор" (slug) плагіна (тобто цей список ).

1. Це вибір автора в точці подання SVN або модератором?
2. Це санітоване ім'я плагіна (назва)?
3. Це plugin_basename?
4. Це основний файл плагінів (без імені каталогу)?
5. Щось ще?

Мені цікаво, який атрибут (-ів) плагіна пов'язують його зі своїм аналогом SVN (якщо у нього є) для API оновлення плагінів?

Я прошу, частково від природи, хотіти знати, але і як (певною мірою) забезпечити, щоб мої власні одноразові плагіни не стикалися з одним у SVN.

Наприклад, якби було лише 3) , я міг би використовувати дуже унікальне ім’я каталогів, але зберегти своє ім'я плагіна (назва) коротке «n солодке».

NB Хоча, здається, "стандартний" файл іменування файлів, схоже [my-plugin-name]/[my-plugin-name].php, я захоплювався [my-plugin-name]/plugin.php.

Він надає всім моїм плагінам певну послідовність, зрозуміло, що це "завантажувач" (головний) файл, і з дрібної точки зору я ненавиджу повторення імені каталогу.

Це ще одна причина, що я задаю це питання, оскільки 4) накрутить мене. Плюс я також хотів би почути ваші думки щодо цього "стандарту" :)

Під час подання плагіна слизь стає надісланим іменем плагіна, як подано. "Ім'я" плагіна може змінитися після цього, але кухоль назавжди залишається тим самим.

Коли WordPress потрібно перевірити наявність оновлення плагіну, він отримує всю інформацію про заголовок плагіна та ім’я каталогу, в якому знаходиться плагін, і надсилає його на WordPress.org.

В даний час використовуються три фактори, щоб спробувати зрівнятися з плагінами в каталозі. Зауважте, що я кажу "наразі", оскільки це змінюється так часто, як ми намагаємося вдосконалити алгоритми відповідності.

1. Ім'я каталогів плагінів часто є "слизом" плагіна. Принаймні, це якщо ви встановили його з каталогу, для початку. Таким чином, ми перевіряємо, чи є слуг із цим ім'ям каталогу. Це не чудовий показник, але він допомагає.

2. Також шукається "Ім'я" у заголовку плагіна, оскільки ім'я повинно бути унікальним у каталозі плагінів. Якщо немає такої точної назви, то ім'я захищається від слизу, і ми також шукаємо цього слима, про всяк випадок. Це не завжди працює.

3. "URI плагіна" у заголовку перевіряється також на відповідність. Оскільки ми знаємо це значення для всіх плагінів у каталозі, то це може вважатися досить унікальним для кожного плагіна. Таким чином, авторам плагінів рекомендується ввести URI плагіна, який вказує на домен, яким вони керують, і URL-адресу, унікальну для плагіна.

Усі три цих коефіцієнта потім зважуються, і повертається верхній результат. Ваги, використані для кожної з трьох, відображають рівень довіри до точності даних. Наприклад, ім'я важить вище, ніж плагін-каталог-як-слуг, оскільки більшість авторів не змінюють імена плагінів дуже часто, і плагін-каталог може бути будь-чим, якщо користувач встановив його вручну чи щось.

Чим ближче збіг до цих трьох елементів, тим більше шансів на те, що він відповідає плагіну. Але принаймні одна точна відповідність повинна бути знайдена для повернення будь-якого результату.

Для користувацьких одноразових плагінів я, як правило, використовую ім’я сайту в самому імені плагіна. Це допомагає і мені в організації. Тож мій одноразовий плагін може бути "ottopress.com - виправити проблему з будь-чим". Навряд чи будь-який плагін у каталозі відповідає вашому домену.

Оскільки запис SVN, очевидно, створений перед тим, як здійснити плагін вперше - він ґрунтується на вашому первинному запиті на введення. Я не знаю, чи процес є технічним чи ручним, можливо, трохи і того, і іншого.

Для оновлення подається купу інформації, і сховище намагається визначити відповідність на основі імені плагіна, імені каталогу, поточної версії та, можливо, іншого. Мені невідомо, чи точний алгоритм коли-небудь публікували