Автоматически определить минимальную версию WordPress, необходимую для плагина?

22

При разработке плагина есть ли способ автоматически определить минимальную версию WordPress, которая требуется для его запуска? Я хочу убедиться, что Requiresзаголовок точен, но проверка вручную каждый раз, когда я вызываю новую базовую функцию, утомительна и подвержена ошибкам.

Я думаю, что сценарий может понять это достаточно легко:

  1. Сканирование всех файлов в плагине.
  2. Разбираем из всех инстанциацию класса и вызовы функций , основанные на new foo( [...] ), foo::bar( [...] ), bar( [...] ),call_user_func( [...] ) и т.д. синтаксис.
  3. Разобрать исходный текст WP, чтобы определить, когда каждый из этих классов / функций был добавлен в WordPress, используя @since помощью тега phpDoc.
  4. Создайте отчет, в котором перечислены все классы / функции и версия, в которую они были добавлены, а также самая ранняя версия WordPress, включающая все классы / функции.

Я оглянулся, но ничего подобного не нашел, и у меня нет времени, чтобы написать это самому. Кто-нибудь знает о существующем решении?

plugin-development wordpress-version automation Ян Данн
источник
Вы видели это, wordpress.org/extend/plugins/log-deprecated-notices
Wyck
Это было бы хорошим началом, спасибо за указание на это :)
Ян Данн
@IanDunn Если вам удалось найти решение, пожалуйста, поделитесь им. :)
its_me
Я еще не нашел решение.
Ян Данн
2
Чем больше я думаю об этом, тем больше кажется, что WordPress должен просто создать это и запустить его для всех плагинов в репозитории, чтобы номер версии был точным для всех плагинов навсегда.
mrwweb

Ответы:

14

Я нашел решение в виде автоматизированного сервиса на http://wpseek.com/pluginfilecheck/

Это именно то, что было запрошено, включая создание списка используемых функций и предложение комментариев для заголовка плагина.

carstenbach
источник
Это довольно круто, спасибо :) Я думаю, было бы намного удобнее, если бы это был сам плагин WordPress, а не веб-сервис, но это лучше, чем ничего.
Ян Данн
2
К сожалению, он также «на файл» - поэтому нет загрузки всего плагина. Но все же очень полезный ресурс - отличная находка!
Стивен Харрис
2
Этот сервис теперь поддерживает загрузку zip-файлов, и он автоматически сканирует все файлы внутри него :)
Ian Dunn
Есть ли способ добавить это ( de.wpseek.com/pluginfilecheck ) или другую альтернативу в статическом анализе плагина во время сборки, чтобы мне не нужно было заходить на вышеуказанный сайт, чтобы снова проверить n, и система сборки будет автоматически генерировать отчет вместе с другим статическим анализом при каждом коммите.
learning_13
3

Обновление: это больше не точно. Смотрите ответ Карстенбаха .

Что ж, похоже, ответ «Нет, для этого не существует решения».

Если кто-то хочет написать один, это может быть полезно:

Я думаю, что комментарий Марка о встраивании этой функции в репозиторий WordPress.org - это действительно хорошая идея, но, возможно, сообщество сначала должно создать его, чтобы доказать, что оно полезно, прежде чем основная команда рассмотрит возможность его добавления.

Ян Данн
источник
2

Ну, это скорее отправной точкой, но это хороший список функций WP и версий они были добавлены / удалены здесь . К сожалению, он подходит только для WP 3.0.1, но если вы используете версию 3.0 в качестве базовой, это как минимум поможет - если его нет в списке, он был добавлен позже. Возможно, вы захотите написать Ozh по электронной почте и попросить его обновить список, и если кто-то из нас поймет, кто-то может создать плагин для проверки (например, обратная проверка устаревания) ).

ETA: Per @mrwweb - Список крючков Адама Брауна ! Текущий до 3.3 и идет вааааай обратно к 1.2.1, который никто в здравом уме больше не будет запускать (дата релиза 6 октября 2004 г.).

SickHippie
источник
2
Я бы добавил список хуков Адама Брауна по версии (обратно к 1.2.1!), С которыми также было бы неплохо проверить.
mrwweb
Спасибо за ссылку на плагин Deprecation Checker, который может предоставить некоторый полезный код, на котором можно будет остановиться, если у меня будет время написать это.
Ян Данн,
Это замечательный плагин, созданный пользователем WPSE Брайаном Фегтером.
SickHippie
0

Я думаю, что ответ лежит в устаревших уведомлениях - вы должны разрабатывать с WP_DEBUG true - независимо от того, отображаете ли вы их или регистрируете их, это ваш вызов, но WP сообщит вам, если вы используете устаревшую функцию.

Можно было бы проанализировать @since, как вы говорите, но инструменты могут занять вас только далеко - знакомство с базой кода и ручная проверка могут быть подходящим вариантом.

Крис Кокс
источник
1
Я думаю, что вы ответили на вопрос наоборот. Вопрос состоит в том, чтобы определить, насколько далеко назад идет поддержка функций, которые в настоящее время поддерживаются (например, функция, которую использует ваш плагин, была введена в 3.1, поэтому ваш плагин не работает в более ранних версиях, но эта функция не выдает ошибку или уведомление потому что это поддерживается сейчас.)
mrwweb
Вы правы, служите мне прямо за публикацию усталости. Тогда я бы посоветовал вручную проверить его по сравнению с последней основной версией и использовать его в качестве произвольной отправной точки, потому что в интересах каждого поощрять пользователей обновлять свои WP. После того, как начальная точка установлена, сообщения о фиксации, вероятно, являются лучшим местом для поиска обновленной версии Required, так как там следует отметить любой рефакторинг, чтобы избежать устаревших функций и методов.
Крис Кокс
Глядя на wordpress.org/about/stats, я бы сказал, что 3.2 - это хорошая версия, так как любые более ранние версии статистически незначимы.
Крис Кокс
Спасибо за идеи, Крис, но главный толчок здесь заключался в том, чтобы получить автоматизированное решение. Тем не менее, вы делаете хороший вывод о том, что версии старше 3.2 статистически незначимы.
Ян Данн,
Я заключу с тобой сделку - дай мне знать, если ты сдашься и напишешь одну, и я дам тебе знать, если найду время написать одну. Это хорошая идея и будет полезным инструментом в любом наборе инструментов.
Крис Кокс