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

Программирование в WordPress можно охарактеризовать как HDD («Hook-Driven Development»), т.е. разработка под управлением хуков.
Хук — это механизм, который позволяет изменять поведение или значение по умолчанию и позволяет другому коду выполнять связанные функции. Хуки запускаются через «действия», которые позволяют добавлять дополнительную функционал, и «фильтры», которые позволяют изменять значения.

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

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

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

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

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

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

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

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

Редактирование файла изнутри и снаружи сайта October CMS.

October CMS позволяет создавать контент из внешних приложений.

WordPress пытается обеспечить минимальную базовую функциональность, которая расширяется с помощью плагинов. WordPress полагается на «правило 80/20«, чтобы решить, включать ли функционал в ядро или нет. Если он приносит пользу 80% пользователей, то он входит в систему, в противном случае — он принадлежит к plugin-land, т.е. «Устанавливать по необходимости». При добавлении плагинов на сайт они могут привести к нагромождению, если установлено слишком много плагинов. Плагины также могут плохо работать друг с другом, выполнять схожий код или загружать схожие ресурсы, что приводит к неоптимальной производительности. Таким образом, в то время, как запуск сайта WordPress относительно прост, более сложной задачей является его общее обслуживание и возможность сохранить оптимальное и работоспособное состояние при добавлении новых функций.

Каталог плагинов WordPress утверждает, что у него есть почти 55 000 плагинов.

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

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

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

Поиск «Rainlab» в каталоге плагинов October отображает Плагины, созданные командой October CMS.

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

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

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

В October CMS плагин под названием «User» создает пользователей, но без каких-либо пользовательских полей. Поверх этого плагина существует «User Plus» — плагин, который добавляет несколько произвольных полей пользователей. И если их недостаточно, существует плагин «User Plus +», который решает этот вопрос.

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

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

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

Начиная с WordPress 5.0 Gutenberg — это редактор контента по умолчанию.

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

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

Создание страницы в October CMS. (Большой предварительный просмотр)

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

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

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

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

October CMS поставляется с мощным медиа-менеджером.

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

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

Poedit позволяет переводить строки для тем и плагинов для WordPress.

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

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

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

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

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

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

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

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

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

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

Как WordPress, так и October CMS можно использовать как headless, т. е. рассматривать CMS как систему управления контентом, которая делает контент доступным через API, что позволяет рендерить веб-сайт на стороне клиента и может питать другие приложения (например, мобильные приложения). Действительно, WordPress неуклонно движется к headless, поскольку сам редактор контента Gutenberg рассматривает WordPress, как headless CMS (и, как следствие, Гутенберг также может работать с любой другой CMS, как это демонстрирует Drupal Gutenberg).

Headless системе требуется встраивать некоторое API, чтобы реализовать получение данных, таких как REST и GraphQL. WordPress поддерживает REST через WP REST API (встроенных в ядро), предоставляя конечные точки под некоторым предопределенным маршрутом / wp-json/wp / v2/...; October CMS поддерживает REST через плагины RESTful и API Generator, которые позволяют создавать пользовательские конечные точки и, как следствие, поддерживают управление версиями как часть URL-адреса конечной точки и могут предложить лучшую защиту от ботов. Что касается GraphQL, то WordPress поддерживает его через WPGraphQL, в то время как October CMS в настоящее время не имеет для него никаких реализаций.

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

Со своей стороны, как уже упоминалось ранее, October CMS может опустить базу данных и вести себя как flat файловая система, или же она может иметь базу данных и вести себя, как гибрид, храня контент со страниц в виде статических файлов и записей блога (и других) в базе данных. Как следствие, контент не является централизованным, и его управление предполагает иной подход. Например, хотя мы и можем использовать Git для управления версиями страниц, нет никакой поддержки для управления версиями базы данных как таковой. Решение этой проблемы заключается в заполнении данных в базу данных с помощью Seeder, которые, будучи кодом, могут быть помещены под контроль версий и выполнены при развертывании. Кроме того, October CMS не предлагает встроенную модель базы данных с предопределенными сущностями данных, которые могут поддерживать потребности большинства приложений. Следовательно, скорее всего, приложение будет нуждаться в пользовательской разработке для реализации своей модели данных, что означает больше работы, но также означает, что оно может быть более эффективным (например, доступ к свойству из столбца происходит быстрее, чем из строки в другой таблице через INNER JOIN, что имеет место в случае с мета-свойствами WordPress).

Как WordPress, так и October CMS может взаимодействовать с консолью через интерфейс командной строки (CLI): WordPress через WP-CLI и October CMS через Laravel'S Artisan. В дополнение к командам Laravel, October CMS реализует несколько пользовательских команд для обновления системы, миграции базы данных и других. Эти инструменты делают его очень удобным для доступа к сайту из-за пределов браузера, например, для целей тестирования.

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

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

Коммерческая экосистема WordPress оценивается в 10 миллиардов долларов США в год, что свидетельствует о том, сколько людей и компаний сумели заработать на жизнь, предлагая продукты и услуги WordPress, такие как создание сайтов, хостинг, разработка тем и плагинов, поддержка, безопасность и другие. Действительно, его размер настолько велик, что он даже перенасыщен, а это означает, что очень часто можно найти разные плагины, решающие одну и ту же проблему, плагины, которые недоделывают, недоработают или не обновлялись в течение многих лет, и темы, которые кажутся похожими друг на друга. Однако при создании нового сайта размер и разнообразие экосистемы также означает, что мы, скорее всего, найдем по крайней мере один плагин, реализующий каждую из требуемых функций, что позволит нам сэкономить деньги, не разрабатывая функциональность самостоятельно, а наличие настраиваемых тем позволяет создать достаточно отличительный сайт с минимальными усилиями. Как следствие, мы можем легко создать и запустить сайт WordPress менее чем за 100 долларов США, что делает WordPress разумным вариантом для проектов любого бюджета.

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

Следовательно, даже если 600 + плагинов звучит не так уж много, по крайней мере, они переводятся в 600+ различных функциональных возможностей. Таким образом, даже если невозможно выбрать один из нескольких поставщиков, по крайней мере, мы можем ожидать, что эти основные функции веб-сайта (такие как ведение блога, комментарии, форум, интеграция с социальными сетями, электронная коммерция и другие) будут охвачены. Кроме того, поскольку основатели October лично рассматривают все представленные плагины и оценивают их в соответствии с рекомендациями по качеству, мы можем ожидать, что эти плагины будут работать так, как ожидалось. Еще одним плюсом является то, что плагины October могут включать элементы из пакетов Laravel (хотя не все они совместимы с October, по крайней мере, не без дополнительные манипуляций). Что касается тем, то малое количество предложений подразумевает, что нам, скорее всего, придется разработать свою собственную тему, наняв для этой задачи разработчика. На самом деле, я осмелюсь сказать, что тема в October CMS, скорее всего, будет пользовательской разработкой, так как темы и плагины не полностью разделены (как объяснялось ранее), в результате чего рынок для легко заменяемых тем будет более трудным для возникновения. (Однако это временная проблема: как только этот pull request будет разрешен, страницы смогут храниться в базе данных, и обмен темами не будет нарушать функциональность.)

На мой взгляд, из-за малого количества предложений тем и плагинов, создание простого сайта с October CMS будет стоить дороже, чем создание простого сайта WordPress. Однако для сложных сайтов Лучшая архитектура October (объектно-ориентированное программирование и парадигмы Model-View-Controller) делает программное обеспечение более отказоустойчивым и, как следствие, потенциально более дешевым.

Сообщество WordPress представляет собой одну из самых убедительных причин для использования WordPress. Это не просто вопрос количества (обслуживание почти одной трети всех веб-сайтов в мире), но и вопрос разнообразия. В сообществе WordPress участвуют люди самых разных профессий (разработчики, маркетологи, дизайнеры, блогеры, продавцы и т. д.), со всех континентов и стран, говорящие на бесчисленных языках, из разных социальных, образовательных и экономических слоев, с ограниченными возможностями или без них, из корпоративных, некоммерческих и правительственных организаций и других. Следовательно, вполне вероятно, что для любой проблемы, с которой мы сталкиваемся, кто-то сможет помочь на любом из форумов поддержки. И вклад в WordPress тоже довольно прост: Make WordPress group объединяет заинтересованные стороны, заинтересованные в поддержке различных проектов (доступность, дизайн, интернационализация и многие другие), и организует, как и насколько регулярно они общаются — в основном через какой-то выделенный канал в Slack.

Кроме того, в WordPress сообщество реальное и осязаемое: оно существует не только в интернете, но и собирает в WordCamps и встречах по всему миру огромное количество людей; в 2018 году насчитывалось в общей сложности 145 WordCamps в 48 странах с более 45000 проданных билетов, а в общей сложности 5400 встречи во время мероприятий из 687 группы. Следовательно, вполне вероятно, что поблизости есть местное сообщество, к которому каждый может присоединиться, чтобы попросить помощи, узнать, как использовать платформу, продолжать учиться на регулярной основе и учить других. В этом смысле WordPress — это не просто CMS, но, что еще более важно, это также люди, и рассмотрение вопроса о том, чтобы покинуть WordPress, никогда не должно быть сделано только по его техническим достоинствам, но и по силе его сообщества.

Сообщество October CMS не имеет ничего общего с размером или разнообразием WordPress, хотя оно неуклонно растет вслед за растущей популярностью программного обеспечения. Октябрь предоставляет форум поддержки для обращения за помощью, однако он не очень активен. Slack весьма активен и там, что весьма важно, основатели October регулярно участвуют, помогая убедиться, что все проблемы должным образом решаются. Этот канал является отличным источником для изучения рекомендация для начинающих, однако он ориентирован в основном на разработчиков: нет никаких каналов, касающихся доступности, дизайна, интернационализации и других тем, как в сообществе WordPress, по крайней мере пока. В настоящее время нет никаких конференций, касающихся October CMS, но есть Laracon, конференция для сообщества Laravel.

Можем ли мы быть уверены, что программное обеспечение будет поддерживаться в долгосрочной перспективе, так что, если мы решим начать проект сегодня, нам не нужно будет переходить на какую-то другую платформу в будущем? Сколько людей заботятся о разработке программного обеспечения? И кто решает, в каком направлении движется программное обеспечение?

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

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

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

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

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

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