Больше никаких случайных пользовательских переопределений плагинов, WordPress 5.8 позволяет разработчикам устанавливать имя хоста плагина

Почти с тех пор, как более десяти лет назад в ядро ​​были включены механизмы обновления плагинов и тем, сторонние разработчики просили предоставить простой способ обойти систему. WordPress 5.8 наконец выполнит этот запрос функции .

Хотя фильтровать систему обновлений можно уже давно, методы для этого были более сложными, чем требовалось. Они также требовали, чтобы сам плагин был активен на сайте. Давно пора установить простой флаг для включения / отключения функции для каждого плагина.

«Утилита заключается в том, что это абстрактный API, который позволяет две вещи», – написал Дион Халс в запросе на извлечение GitHub, в котором был исправлен код:

• Плагин для объявления URI / строки, которая, если установлена, API обновления WordPress.org игнорирует плагин.
• Код, запущенный на сайте, может использовать эти заголовки hostname / data, чтобы предлагать обновление для плагина, которое будет сохранено в переходном процессе обновления, без необходимости перепрыгивать через обручи, такие как переопределение переходного процесса / слишком частая проверка / и т. д.

WordPress 5.8 будет иметь новое Update URI поле заголовка плагина . Если его значение совпадает с чем- https://wordpress.org/plugins/{$slug}/либо w.org/plugin/{$slug}, кроме или , WordPress не будет пытаться его обновить.

Кроме того, разработчики могут развернуть свои собственные решения, если они хотят обрабатывать обновления для плагинов, отличных от WordPress.org. Вот где update_plugins_{$hostname} в игру вступает новый фильтр. WordPress проанализирует URL-адрес, включенный в Update URI заголовок плагина, и использует имя хоста в качестве значения. Затем разработчики могут подключиться к нему и делать все, что им нужно.

Авторам плагинов с расширениями, размещенными на WordPress.org, не нужно будет беспокоиться о добавлении этого нового заголовка. Правило № 8 руководства по плагинам уже запрещает отправку исполняемого кода через сторонние системы. В следующем подразделе этот сценарий рассматривается более конкретно:

Обслуживание обновлений или иная установка плагинов, тем или надстроек с серверов, отличных от WordPress.org.

13 месяцев назад дискуссия о билетах шестилетней давности разгорелась . «Теперь у меня был плагин, бесцеремонно удаленный с веб-сайта клиента, когда было запущено запланированное автоматическое обновление плагина», – написал участник с именем пользователя Apedog . «На самом деле это второй раз, когда я сталкиваюсь с проблемой конфликта имен для моего плагина. В обоих случаях я выбрал имя плагина без априорного конфликта имен. Однако позже кто-то еще написал плагин с тем же общим именем и отправил его в репозиторий wp.org. С этого момента нормальная работа моего плагина нарушена ».

Хотя проблема с удалением оказалась не для WordPress, возможно, это была начало, необходимое для продолжения разговора.

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

Билет на плагины принят и передан в WordPress. Тем не менее, все еще остается вопрос, удастся ли это сделать для тем. Движение в тематическом билете 11-летней давности указывает на то, что это могло произойти.