Если бы я сменил издательскую систему, ProcessWire не был бы моим первым выбором

CMS Critic , популярный веб-сайт, посвященный рынку систем управления контентом, перешел с WordPress на ProcessWire . ProcessWire — это бесплатная система управления контентом с открытым исходным кодом на основе PHP, созданная четыре года назад и поддерживаемая Райаном Крамером. CMS Critic называет следующие причины отказа от WordPress:

• Раздувание
• Низкая производительность в их учетной записи веб-хостинга
• Слишком много обновлений плагинов/тем
• Слишком много плагинов в целом без процесса проверки
• Сложно использовать плагины кэширования

Их главная причина ухода из WordPress — раздувание, но их объяснение раздувания отличается от большинства, которые я читал.

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

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

Согласно CMS Critic, Крамер просматривает большинство модулей до того, как они попадут в официальный каталог. Он дает разработчикам список улучшений и советов, которые помогают ограничить вероятность конфликтов модулей друг с другом. Процесс проверки помог свести проблемы, связанные с модулями, к минимуму, но я не понимаю, как его можно масштабировать. Если CMS когда-либо достигнет точки получения 20-50 модулей в день, Крамеру придется искать помощь, иначе он рискует потерять драгоценное время разработки.

Усталость от обновлений плагинов WordPress реальна

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

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

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

Философия разработки « итерировать и выпускать часто » хорошо работает для таких сервисов, как WordPress.com, но не так хорошо для WordPress, тем и плагинов. Коэн Джейкобс написал отличный пост , объясняющий, почему не все плагины WordPress должны быстро обновляться и часто выпускаться.

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

Усталость от обновлений реальна, и ее следует по возможности избегать. Проблема усугубляется по мере увеличения количества установленных плагинов. Я бы хотел, чтобы больше разработчиков плагинов придумали лучшую стратегию выпуска вместо того, чтобы отправлять обновление, как только они исправили ошибку. Начиная с WordPress 3.7, пользователи могут автоматически обновлять ядро, плагины и темы . Однако включение автоматических обновлений из-за того, что плагин слишком часто обновляется, — плохая причина для использования этой функции. Стоит отметить, что автоматическое обновление невозможно для определенных сайтов, таких как электронная коммерция или те, которые используют контроль версий для проверки обновлений до их публикации.

Мой опыт использования ProcessWire

Чтобы увидеть, из-за чего вся эта суета, я установил ProcessWire на свой локальный сервер. Установка проста и не требует редактирования файла конфигурации. Вот как выглядят сайты после новой установки.

Серверная часть ProcessWire проста, но исходить из WordPress — это как будто оказаться на новой планете. Все, с чем я знаком в плане создания контента, отсутствует. Я могу создавать страницы, но зная, что страницы больше предназначены для статического контента, я не уверен, что это оптимальный метод создания контента. Там нет приветственного экрана, никаких признаков помощи, если она мне понадобится, и быстро становится очевидным, что это создано разработчиками для разработчиков.

Попользовавшись CMS в течение 30 минут, я сразу же бросил попытки сделать с ней что-нибудь классное. У ProcessWire есть каталог модулей для добавления функциональности платформе, но он недоступен из CMS без диспетчера модулей .

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

ProcessWire основан на предположении, что все является вызовом API . «В основе ProcessWire 2 лежит полностью управляемая API-интерфейсом структура управления контентом, которая полностью функциональна без какого-либо административного интерфейса». WordPress неуклонно движется в том же направлении, особенно после того, как JSON REST API появится в ядре .

ProcessWire не был бы моим первым выбором

Я рад видеть, что еще один проект под лицензией GPL набирает обороты и находит свое собственное место. Сообщество активно, и главный разработчик имеет более 8000 сообщений на форуме. У них также есть витрина , заполненная веб-сайтами, использующими программное обеспечение. Если вы хотите сами проверить ProcessWire, у них есть демоверсия, которая показывает уже созданный общедоступный веб-сайт. Вы также можете войти в бэкенд, чтобы увидеть, как он выглядит и работает.

Если бы я собирался перейти с WordPress на другую систему публикации, ProcessWire не был бы моим первым выбором. Есть несколько причин, почему. Во-первых, я не являюсь пользователем их целевого рынка. Во-вторых, большей части того, что я хочу от издательской системы, в ней нет из коробки. Если да, то не очевидно. И последнее, но не менее важное: из-за того, как работает ProcessWire, у него нет возможности устанавливать новые темы для внешнего интерфейса сайта. Отлично для разработчиков, ужасно для пользователей.

Несколько причин, по которым CMS Critic перешла с WordPress, я считаю преимуществом, а не ущербом для проекта. Здорово, что они нашли проект, который больше соответствует тому, что им нужно, но с характером развивающегося программного обеспечения, сколько времени потребуется, прежде чем итерации и улучшения заставят их искать еще одну CMS для перехода? В большинстве программных проектов число конечных пользователей значительно превышает число разработчиков. У меня сложилось впечатление, что большинство пользователей ProcessWire — разработчики. Если проект не решит обслуживать конечных пользователей, я не думаю, что он когда-либо станет чем-то большим, чем дополнением к ящику для игрушек разработчика.

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