Команда WordPress Performance работает над разделением плагина Performance Lab

Группа производительности WordPress собралась на этой неделе с конкретной целью ответить на недавний запрос Мэтта Малленвега о прекращении добавления функциональности в плагин Performance Lab , который в противном случае мог бы работать как отдельный плагин.

В конце декабря 2022 года группа Performance Team опубликовала инструкции по тестированию новой реализации SQLite , которая была включена в подключаемый модуль Performance Lab в виде модуля. Малленвег прокомментировал сообщение, указав, что он считает функциональность SQLite более подходящей для того, чтобы стать отдельным плагином сообщества:

Можем ли мы сделать это отдельным плагином сообщества, надеюсь, он станет каноническим, и перестанем помещать дополнительные вещи, подобные этому, в Performance Lab — такое ощущение, что мы впихиваем вещи в PL без необходимости.

В середине октября я потребовал, чтобы мы прекратили это ненужное связывание с @tweetythierry вокруг WebP, который был помещен в Performance Lab, поэтому разочаровывает, что другая большая функция, такая как SQLite, была объединена в плагин Performance Lab.

Стремясь активизировать базу тестировщиков для будущих функций производительности, команда производительности склонилась к объединению новых функций, связанных с производительностью, в плагин. Хотя они уже разработаны как автономные модули, поэтому их можно легко извлечь как отдельные плагины, проблема заключается в том, что их видимость будет значительно снижена. Плагин Performance Lab имеет более 30 000 активных установок. Любому автономному плагину потребуется время, чтобы создать пользовательскую базу, тогда как функциональность, добавленная в Performance Lab, имеет мгновенную аудиторию.

«Согласен с тем, что существуют определенно допустимые варианты использования для автономных плагинов, помня о некоторых преимуществах единого плагина-концентратора, таких как разработка/обслуживание, принятие, продвижение, адаптация/вклад разработчиков и т. д., которые Performance Lab сегодня хорошо облегчает как плагин центра сообщества, ориентированный на центральную производительность», — сказал участник Performance Team Тьерри Мюллер в ответ на запрос о разделении.

Мюллер обрисовал в общих чертах три различных варианта, которые участники обсуждали на собрании Performance Team на этой неделе :

• Вариант 1: оставить PL как есть, но дополнительно развернуть модули как отдельные плагины.
• Вариант 2: Сделать PL «оболочкой», ориентированной на центральную инфраструктуру и рекомендацию отдельных плагинов.
• Вариант 3: полностью отказаться от PL в пользу отдельных плагинов

Вариант 3 кажется наименее привлекательным для тех, кто участвовал в обсуждении на этой неделе, поскольку он создает больше препятствий для обнаружения. Сотрудник Performance Team Феликс Арнц отметил, что одним из преимуществ варианта 1 является то, что плагин будет продолжать работать как есть для 30 000 человек, у которых он уже установлен, а вариант 2 «потребует сложной миграции, которую пользователи, вероятно, не поймут».

Разработчик WordPress Джонни Харрис предположил, что наличие каждой функции в отдельном плагине помогает при тестировании, но также спросил, что определяет модуль.

«Будут ли, например, выполняться все текущие проверки работоспособности сайта?» — спросил Харрис. «SQLite и WebP явно являются отдельными модулями, но как насчет более мелких вещей?»

Арнц предложил участникам продолжить обсуждение того, как текущие модули могут распространяться в виде плагинов. Он предложил, чтобы каждый модуль мог стать отдельным плагином, где некоторые модули стали бы автономными плагинами, а другие были бы сгруппированы в несколько плагинов, «конкретных по теме».

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