Быть новичком значит исследовать новые горизонты программирования, шагая в неизвестность, надеясь что где-то там будет лучше.

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

Так о чём это я. Сегодня я здесь чтобы поделится с вами своим первым опытом создания системы из Hedless CMS, API и блога. В связи с отсутствием достаточного количества подобного материала, особенно русскоязычного, я надеюсь что эта статья поможет вам создать подобную систему самостоятельно, избегая ошибок, которые я совершал.

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

Исходный код проекта вместе с пошаговым руководством по пользовательскому интерфейсу и API (рекомендую не читать, пока не закончите статью):

Vidzhel/Bluro

Преамбула

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

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

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

Общая структура

Воодушевленный возможностями, я не мог дождаться, чтобы начать работать над новым проектом. Идея состояла в том, чтобы создать Headless (распределенную) CMS, которую я назвал Bluro. Систему я решил дополнить расширенным Hello world приложение, блогом TechOverload и панелью администрирования для него.

Во-первых, я должен был понять, что должна делать система, после чего определить требуемые компоненты.

Блог может быть простым сайтом, где единственный человек имеет право публиковать и изменять контент. Но в моем варианте все немного сложнее. Любой желающий может прочитать статью. Однако, если он хочет писать, комментировать, подписываться на авторов, тогда он должен создать учетную запись.

Подсумировав вышесказанное, я выписал полный список функций:

• Регистрация, вход, изменение и удаление профиля
• Публикация, сохранение в черновиках, модификация, удаление статей
• Создание, модификация, удаление комментариев
• Возможность подписаться, отписаться от автора
• Создание, чтение, удаление уведомлений

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

• Просмотр профилей, написание сообщения, которое появится в виде уведомления, удаление профиля пользователя.
• Просмотр, удаление опубликованных статей
• Просмотр, удаление комментариев

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

Предыдущий значительный скачок в моем уровне веб-разработки был, когда я создал сайт на Python с Django. Я должен сказать, что это дало мне некоторое понимание того, как конечная система должна функционировать.

В конце концов, благодаря куче статей и видео с YouTube, я продвинулся и начал думать об общей структуре приложения.

Если вы посмотрите на диаграмму ниже, то увидите, что архитектура состоит из блоков. Самый верхний блок это сервер, который ведет вас к соответствующему фронтенду в зависимости от URL (пути, если быть более точным). Оба веб-интерфейса используют компонент бэкенда для получения или сохранения данных.

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

Связь между компонентами осуществляется с помощью API. Бэкэнд-компонент является наиболее сложным, поэтому мы начнем разработку с него.

Поскольку я хотел углубить свой опыт работы с JavaScript, я выбрал NodeJS для бэкэнда и React для фронтендов. Это было бы отличным дополнением к моему портфолио, подумал я тогда.

Разрабатываем Bluro CMS

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

Как вы, возможно, знаете, API это программная абстракция, проще говоря место, к которому может подсоединиться программа. Это может быть интерфейс с несколькими функциями, использующимися для соединения одного модуля с другим внутри одной системы, или, как в нашем случае, список URL-адресов, которые мы можем предоставить общественности, чтобы все знали как использовать нашу систему для манипуляции некоторыми данными.

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

Частый способ построения такой системы использование шаблона проектирования MVC (Model View Controller). Таким образом мы разделяем структуру на контроллеры и модели данных (у нас нет представлений).

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

Внедрение дополнительного функционала в нашу CMS требует отделения контроллеров от других компонентов.

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

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

Приведенная выше диаграмма показывает отношения между наиболее значимыми модулями. Давайте обсудим их.

Main является главным модулем, который загружает систему и другие модули.

ORM

Самый большой и одновременно сложный модуль, являющийся абстракцией между базой данных и другими компонентами ORM (Object Relational Mapper).

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

Центральная сущность модуля Модель. Модели дают нам методы для запроса данных, не вдаваясь в детали, такие как написание SQL запросов.

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

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

Опять же таки я не знал как это реализовать, однако к тому времени я работал с несколькими ORM. Поэтому я представлял, как это будет работать на самом высоком уровне абстракции и где я могу подсмотреть реализацию.

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

Итак, вернемся к делу. Я посмотрел в библиотеку Sequelize и пересмотрел API Django, чтобы имитировать его. Вот как я реализовал ORM.

Самые верхние Entities это сущности, которые используются для запроса данных из базы (обычно они имеют то же имя, что и таблицы). Класс Model использует QuerySet для фильтрации, сортировки и извлечения данных. В свою очередь, QuerySet зависит от Statement, который предоставляет удобный API для построения запросов. StatementsBuilder это абстрактный класс, используемый Statement для создания кусочков запроса. Затем у нас есть несколько реализаций, которые вводят определения типов данных и операторов после чего реализуют методы для работы с конкретным диалектом.

Это отличный пример Паттерна стратегии, хотя не лучший архитектурный подход, поскольку в итоге мы сильно зависим от баз данных.

Я думал, что второй вариант будет лучше, потому что я не видел смысла в использовании простых интерфейсов. Тем не менее я стал мудрее, поэтому рекомендую использовать первый, кроме случаев, когда вы хотите лучше изучить работу ORM.

Вот пример использования моей ORM. Не идеально, но для первой попытки сойдет.

Расширение системы

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

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

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

Однако я должен предупредить вас, в моей реализации вы можете найти много нарушений принципов SOLID, которые затрудняют изменение логики. Диаграммы, показанные выше, являются идеализированными с целью упрощения. На самом деле я перепробовал много техник, которые раньше не пробовал, поэтому извиняюсь за беспорядок. Если вы заинтересованны в построении чего-то более сложного, я предлагаю вам узнать больше о чистой архитектуре.

Пример модулей вы можете найти здесь.

Создание API

С готовой системой, разработка API для приложения становится намного проще. Я создал четыре модуля, которые охватывают функциональность, упомянутую ранее. Четыре сущности, которые они представляют, изображены ниже в схеме базы данных.

Auth

Определяет конечные точки, которые позволяют нам создавать учетные записи, входить в систему и управлять информацией профиля: обновлять, удалять, просматривать, подписываться...

Каждый вызов API может быть инициирован разными пользователями, поэтому нам нужен способ идентифицировать их. Итак, мы хотим отправить пользователю некоторые дополнительные данные, которые он будет использовать для авторизации.

Когда пользователь успешно входит в систему, генерируется JWT (JSON Web Token) после чего он отправляется в виде cookie. Токен является закодированным объектом со всем необходимым для идентификации данными. Последующие запросы будут использовать его для авторизации пользователя.

Кроме того, модуль предоставляет два правила:

• authRule правило, применяемое для каждой конечной точки и проверяющее cookie на наличие токена. Если токен действителен, правило сохраняет пользовательские данные в объекте, доступном другим контроллерам.
• requireAuthorizationRule правило, которое вы можете применить к конечной точке для защиты от доступа неавторизованных пользователей.

Article

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

Comment

Дает возможность управлять комментариями.

Notifications

Модуль отвечающий за управление уведомлениями. Он использует
NotificationService для дублирования уведомления на электронную почту.

Вот пример стандартного запроса и ответа от API:

fetchData это сага, которая использует Fetch API для выполнения запроса. Если запрос занимает больше времени, чем TIMEOUT, мы отменяем его. makeRequest использует предыдущую сагу для запроса некоторых данных, а затем обрабатывает их. Остальные саги используют эти утилиты для получения необходимых данных или выполнения каких-либо действий. Например, здесь вы можете увидеть, как я выполняю открытие статьи:

Используя Docker Compose, я создал контейнеры из которых собрал сервисы. Здесь вы можете найти конфиги со скриптами, которые облегчают развертывание (у меня есть единственная версия сервиса для разработки).

---

Если вы хотите создать что-то более захватывающее, советую посмотреть headlesscms.org, где находится список Headless CMS с открытым исходным кодом, которые вы можете использовать в качестве примера.

Спасибо, что уделили мне время, надеюсь мне удалось раскрыть тему в достаточной степени, чтобы помочь кому-то.

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

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

В этом обзоре я хочу поговорить об актуальной на сегодня версии DRUPAL 9. О возможностях системы, ее плюсах и ограничениях. И этот текст адресован, в первую очередь, будущим пользователям и владельцам сайтов. Потому здесь не будет сложных технических нюансов, их специалисты и без того уже не один раз обсудили в профессиональных сообществах.

Я постараюсь максимально простым языком объяснить потенциальным владельцам Drupal-сайтов, что можно ожидать от этой CMS, что требовать от веб-разработчиков в процессе создания сайта, и что можно реально получить для последующей самостоятельной работы с проектом.

Небольшое разъяснение:

1. Я намеренно не сравниваю версии Drupal, так как на данный момент это уже не важно и вот почему:

   
   

   Для Drupal 7 разработка новых модулей практически не ведется. Для уже выпущенных модулей в приоритете DRUPAL 9. Думаю это связано не только с тем что Drupal 9 новее, но и потому что официальная поддержка Drupal 7 и Drupal 8 закончиться в ноябре 2022 года.

   
   

   

   
   

2. Все скриншоты я делаю на работающем личном сайте (ссылку сможете найти в моем профиле).

   
   

3. На некоторых скриншотах вы увидите вот такое предупреждение. Все в порядке, я специально оставил эти предупреждения, для тех кто будет переходить с 8 ки, что если даже ваша тема и/или модуль не обновлены, то сайт все равно будет работать. Это же я считаю заботой разработчиков CMS об пользователях. То есть если обновление выходит, то обычно проблем c ним не бывает.

   
   

   

   
   

4. В каждом скриншоте, за редким исключением, вы сможете найти адрес страницы сайта, и при желании подставив свой домен вместо моего, вы сможете перейти к странице настроек как в статье.

   
   

Из чего состоит CMS

CMS (Content Management System) переводится как это компьютерная информационная система для управления контентом, т.е. содержимым сайта.Нередко можно встретить упрощенное название движок сайта, что по сути упрощение. Появились такие системы как ответ на решение одновременно двух проблем:

1. Снижение трудоемкости работы программистов. CMS формирует страницы на лету на основе шаблонов и непосредственно контента (текста, картинок, видео и других материалов, хранящихся в базах данных).
2. Предоставление возможности пользователям заниматься наполнением сайта. При помощи CMS даже человек, далекий от программирования, может добавлять или удалять страницы, изменять их содержимое и т.д.

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

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

Появление CMS-систем решило все эти проблемы, теперь все выглядит так:

1. Есть шаблоны с дизайном сайта или его отдельных разделов.
2. Есть сама система управления с удобным для пользователей разделом администратора.
3. Есть базы данных и папки для хранения графики, документации, видео.

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

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

Управление данными в DRUPAL 9

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

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

В Drupal эти возможности имеются по умолчанию. Т.е. вы можете самостоятельно при желании добавить страницу или целый информационный блог с определенным вариантом отображения информации даже в том случае, если такая потребность появилась в процессе работы сайта.

Для работы с данными вам понадобятся 3 основные сущности:

• Ноды;
• Таксономия;
• Представление.

О каждой из них поговорим подробнее.

Ноды (Типы материалов)

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

В разделе Типы материалов доступны:

1. Все уже существующие типы. При желании в них можно добавлять или убирать поля, редактировать описание или удалить. Но не забывайте, что в случае некорректной работы с полями или удалением типа вы можете потерять связанные с ним материалы. Т.е. сам контент в базе данных останется, но он либо вообще исчезнет с сайта, либо будет отображаться некорректно.

   
   

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

   
   

3. Добавляете контент на сайт.

   
   

С учетом многочисленных подсказок и русскоязычного интерфейса опытные пользователи интуитивно разберутся, как работать с настройкой нод. В случае возникновения проблем, на сайте Drupal есть подробная документация, инструкции, а также сообщество, где можно задать вопрос.

В рамках обзора у нас задача познакомиться с возможностями системы. Потому давайте разберемся, как можно использовать типы данных на практике.

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

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

Примеры типов материалов: статья, базовая страница, запись блога, отзыв и т.д.

Таксономия (Taxonomy)

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

Основные сущности:

• Словарь используется для объединения терминов ( например словарь категории или тэги)
• Термины основные сущности (метки, разделы) для объединения материалов по какому-то признаку. При этом термины могут иметь неограниченное количество вложений.

Например, вы хотите создать магазин по продаже овощей и фруктов. Основные словари Овощи, Фрукты, Ягоды. В словаре Фрукты могут быть Яблоки, Апельсины, Бананы и т.д. Но, если вам нужна дальнейшая детализация без проблем. В термине Яблоки создаете, например, подпункты с названиями сортов. При этом вы можете одновременно использовать словарь сортировки, скажем, по цвету. И тогда ваши яблоки будут отображаться и при выборе покупателям раздела с яблоками, и при поиске по красным или зеленым фруктам.

Еще один классический пример это категории блога. Создаем словарь "Категория услуг", в словаре создаем термины, например CRM, ERP методология и т.

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

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

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

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

Представление (Views)

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

Вы создаете представление, в котором указываете стиль страница или блог, какие типы контента на ней будут отображаться, какие информационные поля должны быть видны, в каком формате. Т.е. по сути, создаете отдельный шаблон для этого типа страниц.

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

Вот так выглядит представление страницы отзывов в административном разделе:

А вот результат на странице сайта отзывы отделены друг от друга, выбран стиль отображения, все поля выглядят одинаково:

Работа с этим разделом может оказаться сложной для пользователей, но даже начинающий верстальщик быстро подберет нужный вам стиль и настроит все типы страниц сайта.

По сути модуль Views это конструктор страницы сайта для заполнения его записями. Вы можете его темизировать как сами внутри конструктора, так и используя шаблоны темы.

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

Пользователи (People) с точки зрения системы Drupal это все посетители вашего сайта, начиная от случайных читателей и заканчивая редакторами и администраторами.

Работать с этим разделом просто:

В меню Роли (Roles) вы создаете все необходимые виды пользователей. Количество ролей может быть столько, сколько вам нужно. Обычно это:

1. анонимный, т.е. посетитель без регистрации,
2. зарегистрированный, т.е. пользователь с авторизацией, но без доступа к административному разделу;
3. автор или контент-менеджер человек, который может добавлять материалы в выбранные вами разделы;
4. администратор полные права доступа и т.д.
5. В меню Права доступа для каждой роли вы прописываете доступ, просто выставляя флаг галочка в выбранном поле. При добавлении каждой ноты или таксономии они автоматически попадают в этот список. И добавить право просматривать или как-то работать с ними вы можете при помощи редактирования прав доступа.

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

Работать с этим разделом просто, он понятен интуитивно и редко вызывает вопросов.

Шаблонизация в Drupal 9

В Drupal 9 заметно упростили разработку шаблонов для отображения различных типов страниц. Теперь для этого нет необходимости знать язык программирования PHP. Шаблоны можно формировать в простом HTML-коде, в том числе, при помощи конструктора. Далее они дополняются некоторыми командами специального языка Twig 2.x.

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

Для примера вот код верстки на сайте из шаблона отвечающие за вывод отзывов.

Расширения

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

Система Drupal 9 поддерживает огромное количество модулей. Значительная часть из них уже установлена в коробке. Остается только решить, что с ними сделать включить и применять, отложить до лучших времен или удалить. Другие вы можете найти на сайтах, посвященных CMS Drupal, скачать и установить.

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

Из числа расширений хотелось бы выделить:

• Набор модулей Commerce для организации интернет-магазина. Благодаря гибкой настройке и широкому перечную функций позволяют организовать практически любой тип электронной торговли.
• Pathauto. Автоматически создает по шаблону осмысленные адреса страниц, соответствующие материалу.
• Redirect 404. Регистрирует ошибки 404, позволяет анализировать статистику переходов на несуществующие страницы, создает редирект в случае попытки перехода на отсутствующую страницу.
• Webform набор модулей для создания различных типов форм, в том числе, комментарии, обратная связь, работа с тикетами и т.д.

При желании вы можете найти для CMS Drupal самые разные модули от организации обратной связи, различных вариантов комментирования и отзывов до интернет-магазинов и других элементов электронной коммерции. И, еще раз повторюсь, все они бесплатны, а основные модули регулярно обновляются.

Локализация

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

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

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

Интеграция

Система Drupal легко интегрируется с различными информационными системами. Мы интегрировали Drupal-сайты с Zoho CRM и другими продуктами линейки, с учетными системами, в том числе, 1С, с различными платежными системами, онлайн-чатами поддержки и т.д.

В релизе 9.0.0 организация обмена данными стала еще проще. Теперь есть инструмент, позволяющий получить из Drupal по API данные с сайта. Теперь для этого не нужно даже подключаться, например, к базам данных или писать свой модуль для обмена. Теперь по API из коробки.

Программист просто подключается к сайту и получает нужные данные, даже не зная Drupal. Он будет работать, например, над мобильным приложением или какой-либо системой обработки информации. И ему для получения информации с сайта понадобятся знание JSON, методов и запросов, которые широко используются при организации API.

Поисковая оптимизация

С точки зрения SEO-продвижения, сайты Drupal можно смело называть одними из самых настраиваемых. Больше возможностей дает разве что прямая работа с php-кодом. Расширений для SEO существует огромное количество. Расскажу про некоторые из них.

О модуле Pathauto, который создает осмысленные адреса страниц, я уже рассказывал выше. В случае необходимости вы также можете вручную менять синонимы URL для любых страниц.

Вторая строка выдачи.

Существуют в Drupal также встроенные поля для различных сео-тегов, не забывайте подключать их при настройке нодов, а после заполнять. Есть расширения для генерации карты сайта. В разделе расширений вы их найдете в разделе XML КАРТА САЙТА. А если не понравятся имеющиеся в коробке, всегда можно найти и установить альтернативные.

Скорость работы

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

Также в Drupal 9 появилась возможность хранить для определенного разрешения устройства определенный размер картинки. То есть загружаете вы картинку размера 1200*1600, и можно указать что разрешения экрана в 800 пикселей максимальная ширина картинки будет 800 и CMS сама сделаем соответствующую копию картинки. За это отвечает модуль Responsive Image.

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

Для примера прикладываю замер с сервиса PageSpeed Insights

E- Commerce

Интернет-магазины на базе Drupal решение популярное. За организацию электронной коммерции отвечает соответствующий модуль Commerce. В базовой версии он выглядит так:

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

Вы можете:

• Создать каталог товаров с разделением по категориям;
• Организовать поиск по товарам;
• Создать карточку товара с нужными полями;
• Добавить товар в корзину;
• Подключить различные платежные системы;
• Настроить обмен данными с учетными, CRM и другими программными системами и т.д.

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

Безопасность данных

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

При грамотных настройках вы можете быть уверены в достаточном уровне защиты своих данных. Тем более, что введение темизации, т.е. отделение шаблонов от самих данных в Drupal 9, значительно повышает степень защищенности сайта. Впрочем, забывать о правилах безопасности работы в сети Интернет нельзя ни в коем случае, независимо от выбранного движка сайта.

Почему я перешел на Drupal 9

Я много лет проработал с CMS Drupal 7, но в последние годы после внимательного изучения полностью перешел на Drupal 8, а затем как только вышла 9 версия, сразу на нее.

В чем преимущества системы:

• Для работы с шаблонами не требуется знания PHP. Работать с ними теперь проще и быстрее, даже для опытного программиста.
• Интеграция стала проще. О преимуществах модуля интеграции, который появился в Drupal 9, я подробно писал выше.
• Большое количество модулей в Drupal 9 уже есть в коробке. В прошлой версии многие расширения приходилось искать и устанавливать вручную.
• Открытость и бесплатность

Кроме того, многие возможности Drupal 7, в том числе, написанные под эту версию движка расширения, уже перестали обновляться. А новые решения уже ориентированы на Drupal 9.

Для каких сайтов подходит Drupal

Если вы создаете небольшой сайт-визитку и вам предлагают воспользоваться Drupal 9, стоит хорошо подумать и, скорей всего, отказаться. Здесь скорее будет актуален Wordpress или подобные решения. Также не имеет смысла выбирать Drupal для блога или простого статейного проекта. Выбирайте CMS, которые уже позиционируют себя как решения, подходящие под ваш тип сайта.

Дело в том, что Drupal 9 система мощная, но по-своему сложная. И число необходимых для начала работы настроек велико для организации небольшого сайта. Затраты времени на настройку и добавление информации, скорей всего, не окупятся. Впрочем, если к этой визитке в недалеком будущем будут подключаться и другие модули, выбор Drupal может оказаться, наоборот, верным решением.

Для создания корпоративного сайта или полноценного интернет-магазина CMS Drupal 9 подойдет наилучшим образом. Для подобных проектов важно:

1. Скорость загрузки и сео-оптимизация;
2. Возможность автоматизации и настройки обмена данными с другими системами;
3. Распределение ролей пользователей для разных сотрудников;
4. Настройка шаблонов для разных разделов и т.д.

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