Мэтт Малленвег, разработчик 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, которая ранее предназначалась для интеграции в ядро, а теперь станет плагином.
Избранное изображение Shutterstock/Studio Romantic