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

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

Говорят, что плагины Canonical предлагают способ продолжать улучшать WordPress в более сжатые сроки.

Но некоторые участники ядра WordPress выразили мнение, что пользовательский опыт издателя может пострадать.

Канонические плагины

Канонические плагины, впервые обсуждавшиеся в 2009 году, — это способ разработки новых функций в виде плагинов.

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

В первоначальном предложении 2009 года это описывалось так:

«Канонические плагины — это плагины, которые разрабатываются сообществом (несколько разработчиков, а не один человек) и удовлетворяют самые популярные запросы функциональности с превосходным исполнением.

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

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

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

Интеграция канонических плагинов в само ядро ​​WordPress будет рассмотрена после того, как технология плагинов зарекомендовала себя как популярная и необходимая для большинства пользователей.

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

Плагин-сначала можно увидеть в соответствии с философией WordPress под названием «Решения, а не варианты», которая направлена ​​​​на то, чтобы не обременять пользователей слоями технических опций.

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

Философия дизайна WordPress гласит:

«Наш долг как разработчиков — принимать разумные дизайнерские решения и не перекладывать бремя технического выбора на наших конечных пользователей».

Будущее за плагинами Canonical?

Мэтт Мулленвег опубликовал пост под названием «Пересмотр канонических плагинов», в котором он привел доводы в пользу того, что WordPress следует развивать в будущем.

Он написал:

«Мы приближаемся к моменту, когда ядро ​​должно быть более редакционным и говорить «нет» функциям, которые появляются так случайно, как они иногда делают, и я надеюсь, что больше команд Make используют это как возможность влиять на будущее WordPress через подход, ориентированный на плагины, который дает им роскошь более быстрых циклов разработки и выпуска (вместо трех раз в год), меньших накладных расходов на проверку и пути к внедрению в ядро, если плагин станет безудержным успехом».

Первой жертвой этого нового подхода стала отмена интеграции преобразования изображений WebP в следующую версию WordPress, WordPress 6.1, которая в настоящее время запланирована на ноябрь 2022 года.

Plugin-First вызывает споры

Переход к процессу разработки плагинов обсуждался в разделе комментариев.

Некоторые разработчики, такие как основной участник Джон Браун, высказали оговорки по поводу предложения перейти на разработку с использованием канонических плагинов.

Они прокомментировали:

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

Плагины — это не удобный вариант основных настроек. Сначала пользователи должны обнаружить, что есть плагин, затем они согласовали еще один экран настроек, обновления и обслуживание этого плагина».

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

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

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

Они продолжили:

«Теперь я действительно думаю, что плагины Canonical — это лучшая ситуация, чем 6+ раздутых плагинов, которые существуют здесь, но для этого нужно добавить один флажок на страницу настроек в ядре. Это еще больше улучшит UX и проблемы обнаружения, присущие плагинам».

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

«Канонические плагины» кажутся вооруженным инструментом для срыва дискуссий, так же, как «решения, а не варианты» стали годами».

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

Другие также не согласились с подходом, основанным на плагинах:

«Канонический плагин звучит грандиозно, но это еще больше увеличит нагрузку на сопровождающих.

По-моему, никуда не годится.

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

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

Они написали:

«Как мы можем лучше собирать отзывы пользователей?

Если владельцы сайтов не обладают достаточными знаниями, чтобы сообщать о проблемах на GitHub или Trac (давайте будем честными, никто не сообщает о проблемах с плагинами на Trac), на самом деле нет никакого способа собрать отзывы пользователей, чтобы улучшить эти рекомендуемые/официальные плагины.“

Канонические плагины

Разработка WordPress развивается, чтобы быстрее вносить улучшения. Комментарии основных участников указывают на то, что есть много нерешенных вопросов о том, насколько хорошо эта система будет работать для пользователей.

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

В 2021 году мета-команда WordPress создала сканер кода, который обнаруживает потенциальные угрозы безопасности, такие как неэкранированные SQL-запросы в коде плагина, с целью снижения нагрузки на команду плагинов за счет автоматизации. Этот конкретный инструмент был разработан не для поощрения передового опыта, а для обеспечения того, чтобы подключаемые модули, входящие в каталог, соответствовали минимальным стандартам, необходимым для безопасности.

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

«Он должен охватывать различные аспекты разработки плагинов, от базовых требований, таких как правильное использование функций интернационализации, до лучших практик доступности, производительности и безопасности», — сказал спонсор Google Феликс Арнц. Он определил три основные цели для плагина:

• Предоставляйте разработчикам плагинов отзывы о требованиях и передовых практиках во время разработки.
• Предоставьте группе проверки плагинов wordpress.org дополнительный автоматизированный инструмент для выявления определенных проблем или недостатков в плагине перед ручной проверкой.
• Предоставьте владельцам технических сайтов инструмент для оценки плагинов на основе этих требований и лучших практик.

Команда Performance рекомендует, чтобы плагин также работал из командной строки (используя WP-CLI) и чтобы он выходил за рамки статического анализа кода, включая проверки во время выполнения, которые выполняют код.

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

«Наличие плагина для автоматизации этих проверок звучит здорово», — сказал разработчик WordPress Майкл Нельсон, «однако я беспокоюсь, что в конечном итоге это будет означать, что разработчикам плагинов WP также придется принять стиль кода WP, что будет довольно раздражающим».

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

«Если это ПОМОГАЕТ разработчикам плагинов, то хорошо, но если это будет использоваться как оружие для настаивания на стандартах, то я подозреваю, что это будет гвоздь в гроб WP», — сказал разработчик плагинов Робин В.

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

«Теперь, если инструмент переписал код в соответствии со стандартом, так что разработчик получил «это лучшая версия», тогда я был бы на борту».

«Но тот, который просто говорит: «Вы неправильно экранируете свой код», а затем заставляет разработчика плагина попытаться найти, что и где не так, просто приведет к меньшему количеству инноваций».

Команда Performance запрашивает отзывы у сообщества, особенно у разработчиков плагинов, рецензентов плагинов и мета-команды. По словам Арнца, если они смогут достичь консенсуса, следующим шагом будет разработка инфраструктуры для средства проверки плагинов в репозитории GitHub.

«Команда производительности была бы рада возглавить этот проект, но очень важно, чтобы дополнительные участники из других команд помогали в его разработке, особенно когда речь идет об определении и реализации различных проверок», — сказал Арнц.

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

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

По словам исследователей из компании Jetpack, занимающейся безопасностью WordPress, которые обнаружили компрометацию, по состоянию на 18 января большинство плагинов AccessPress были обновлены, однако на тот момент затронутые темы не были обновлены и были извлечены из репозитория тем WordPress.org. На момент публикации неясно, были ли обновлены темы AccessPress.

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

Базирующаяся в Непале компания AccessPress предлагает 64 бесплатных и платных темы и шаблона, упрощающих работу дизайнеров WordPress, и 109 плагинов для расширения возможностей WordPress. Плагины включают контактные формы, менеджеры блогов и средства электронной коммерции.

Плагины WordPress от разных разработчиков годами были мишенью для хакеров, которые часто используют их для доступа к данным кредитных/дебетовых карт онлайн-покупателей.