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

В начале 2018 года я разрабатывал веб-сайты с использованием двух разных систем управления контентом. Одним из них был Wordpress, а другим — собственная CMS, созданная с использованием PHP-фреймворка Laravel. Причина, по которой компания создала эту собственную версию, заключалась в том, что они продавали сайты людям, которые либо имели очень небольшой опыт работы с компьютерами, либо боялись администратора Wordpress; Эти люди занимаются бизнесом и не имеют желания изучать администрирование Wordpress. В целом им нужен был простой способ добавления контента на страницы и ничего больше. Администратор Wordpress может быть пугающим для некоторых людей: «Я боюсь нажимать кнопку «Сохранить», если сайт сломается», — однажды сказал мне один человек. Это была плохая новость для компании, в которой я работал, поскольку у них не было ресурсов для управления сайтами до такой степени, чтобы они могли взять на себя ответственность за добавление и изменение контента по прихоти, но это то, с чем они столкнулись. Клиенты ни с того ни с сего присылали нам по электронной почте текст и изображения с просьбой добавить контент на их сайт. Иногда это было бы невероятно просто (хотя и отнимало бы много времени). В других случаях я думал, что даже если этот человек делает простую просьбу, ему будет сложно сделать это дополнение без моего участия. Например, предположим, что человек хотел добавить аккордеон, содержащий текст и, возможно, изображения. Это не является (или не должно быть) масштабной задачей. Я могу написать код, который сделает это за 5 минут, но без использования CMS. Чтобы достичь этого без разработчика, им нужно найти подходящий, надежный/безопасный плагин; Установите плагин (возможность сделать это зависит от разрешений сервера); Добавьте короткий код¹, чтобы определить, где на странице отображается аккордеон; Настройте аккордеон так, чтобы его внешний вид соответствовал остальной части дизайна, и, наконец, заполните аккордеон содержимым. Даже выполнение всего этого не дает гарантии, что конечный результат не потребует дополнительного участия разработчика.

Разработчик или дизайнер не требуются.
Запустите свой сайт за считанные минуты. Вордпресс.

Ключевое слово в приведенной выше цитате — «начато». CMS обеспечивает фору так же, как среда программирования обеспечивает фору. Помимо этой отправной точки, осталось сделать много, не только с точки зрения содержания и разработки функций, но и безопасности. Это одна из причин, по которой так много сайтов Wordpress подвергаются атакам. В конце концов, эти системы позиционируются как простые готовые решения. Они не. Возможно, нереально утверждать, что можно автоматизировать весь процесс создания веб-сайта, но я думаю, что мы можем приблизиться к этому сценарию «мечты», чем это делают CMS в настоящее время.

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

  • Пользователи хотят отправлять текст и медиа для сайта, вот и все. Примите это и создайте CMS, которая поможет людям делать это и только это. Вместо того, чтобы пытаться создать администратора, ориентированного на то, чтобы не-разработчики могли понять, что такое веб-сайты, идите в противоположном направлении и создайте администратора, ориентированного на разработчиков, контролирующих контент, который публикуют пользователи.
  • Забудьте о дизайне, шаблонах и бесконечных конфигурациях стилей. Реальность такова, что большинство веб-сайтов, созданных с помощью существующих CMS, выглядят одинаково, несмотря на то, что предлагают огромное количество опций для настройки. Веб-сайты, которым удается выделиться из толпы графически, почти всегда имеют какой-то интересный графический компонент или интересную функциональность. Используйте дизайнеров для создания этой интересной графики и опыта. Остальные элементы на странице должны быть настраиваемыми да, но в установленных границах, которые продиктованы явной потребностью в такой автоматизации. Мое вдохновение здесь — CSS-фреймворк Bulma. Доступно множество настраиваемых параметров для различных вариантов использования, но в разумных пределах, которые соответствуют лучшим практикам ясности и удобства использования. Это не новая концепция, у Apple и Google есть рекомендации по пользовательскому интерфейсу, которым должны следовать их приложения².
  • Я бы применил ту же концепцию к компонентам. CMS предоставит обширный набор компонентов, охватывающих общие функции, которые можно найти на современных веб-сайтах: карусели, календари, панели навигации, формы и так далее. Компоненты можно переопределить, если это необходимо, но идея состоит в том, что вам не нужно переопределять их, поскольку они могут быть спроектированы и закодированы таким образом, что они изменяются или мутируют в зависимости от получаемых данных.
  • Маршруты будут работать так же, как и на существующих CMS. Единственное отличие состоит в том, что URL-адрес не должен содержать несколько идентификаторов, которые информируют серверное приложение о типе страницы и связанных данных. Нет «типов» страниц в смысле MVC (компонент продукта не имеет модели, представления и контроллера, специально разработанных для объекта продукта). Страницы состоят из компонентов, и сами компоненты, связанные со страницей, определяют тип просматриваемой страницы. Таким образом, вы выходите за рамки стандартных страниц шаблонов, которые вы часто видите при просмотре сайтов.
  • Тогда есть данные. Как я только что сказал, мы избегаем жесткой структуры, поэтому мне не нужны таблицы, относящиеся к таким объектам, как продукты и события. Я хотел абстрагировать данные, и для этого мне просто нужно было создать схему. Моя идея состояла в том, чтобы иметь блоки данных (скажем, JSON), которым присваивается уникальный идентификатор и поле типа. Тип будет отображаться на компонент, а уникальный идентификатор будет использоваться для присоединения блока к маршруту или странице. Внутри блока вы можете иметь дополнительные блоки со своим уникальным типом. Это упрощает компоненты внутри компонентов, что очень важно, поскольку вы можете иметь страницу с вложенными элементами, а не линейную прокрутку последовательных блоков, которые вы получаете на многих веб-сайтах (включая, по большей части, веб-сайт, который вы используете прямо сейчас) .
  • Вы должны иметь возможность прикрепить компонент к странице, и если нет данных для его заполнения, вместо того, чтобы вызвать ошибку, компонент просто не отображается, он все еще существует на странице, поэтому, возможно, выполняется запрос Ajax для извлекать данные и, благодаря реактивности, отображать их. Данные, связанные со страницей, будут переданы с сервера клиенту и станут доступными для каждого компонента на странице. К этому объекту также будут прикреплены глобальные данные, например данные меню, поэтому вам не нужно создавать данные для каждой страницы. Компоненты будут существовать в теневой модели DOM, и они будут просто ждать и смотреть, будут ли они вызваны.

Я старался поддерживать эти объекты на «высоком уровне». На самом деле я исследовал возможности таких фреймворков, как Vue, Laravel, Bulma, других библиотек кода, Docker, GitLab CI/CD и многих других технологий. Одна вещь, которую я чувствовал, была необходимостью — это необходимость изменить баланс и взаимосвязь между кодом на стороне сервера (скажем, PHP) и кодом на стороне клиента (Javascript). В заключительной части этой серии я представлю вам платформу, поделюсь своим репозиторием GitLab и расскажу, где я нахожусь.

¹ В Wordpress короткие коды можно использовать для вставки плагинов в посты через хук, подробнее о них можно прочитать здесь: https://codex.wordpress.org/Shortcode_API

² Стоит отметить, что моя возможная реализация позволит вносить изменения в CSS (SASS), и, следовательно, по-прежнему можно будет добавлять на сайт индивидуальные стили, которые переопределяют «базовые» стили. Другими словами, если у вас нет индивидуальных стилей, на вашем веб-сайте по умолчанию будут использоваться стили Bulma… Я не отказываюсь от возможности использования пользовательских стилей.