Подробное сравнение WordPress и October CMS

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

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

Почему Октябрьская CMS

Я узнал о October CMS, когда она получила награду, после чего перешел в режим исследования и потратил много времени на изучение этой CMS — как с точки зрения пользователя, так и с точки зрения разработчика. Когда я получил знания об этой CMS, я был уверен, что смогу дать объективную оценку ее функций по сравнению с WordPress. Я выбрал эту CMS для сравнения с альтернативными вариантами, такими как Grav, Statamic, ButterCMS, Joomla, Drupal, Jekyll, Hugo и другими, по следующим причинам:

• Я знаю, как работает эта CMS (в отличие от Grav);
• Это бесплатно и с открытым исходным кодом (в отличие от Statamic и ButterCMS);
• В пять лет он «относительно» новый (в отличие от Joomla и Drupal);
• Это динамический (не статический) генератор контента, основанный на PHP (в отличие от Jekyll и Hugo).
  

Я считаю, что October CMS — хороший кандидат, потому что он основан на Laravel — фреймворке, используемом для создания современных приложений. После семи лет существования он получил положительное одобрение разработчиков (о чем свидетельствует его многочисленное сообщество и экосистема) и отмечает явный контраст с кодированием в WordPress, т.е. WordPress — это в основном процедурное программирование, а Laravel — явно объектно-ориентированное программирование.

В чем разница между ними?

Ниже я сравню WordPress и October CMS по разным категориям и выделю, что, на мой взгляд, в них хорошо, а что нет. Однако я не буду выбирать победителя, так как это не является целью статьи и, в любом случае, не существует «лучшей» или даже «лучшей» CMS: у каждой CMS есть свой набор сильных и слабых сторон , которые делают ее более-менее подходит для каждой задачи, проекта, компании, команды и чего угодно еще. Более того, проект может выиграть от использования более чем одной CMS, например, использования одной CMS для управления и предоставления данных, а другой CMS для рендеринга представления. Решить, какая из десятков существующих CMS больше всего подходит для ваших нужд, полностью зависит от вас.

Кроме того, в этой статье никогда нельзя было сделать окончательных выводов, поскольку она касается только подмножества всех возможностей. Например, мы также можем найти онлайн-сравнения, такие как «WordPress против Drupal против Joomla», «WordPress против генераторов статических сайтов» и даже «WordPress против Medium». Поскольку ни в одной из этих статей не представлена ​​полная картина, ни одно из этих сравнений не может быть окончательным и не должно рассматриваться как таковое.

Начнем со сравнения.

Философия и целевая группа

Не случайно WordPress работает почти на каждом третьем веб-сайте. С момента своего создания он стремился быть чрезвычайно удобным для пользователя, и ему это удалось, устраняя трения как для технических, так и для нетехнических пользователей, а также для людей любого происхождения — независимо от их образования и экономического уровня. Основатель WordPress Мэтт Малленвег сказал, что девиз WordPress «Демократизировать издательское дело» для нынешней эпохи означает следующее:

«Люди любого происхождения, интересов и способностей должны иметь доступ к программному обеспечению Free-as-in-speech, которое дает им возможность выражать себя в открытой сети и владеть своим контентом».

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

Напротив, October CMS больше ориентирована на разработчика, как было установлено с самого первого выпуска:

«Октябрь делает одно смелое, но очевидное предположение: не клиенты создают веб-сайты, это делают разработчики. Роль клиента — управлять веб-сайтом и доносить свои бизнес-требования. Веб-разработчик и сама индустрия вращаются вокруг этих факторов».

По словам ее основателей, миссия CMS — «доказать, что создание веб-сайтов — это не ракетостроение». Основанная на Laravel, October CMS может претендовать на прочную основу многократно используемого модульного кода, который может создавать приложения с правильной архитектурой, поддерживаемые в долгосрочной перспективе и полностью настраиваемые без необходимости взлома — тип, который привлекает серьезных программистов. October CMS также может обеспечить отличный пользовательский интерфейс, однако он не такой простой и удобный, как WordPress. Пользователям может потребоваться объяснить, как использовать определенные функции, прежде чем они смогут их использовать. Например, встраивание формы из какого-либо плагина имеет длинное объяснение того, как это сделать, что более громоздко, чем самоочевидная функциональность перетаскивания, предоставляемая несколькими плагинами форм в WordPress.

Установка

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

Установка October CMS также проходит очень гладко: сама установка мастера занимает даже меньше пяти минут, а если установить через консольную установку, то еще быстрее. Вы можете сделать последнее, просто перейдя в целевой каталог, а затем выполнив curl -s https://octobercms.com/api/installer | php curl -s https://octobercms.com/api/installer | php (после чего нам нужно ввести конфигурацию базы данных, иначе она ведет себя как плоская CMS). После завершения установки у нас будет полностью функционирующий веб-сайт, но все еще довольно пустой (если вы добавите время, необходимое для установки и настройки необходимых плагинов, вы можете ожидать, что это займет не менее 15 минут).

Безопасность

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

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

October CMS, с другой стороны, не имеет репутации небезопасной. Однако, поскольку существует примерно 27 000 живых сайтов, использующих October, по сравнению с миллионами WordPress, мы не можем судить о них с одной точки зрения. Тем не менее, команда October CMS серьезно относится к безопасности, о чем свидетельствует приглашение мастера установки ввести URL-адрес серверной части CMS, установленный как /backend по умолчанию, но с возможностью изменения на что-либо еще, чтобы хакерам было труднее атаковать сайт. . Напротив, изменение URL-адресов входа и бэкэнда WordPress с /wp-login.php и /wp-admin соответственно на что-то еще должно быть выполнено через плагин. Кроме того, October CMS может работать как CMS с плоскими файлами (т. е. без базы данных) и избегать уязвимостей, связанных с базой данных, таких как SQL-инъекция.

Стек технологий

И WordPress, и October CMS работают на традиционном стеке LAMP: Linux, Apache, MySQL и PHP. (Однако зафиксирован только PHP: мы также можем использовать Windows, Nginx, MariaDB и другие.) October CMS также может вести себя как CMS с плоскими файлами, что означает, что она может обходиться без базы данных, однако ценой отказа от многие функции (такие как сообщения в блогах и пользователи) единственная гарантированная функциональность — это страницы, которые считаются базовой единицей для создания и публикации контента и поставляются в качестве основной функции.

Что касается языкового стека, сайты, созданные с помощью WordPress и October CMS, основаны на HTML, CSS и JavaScript (обратите внимание, что PHP используется для создания HTML). October CMS также упрощает использование файлов LESS и SASS.

Парадигма программирования

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

С другой стороны, October CMS следует императивной парадигме программирования, основанной на расчете вычислений путем манипулирования состоянием объектов. October CMS работает поверх Laravel, веб-фреймворка, полностью основанного на принципах объектно-ориентированного программирования, которые позволяют создавать модульные приложения на основе таких концепций, как Model-View-Controller для отделения пользовательского интерфейса от данных приложения, Dependency Injection для настроить зависимости классов и принцип разделения интерфейса для определения основных служб, предоставляемых платформой, среди многих других.

Хуки/события

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

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

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

Зависимость от библиотек JavaScript

Последняя версия WordPress включает в себя Gutenberg на базе React для создания контента по умолчанию. Следовательно, разработка WordPress теперь в значительной степени зависит от JavaScript (преимущественно через React), хотя также можно использовать другие фреймворки или библиотеки (о чем свидетельствует Elementor Blocks для Gutenberg, основанный на Marionette). Кроме того, WordPress по-прежнему полагается на Backbone.js (для медиа-менеджера) и jQuery (устаревший код), однако мы можем ожидать, что зависимость от этих библиотек исчезнет, ​​поскольку Гутенберг станет новой нормой.

October CMS зависит от jQuery, который используется для реализации дополнительной инфраструктуры AJAX для загрузки данных с сервера без обновления страницы браузера.

Страницы, темы и плагины

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

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

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

Примечательно, что October CMS разрешает маршрутизацию через страницы, поэтому страницы используются не только как контейнеры для контента, но и для функциональности. Например, плагин для ведения блога зависит от страницы для отображения списка сообщений блога по выбранному URL-адресу, от другой страницы для отображения одного сообщения блога по другому выбранному URL-адресу и так далее. Если какая-либо из этих страниц исчезнет, ​​соответствующая функциональность плагина станет недоступной, и этот URL-адрес создаст ошибку 404. Следовательно, в октябре темы CMS и плагины не полностью отделены друг от друга, и переключение между темами должно выполняться осторожно.

Функциональность ядра и плагина

WordPress пытается предоставить минимальную базовую функциональность, которая расширяется с помощью плагинов. WordPress полагается на «правило ⁸⁰ ⁄ ₂₀ », чтобы решить, включать ли некоторые функции в свой основной опыт или нет. Если он приносит пользу 80% пользователей, в которые он входит, в противном случае он принадлежит стране плагинов. При добавлении плагинов на сайт они могут привести к раздуванию, если установлено слишком много плагинов. Плагины также могут плохо работать друг с другом, выполнять одинаковый код или загружать аналогичные ресурсы, что приводит к неоптимальной производительности. Следовательно, в то время как запуск сайта WordPress относительно прост, более сложной задачей является его общее обслуживание и возможность сохранения оптимального и производительного состояния при добавлении новых функций.

Точно так же October CMS также пытается предоставить минимальную базовую функциональность, но на стероидах: единственная гарантированная функциональность — это создание и публикация страниц, а для всего остального нам нужно будет установить тот или иной плагин, который выражается как:

«Все, что вам нужно, и ничего лишнего».

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

October CMS также включает в себя определенные функции, которые (хотя они и не всегда необходимы) могут значительно улучшить приложение. Например, он предоставляет готовую поддержку для загрузки медиафайлов в Amazon S3 и доступа к ним через CDN Rackspace. Он также включает в себя медиа-менеджер, который в основном используется через плагины, например, для добавления изображений в сообщение в блоге. (Страницы также могут использовать Media Manager для встраивания медиафайлов, однако CMS также поставляется с разделом Assets для загрузки медиафайлов для них, что кажется более подходящим.)

Я считаю, что самоуверенность October может позволить нам создать максимально компактное приложение — в основном для простых сайтов. Однако это также может иметь неприятные последствия и стимулировать раздувание, потому что линия того, что необходимо, а что нет, является произвольной, и CMS трудно установить заранее. Эту трудность можно оценить при рассмотрении концепции «пользователя»: в WordPress пользователи веб-сайта и администраторы веб-сайта принадлежат к одному и тому же пользовательскому объекту (и с помощью ролей и привилегий мы можем сделать пользователя администратором). В October CMS эти две функции реализованы отдельно: в ядре реализована реализация для администратора веб-сайта, который может входить в бэкэнд-область и изменять настройки, а через плагин — реализация пользователя веб-сайта. Эти два типа пользователей имеют разный процесс входа в систему и разные таблицы базы данных для хранения своих данных, что, возможно, нарушает принцип DRY (не повторяйтесь).

Эта проблема возникает не только в отношении поведения сущности, но и в отношении того, какие поля данных она должна содержать. Например, должны ли поля данных пользователя веб-сайта быть предопределены? Обязательно ли поле для телефона? Как насчет поля URL-адреса Instagram, учитывая, что Instagram только недавно стал крутым? Но тогда при создании профессионального веб-сайта не следует ли вместо этого использовать поле URL-адреса LinkedIn? Эти решения явно зависят от приложения и не могут приниматься ни CMS, ни плагином.

Плагин October CMS под названием User реализует пользователей, но без пользовательского поля, поверх которого плагин User Plus добавляет несколько произвольных пользовательских полей, которых может быть недостаточно, поэтому плагин User Plus+ добавляет еще другие пользовательские поля. Когда, где и как остановить этот процесс?

Другая проблема заключается в том, что нет места для добавления новых возможностей к сущности, что приводит к созданию другой, очень похожей сущности, только для поддержки этих необходимых возможностей. Например, October CMS поставляется со страницами и позволяет создавать «статические страницы» с помощью плагина. Их природа одинакова: и страницы, и статические страницы сохраняются как статические файлы. Единственная разница между ними (насколько я могу судить) заключается в том, что статические страницы редактируются в визуальном редакторе, а не в редакторе HTML, и могут быть добавлены в меню. На мой взгляд, только структурные различия, такие как сохранение одного объекта в виде статического файла, а другого в базе данных, могут оправдать создание второго объекта для страницы (для этого есть запрос на извлечение), но для простых особенностей, как это имеет место в настоящее время, это представляет собой раздувание разработки.

Таким образом, хорошо реализованное приложение October CMS может быть очень компактным и эффективным (например, за счет удаления базы данных, когда она не нужна), но, наоборот, оно также может стать излишне раздутым, вынуждая разработчиков реализовывать несколько решений для аналогичных объектов, которые могут быть очень запутанным в использовании («Должен ли я использовать страницу или статическую страницу?»). Поскольку ни WordPress, ни October CMS не нашли идеального решения для устранения раздувания, мы должны с осторожностью проектировать архитектуру любого приложения, чтобы избежать проблем в будущем.

Создание контента

Гутенберг вносит два важных вклада в WordPress: он использует компоненты в качестве единицы для создания сайтов (что дает несколько преимуществ по сравнению с кодированием больших двоичных объектов HTML) и вводит объект, называемый «блоком», который после завершения фазы 2 Гутенберга (предположительно в 2019) обеспечит унифицированный способ добавления контента на сайт, что упростит взаимодействие с пользователем, в отличие от более хаотичного процесса добавления контента с помощью шорткодов, кнопок TinyMCE, меню, виджетов и прочего.

Поскольку блоки Гутенберга могут создавать и сохранять статический HTML как часть сообщения в блоге, установка многих блоков Гутенберга не обязательно приводит к раздуванию веб-сайта на стороне пользователя, но может быть ограничена административным доступом. Следовательно, Gutenberg, возможно, можно считать хорошим подходом к созданию веб-сайтов модульным способом с простым, но мощным пользовательским интерфейсом для создания контента. Возможно, самым большим недостатком является (неизбежное, но не легкое) требование изучения React, кривая обучения которого довольно крутая.

Если компоненты React являются базовой единицей для создания контента в WordPress, October CMS основана на предпосылке, что для создания сайтов достаточно знания старого доброго HTML. Действительно, при создании страницы нам просто представлен редактор HTML (Markup):

Если бы на странице был исключительно статический HTML, тогда не было бы необходимости в CMS. Вместо этого страницы October CMS написаны с использованием шаблонов Twig, которые скомпилированы в простой оптимизированный PHP-код. Они могут выбрать макет для включения каркаса страницы (т. е. повторяющихся элементов, таких как верхний и нижний колонтитулы и т. д.), могут реализовать заполнители, которые определены в макете, чтобы позволить странице настраивать содержимое, и могут включать частичные фрагменты, которые являются многократно используемыми фрагментами кода. Кроме того, страницы могут включать блоки контента, которые представляют собой текстовые файлы, файлы HTML или Markdown, которые можно редактировать самостоятельно и которые могут присоединять компоненты, которые представляют собой функциональные возможности, реализованные с помощью плагинов. И, наконец, когда HTML недостаточно и нам нужно создать динамический код, мы можем добавить функции PHP.

Редактор полностью посвящен HTML. В TinyMCE нет textarea для визуального добавления контента — по крайней мере, не с помощью интерфейса по умолчанию (эта функциональность принадлежит плагинам). Следовательно, знание HTML можно считать обязательным для использования October CMS. Кроме того, несколько различных входных данных для создания контента (страницы, макеты, заполнители, партиалы, блоки контента, компоненты и функции PHP) могут быть очень эффективными, однако это, конечно, не так просто, как через унифицированный блочный интерфейс WordPress. Это может даже усложниться, поскольку могут быть добавлены и другие элементы (например, статические страницы, меню и фрагменты), а некоторые из них, такие как страницы и статические страницы, по-видимому, обеспечивают ту же функциональность, что затрудняет принятие решения о том, когда использовать тот или иной.

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

Медиа-менеджер

И WordPress, и October CMS поставляются с медиа-менеджером, который позволяет без труда добавлять медиафайлы на сайт, поддерживая одновременное добавление нескольких файлов с помощью интерфейса перетаскивания и отображая изображения в области содержимого. Они выглядят и ведут себя одинаково; единственные заметные отличия, которые я обнаружил, заключаются в том, что Media Manager WordPress позволяет встраивать галереи изображений, а Media Manager October позволяет вручную создавать структуру папок для размещения загруженных файлов.

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

Интернационализация

Ядро WordPress использует gettext для перевода тем и плагинов. Начиная с файла .pot , содержащего все строки для перевода, нам нужно создать файл .po , содержащий их перевод на соответствующий язык/локаль, а затем этот файл компилируется в двоичный файл .mo , подходящий для быстрого извлечения перевода. Инструменты для выполнения этих задач включают GlotPress (онлайн) и Poedit (загружаемое приложение). Удобно, что этот механизм также работает для локализации на стороне клиента для Gutenberg.

В настоящее время WordPress не поставляет какое-либо ядро ​​для перевода контента и не будет делать этого до фазы 4 Gutenberg (рассчитанной на 2020+ год). До тех пор эта функциональность предоставляется плагинами, которые предлагают различные стратегии хранения и управления переведенным контентом. Например, в то время как плагины, такие как Polylang и WPML, хранят каждый перевод в отдельной строке из пользовательской таблицы базы данных (что является чистым, поскольку не смешивает содержимое вместе, но медленнее, поскольку требует дополнительного INNER JOIN двух таблиц при запросе база данных), плагин qTranslate X хранит все переводы в одном и том же поле из исходной таблицы базы данных (быстрее для запроса данных, но смешанный контент может привести к поломке на сайте, если отключить плагин). Следовательно, мы можем присмотреться и выбрать наиболее подходящую стратегию для наших нужд.

October CMS предоставляет многоязычную функциональность не через ядро, а в виде плагина, созданного командой October CMS, который гарантирует безупречную интеграцию в систему. С функциональной точки зрения этот плагин выполняет то, что обещает. С точки зрения разработки, то, как на самом деле работает этот плагин, не совсем идеально. В WordPress страница — это просто запись с типом записи «страница» и для них существует единый механизм перевода, но в October CMS есть сущности «страница», «статическая страница» и «запись в блоге» и, хотя очень похожи, они требуют трех разных реализаций для своих переводов! Затем содержимое «страницы» может включать коды сообщений (например, коды, называемые nav.content , header.title и т. д.), каждый из которых содержит свои переводы для всех локалей в виде сериализованного объекта JSON в таблице базы данных rainlab_translate_messages . Содержимое «статической страницы» создается в новом статическом файле для каждой локали, однако все переведенные URL-адреса для всех локалей сохраняются не в соответствующем файле, а в файле языка по умолчанию. Контент для «сообщения в блоге» хранится в виде сериализованного объекта JSON с одной строкой для каждой локали в таблице базы данных rainlab_translate_attributes а переведенный URL-адрес хранится с одной строкой для каждой локали в таблице базы данных rainlab_translate_indexes . Я не знаю, связана ли эта сложность с тем, как был реализован плагин, или это связано с архитектурой October CMS. В любом случае, это еще один случай нежелательного раздувания на стороне разработки.

Управление плагинами

И WordPress, и October CMS предлагают сложный менеджер плагинов, который позволяет искать плагины, устанавливать новые плагины и обновлять установленные плагины до их последней версии — и все это из бэкэнда.

Управление зависимостями

October CMS использует Composer в качестве предпочтительного менеджера пакетов, позволяя плагинам загружать и устанавливать свои зависимости при установке, что обеспечивает безболезненную работу.

WordPress, с другой стороны, официально не принял Composer (или какой-либо менеджер зависимостей PHP), потому что сообщество не может согласиться, является ли WordPress сайтом или зависимостью сайта. Следовательно, если им требуется Composer для своих проектов, разработчики должны добавить его самостоятельно. С переходом на Gutenberg npm стал предпочтительным менеджером зависимостей JavaScript, от него зависит популярный инструментарий разработчика, а клиентские библиотеки постоянно выпускаются в виде автономных пакетов в реестре npm.

Взаимодействие с базой данных

WordPress предоставляет функции для извлечения данных из базы данных (например, get_posts ) и их сохранения (например, wp_insert_post и wp_update_post ). При извлечении данных мы можем передавать параметры для фильтрации, ограничения и упорядочения результатов, чтобы указать, должен ли результат передаваться как экземпляр класса или как массив свойств и другие. Когда функция не полностью удовлетворяет нашим требованиям (например, когда нам нужно выполнить INNER JOIN с пользовательской таблицей), мы можем запросить базу данных напрямую через глобальную переменную $wpdb . При создании плагина с настраиваемым типом записи код, скорее всего, будет выполнять настраиваемые SQL-запросы для извлечения и/или сохранения данных в настраиваемых таблицах. Таким образом, WordPress пытается предоставить доступ к базе данных через общие функции на первом этапе и через низкоуровневый доступ к базе данных на втором этапе.

October CMS использует другой подход: вместо того, чтобы сразу подключаться к базе данных, приложение может использовать Laravel Eloquent ORM для доступа и управления данными базы данных через экземпляры классов, называемых моделями, делая взаимодействие с базой данных также основанным на объектно-ориентированном программировании. . Это доступ высокого уровня; просто следуя правилам создания таблиц и установления отношений между сущностями, плагин может извлекать и/или сохранять данные без написания строки SQL. Например, приведенный ниже код извлекает объект из базы данных через модель Flight , изменяет свойство и снова сохраняет его:

 $flight = Flight::find(1); $flight->name = 'Darwin to Adelaide'; $flight->save();

Обновление модели данных

Другой причиной успеха WordPress (в дополнение к сохранению обратной совместимости) была его архитектура базы данных, которая была спроектирована таким образом, чтобы приложения могли расти с течением времени. Эта цель достигается за счет «мета» свойств, т.е. свойств, которые могут быть произвольно добавлены к объекту базы данных в любой момент. Эти свойства хранятся не в столбце из соответствующей таблицы объектов ( wp_posts , wp_users , wp_comments или wp_terms ), а вместо этого в виде строки в соответствующей «мета» таблице ( wp_postmeta , wp_usermeta , wp_commentmeta или wp_termmeta ) и извлекаются с помощью INNER JOIN . Следовательно, хотя извлечение этих метазначений происходит медленнее, они обеспечивают неограниченную гибкость, и модель данных приложения редко требует перестройки с нуля для реализации некоторых новых функций.

October CMS не использует мета-свойства, но вместо этого может хранить несколько произвольных значений, которые не отображаются напрямую как столбцы в таблицах базы данных, в виде сериализованного объекта JSON. Otherwise, when an object needs some new property, we need to add a new column on the corresponding table (which is the reason behind plugins User Plus and User Plus+, mentioned earlier on). To update the application's database schema, October CMS relies on Laravel's Migrations, which are sets of instructions to execute against the schema (such as add or drop a column, rename an index, etc) and which are executed when upgrading the software (eg when installing a plugin's new version).

Headless Capabilities

Both WordPress and October CMS can be used as headless, ie treating the CMS as a content management system that makes content accessible through APIs, which allows to render the website on the client-side and can power other applications (such as mobile apps). Indeed, WordPress is steadily heading towards headless, since the Gutenberg content editor itself treats WordPress as a headless CMS (and, as a consequence, Gutenberg can also work with any other CMS too, as Drupal Gutenberg demonstrates).

A headless system needs to implement some API to return the data, such as REST and GraphQL. WordPress supports REST through WP REST API (merged in core), exposing endpoints under some predefined route /wp-json/wp/v2/... ; October CMS supports REST through plugins RESTful and API Generator, which allow to create custom endpoints and, as a consequence, support versioning as part of the endpoint URL and can offer a better security against bots. Concerning GraphQL, WordPress supports it through WPGraphQL, while October CMS currently has no implementations for it.

Quite importantly, a headless system needs to offer powerful content management capabilities. As mentioned earlier on, WordPress has a very solid database architecture, offering a plethora of data entities (users, posts and custom posts, pages, categories, tags and custom taxonomies, comments) over which the application can be reasonably well modelled, meta properties to extend these data entities (enabling the application to upgrade its data model accordingly and without major changes), and with plugin Advanced Custom Fields filling the gap to construct relationships among the data entities. In addition, plugin VersionPress allows to version control the database content using Git. Hence, WordPress is undoubtedly a good fit for managing content, as demonstrated in several projects in the wild.

On its part, and as mentioned earlier on, October CMS can omit the database and behave as a flat-file system, or it can have a database and behave as a hybrid, storing the content from pages as static files and blog posts (and others) on the database. As a consequence, content is not centralized, and its management involves a different approach. For instance, while we can use Git to version control pages, there is no support to version control the database per se; the solution to this is to populate data into the database through Seeders which, being code, can be put under version control and executed upon deployment. In addition, October CMS doesn't offer a baked-in database model featuring predefined data entities that can support the needs of most applications. Hence, more likely than not the application will need custom development to implement its data model, which means more work, but also means that it can be more efficient (eg accessing a property from a column is faster than from a row in another table through an INNER JOIN , which is the case with WordPress' meta properties).

CLI Support

Both WordPress and October CMS can be interacted with from the console through a Command Line Interface (CLI): WordPress through WP-CLI and October CMS through Laravel's Artisan. In addition to Laravel's commands, October CMS implements several custom commands for updating the system, migrating the database, and others. These tools make it very convenient to access the site from outside a browser, for instance for testing purposes.

Managed Hosting

It is not a problem finding a managed hosting provider for a WordPress site: given WordPress' market share, there are dozens (if not hundreds) of providers out there vying with each other for the business, constituting a very dynamic market. The only problem is finding the most suitable provider for our specific sites based on all of their offerings, which can vary based on price, quality, type (shared or dedicated services), bandwidth and storage size, customer support, location, frequency of renewal of equipment, and other variables which we can navigate mainly through reviews comparing them (such as this one, this one or this one).

Even though nothing near as many as WordPress, October CMS still enjoys the offering from several hosting providers, which allows for some consideration and selection. Many of them are listed as October Partners, and several others are found DuckDuckGoing, but since I haven't found any independent review of them or article comparing them, the task of finding out the most suitable one will take some effort.

Marketplace, Ecosystem And Cost

WordPress' commercial ecosystem is estimated to be USD $10 billion/year, evidencing how many people and companies have managed to make a living by offering WordPress products and services, such as the creation of sites, hosting, theme and plugin development, support, security, and others. Indeed, its size is so big it is even bloated, meaning that it is very common to find different plugins solving the same problem, plugins that underdeliver, underperform or have not been updated for years, and themes which seem to look-alike each other. However, when creating a new site, the size and variety of the ecosystem also means that we will most likely find at least one plugin implementing each of the required functionalities, enabling us to save money by not having to develop the functionality ourselves, and the availability of customizable themes enables to produce a reasonably distinctive-looking site with minimal effort. As a consequence, we can easily create and launch a WordPress site for less than USD $100, making WordPress a sensible option for projects of any budget.

Being relatively new (only five years so far), OctoberCMS certainly doesn't enjoy anything near WordPress' marketplace and ecosystem sizes, however, it has been growing steadily so its size is bound to become bigger. Currently, its marketplace boasts 600+ plugins, and only a handful of themes. Concerning plugins, the October CMS team is requesting the community to put their effort into the creation of original plugins, delivering functionality not yet provided by any other plugin.

Hence, even though 600+ plugins doesn't sound like much, at least these translate into 600+ different functionalities. This way, even though it is not possible to choose among several vendors, at least we can expect to have those basic website features (such as blogging, comments, forum, integration with social media, e-commerce, and others) to be covered. Also, since October's founders are personally reviewing all submitted plugins and judging them according to quality guidelines, we can expect these plugins to perform as expected. As another plus, October plugins can incorporate elements from Laravel packages (even though not all of them are compatible with October, at least not without some hacks). Concerning themes, the low number of offerings implies we will most likely need to develop our own theme by hiring a developer for the task. In fact, I dare say that the theme in October CMS will most likely be a custom development, since themes and plugins are not thoroughly decoupled (as explained earlier), with the consequence that a market for easily-swappable themes is more difficult to arise. (This is a temporary problem though: once this pull request is resolved, pages will be able to be stored in the database, and swapping themes should not disrupt functionality.)

In my opinion, because of the smaller offerings of themes and plugins, creating a simple site with OctoberCMS will be more expensive than creating a simple WordPress site. For complex sites, however, October's better architecture (Object-Oriented Programming and Model-View-Controller paradigms) makes the software more maintainable and, as a consequence, potentially cheaper.

Сообщество

Being a part of and having access, WordPress' community represents one of the most compelling reasons for using WordPress. This is not simply as a matter of size (powering nearly one third of all websites in the world, there are so many stakeholders involved with WordPress, and its community is representatively big) but also as a matter of diversity. The WordPress community involves people from many different professions (developers, marketers, designers, bloggers, sales people, and so on), from all continents and countries, speaking countless languages, from different social, educational and economic backgrounds, with or without disabilities, from corporate, not-for-profit and governmental organizations, and others. Hence, it is quite likely that, for whatever problem we encounter, somebody will be able to help on any of the support forums. And contributing to WordPress is pretty straightforward too: The Make WordPress group congregates stakeholders interested in supporting different projects (accessibility, design, internationalization, and many others) and organizes how and how regularly they communicate — mostly through some dedicated channel on its Slack workspace.

Furthermore, the WordPress community is real and tangible: it doesn't exist just online, but it gathers offline in WordCamps and meetups all over the world; in 2018, there were a total of 145 WordCamps in 48 countries with over 45,000 tickets sold, and a total of 5,400 meetup events from 687 meetup groups. Hence, it is likely that there is a local chapter nearby which anyone can join to ask for help, learn how to use the platform, keep learning on a regular basis, and teach others as well. In this sense, WordPress is not just a CMS but, more importantly, it's also people, and considering to leave WordPress should never be done only on its technical merits but on the power of its community, too.

October CMS' community is nothing near in size or diversity as WordPress', even though it has been growing steadily following the increasing popularity of the software. October provides a support forum to ask for help, however, it is not very active. A Slack workspace exists which is pretty active and where, quite importantly, October's founders participate regularly, helping make sure that all enquiries are properly addressed. This channel is a great source for learning low-level tips and tricks about the software, however, it is geared towards developers mainly: There are no channels concerning accessibility, design, internationalization, and other topics as in the WordPress community, at least not yet. Currently, there are no conferences concerning October CMS, but there is Laracon, the conference for the Laravel community.

Maintainers And Governance

Can we trust that the software will be maintained in the long term, so that if we decide to start a project today, we will not need to migrate to some other platform down the road? How many people are taking care of developing the software? And who is deciding in what direction the software moves towards?

На WordPress работает треть всех сайтов в мире. следовательно, нам не нужно опасаться, что программное обеспечение придет в упадок. Тем не менее, WordPress проводит внутренние обсуждения своей модели управления, и многие члены сообщества заявляют, что решения относительно направления WordPress принимаются в одностороннем порядке Automattic, компанией, управляющей WordPress.com. Центральным этапом этого восприятия было решение о запуске Гутенберга, с которым не согласились многие участники и которое страдало от отсутствия надлежащей коммуникации со стороны руководителей проекта во время его разработки и выпуска. Как следствие, многие члены сообщества ставят под сомнение роль «доброжелательного диктатора», которая исторически была предоставлена ​​основателю WordPress и генеральному директору Automattic Мэтту Мулленвегу, и исследуют различные модели управления, чтобы найти более подходящую для будущего WordPress. Еще неизвестно, приведет ли этот поиск к какому-либо результату или сохранится ли статус-кво.

Решения о направлении October CMS в основном принимаются основателями Алексеем Бобковым и Сэмюэлем Жоржем, а также разработчиком и менеджером сообщества Люком Тауэрсом, которые поддерживают развитие проекта. October CMS еще не может позволить себе такую ​​роскошь, как проблемы с управлением: ее текущая забота состоит в том, как сделать проект устойчивым, генерируя доход для тех, кто занимается сопровождением основного программного обеспечения.

Документация

Документация WordPress на собственном сайте не является исчерпывающей, но она достаточно хорошо справляется со своей задачей. Однако, принимая во внимание всю документацию по WordPress из всех источников, таких как общие сайты (Smashing Magazine, CSS трюки и многие другие), специализированные сайты (WPShout, WPBeginner и многие другие), личные блоги, онлайн-курсы, и так далее, практически нет аспектов работы с WordPress, которые еще не были рассмотрены.

October CMS не так нравится множество сторонних курсов, руководств или сообщений в блогах, как WordPress, однако документация на ее сайте достаточно всеобъемлющая и, безусловно, достаточная для начала кодирования. Основатели October также регулярно добавляют новую документацию с помощью руководств. Одним из аспектов, который мне лично понравился, является дублирование документации Laravel в документацию October для всего важного, поэтому читатель не должен самостоятельно заполнять пробелы и угадывать, что является доменом October, а что Laravel. Однако это не на 100% идеально. В документации October используются термины, происходящие из Laravel, такие как промежуточное ПО, сервисные контейнеры, фасады и контракты, без адекватного объяснения, что это такое. Затем может быть полезно предварительно прочитать документацию Laravel (к счастью, документация Laravel определенно исчерпывающая, а скринкасты Laravel, Laracasts, являются еще одним отличным источником знаний, не только о Laravel, но и о веб-разработке в целом).

Заключение

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

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

Лично мне, как разработчику, очень нравится то, что я нашел в October CMS, в основном его способность создавать модульные приложения, предоставляемые через Laravel. Я бы определенно рассмотрел эту CMS для нового веб-сайта. Однако в процессе написания этой статьи я также «заново открыл» WordPress. Будучи настолько популярным, WordPress получает более чем справедливую долю критики, в основном касающуюся его старой кодовой базы и, с недавнего времени, введения Гутенберга; тем не менее, WordPress также имеет некоторые превосходные функции (например, супермасштабируемую модель базы данных), которые редко хвалят, но их тоже следует принимать во внимание. И самое главное, WordPress не следует рассматривать только с точки зрения его технических аспектов: в частности, размер его сообщества и экосистемы ставит его на уровень или два выше его альтернатив. Короче говоря, некоторые проекты могут выиграть от использования WordPress, в то время как другим лучше полагаться на October CMS или другую платформу.

В заключение я хотел бы отметить, что изучение того, как работает другая CMS, само по себе является очень полезным занятием, независимо от принятого решения относительно того, использовать эту конкретную CMS или нет. В моем случае я много лет работал только над WordPress, и знакомство с October CMS было очень освежающим, поскольку оно научило меня многим вещам (например, существованию рекомендаций по стандартам PHP), с которыми я не знакомился через WordPress. Теперь я могу решить сменить CMS или придерживаться WordPress, зная, как создавать лучший код.

Дальнейшее чтение на SmashingMag:

• Умное кэширование в эпоху Гутенберга
• Улучшение кода WordPress с помощью современного PHP
• Уроки, извлеченные при разработке плагинов WordPress
• Как использовать тепловые карты для отслеживания кликов на вашем сайте WordPress
• Будьте бдительны: функции PHP и WordPress, которые могут сделать ваш сайт небезопасным