Drupal в рунете

ВНИМАНИЕ, данная статья подразумевает, что вы уже умеете пользоваться git, composer и drush

Хостинг компании ra-don.ru один из самых дружелюбных для Drupal 8 сайтов. Тут из коробки сразу есть:

• git
• composer
• Глобальный drush, который работает как загрузчик для локального drush (не надо прописывать никакие алиасы)
• PHP 7.2+
• Нет дурацких ограничений php-функций

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

1. Зайти на сервер по SSH
2. Создать в домашнем каталоге пользователя каталог куда будем разворачивать сайт, например site
3. С помощью git, composer и drush развернуть копию сайта
4. Удалить каталог /home/USERNAME/public_html
5. Создать символическую ссылку /home/USERNAME/site/web в /home/USERNAME/public_html
6. PROFIT

Добавляем разнообразные компоненты Bootstrap на своем сайте на Drupal 8.

Содержание: инструменты разработчика в Chrome, мобильная версия сайта, гамбургер-меню, навигация для мобильного сайта, компоненты бутстрапа, модальное окно (Modals), отправка формы в модальном окне, вкладки (Togglable tabs), подсказки (Tooltips), сворачивающийся текст (Collaps), аккордеон (Accodion), слайдер с фотографиями (Carousel).

Хотите научиться делать сайты? Онлайн-курс Drupal School — то, что нужно!

Выполняйте задания по созданию сайта на Drupal и вскоре научитесь делать сайты самостоятельно. В каждом уроке вас ждет подробное описание и полезные ресурсы. Задания проверяются автоматически, а если остались вопросы — пишите в обсуждение: https://vk.com/topic-42625288_40095744

Не терпится начать? Поехали: http://drulabs.com/

Подписывайтесь на рассылку «Задания Drupal School», тогда вы точно не пропустите очередной урок: https://vk.com/app5728966_-42625288#114377

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

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

В данном кейсе рассматривается одновременное кросс-управление несколькими хостинг-проектами. Drupal выступил в роли централизованной системы для организации хостинг-сервисов.

Стоимость решения: > $95 000 (не считая расходов на инфраструктуру).
Класс решения: enterprise.

смотреть тут (англ. версия)

Один из наших хостинг-проектов: https://btrxboost.com

Довольствоваться тем, что тебе дают по чайной ложке (я имею в виду возможности заложенные разработчиками в системы и сервисы) - значит быть как все, отказаться от развития, потенциала, преимуществ. Я часто сравниваю зависимость от чужих стратегий с тюремным заключением без даты освобождения. Может быть, повезет. Или не повезет, и через много лет вы констатируете, что жизнь прошла, ваши идеи уже кто-то реализовал. А вы все так же в заложниках чужих мерок “так правильно”.

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

Привожу в пример близкие по смыслу платформы для автоматизации хостинга: WHMCS, Plesk, BillManager. Все эти платформы мы использовали на своих проектах, сравнивали и сейчас я могу сказать, что их всех объединяет один большой недостаток – отсутствие универсальности и функциональной гибкости. Все будет работать только так, как было задумано (N-лет назад). При условии, что наша компания работает на одном из самых динамичных it-сегментов, то в первую очередь мы думаем о перспективах развития. Я имею в виду, что бизнес-модель работающая в рамках функционала сторонних компаний – это тупик. То, что могут все, становится неинтересно и бесперспективно.

Пример: в вышеперечисленных платформах нет и не будет поддержки омниканальной коммуникации, а о интеграции с telegram вообще можно не мечтать. Никогда не будет “бесшовной” среды (я имею в виду, что сайт и биллинг всегда будут разными и слабо связанными). Никогда не будет гибкости. Это сплошной логический dead-end. И для бизнеса это критичные аспекты, они определяют качество работы поддержки. Точнее, они определяют ее некачественность, увы. Мы же ставим своей целью гибкость, бесшовность, архитектурную целостность систем, и именно в этом видим перспективу – свою и клиентскую.

Разрозненность – большое зло для любого бизнеса.

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

Мы все сталкиваемся с ситуациями, когда разработчик решения “улучшает” функционал на своей стороне, а на нашей стороне вовсе перестает работать что-то важное. Начинается выяснение причин, трата времени, бизнес-процессы стоят. А если в веб-проекте используется много внешних сервисов? Проще закрыть глаза на нестыковки и оставить все “как есть”, чтобы не рисковать с переносом процессов. И эта кажущаяся простота – стратегия страуса, прячущего голову в песок. Невидимые проблемы, скрытые в разрозненности процессов, неизбежно накапливаются и вскроются с очень большим грохотом. Компания не в силах предсказать процесс, который раньше ею не наблюдался. И таких процессов в разрозненных системах – масса. Критичные и мелкие, они копятся и угрожают стабильности. Вам это нравится? Нам решительно нет, и поэтому мы объединяем все в единую среду, прозрачную и наблюдаемую, в предсказуемое стабильное решение.

В нашей истории бизнеса было много непростых моментов. Один запомнился больше других.

Наш личный ад с WHMCS (а именно с представительством из Украины) длился две недели, мы не получили за этот период ни копейки прибыли и, к тому же, достали немало средств из собственных кошельков, чтоб не потерять свой бизнес и сохранить бизнес наших клиентов. Вы легко можете представить звонки и письма от 100 негодующих клиентов, у которых в один час перестало работать ВСЕ. У нас же на тот момент их было 5000, и мы разрывались между попытками их успокоить и нечеловеческими усилиями, направленными на то, чтобы сподвигнуть разработчика устранить причину сбоя. Лучшее, что мы смогли придумать для быстрого снижения волны недовольств от клиентов – это работать бесплатно. Это стоило нам большого кассового разрыва, вложения личных средств, и, конечно, очень много нервов.
И если клиенты сохраняли остатки лояльности к нам за бесплатность “сервиса”, то штат сотрудников оставить без зарплаты было нельзя. Это были очень тяжелые две недели, с задачами на границе возможного, со звонками от клиентов, с безденежьем. Мы катились в пропасть и каждое утро начинали с мольбы в адрес WHMCS.

В чем же было дело? WHMCS не делали резервных копий своего собственного сервера лицензий, и даже не торопились это исправлять. Сервер лицензий чудным образом рухнул вместе с данными. Все потеряли доступ к своим оплаченным сервисам, не могли приобретать и продлевать хостинг, работать с данными. “Услуга” длилась две недели, которые понадобились вендорам решения для ручного ввода (по всей видимости) потерянных данных на новый сервер лицензий.
Наверное, вы думаете, что в итоге они потеряли много клиентов, в том числе и нас? Грустная правда в том, что мы и все клиенты остались, просто потому, что альтернатив на тот момент не было.

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

Я много чего могу рассказать и про другие решения от ISP и Plesk, да и про коммерческие CMS для сайтов. Это истории обретения драгоценного опыта. И наш опыт подтверждал снова и снова идею о том, что разрозненность процессов в бизнесе – это большое зло. Очень большое.

Список длинный, поэтому я выделяю для вас основные проблемы:

1. Технические поддержки сервисов не сообщаются между собой. Клиент разбирается самостоятельно. Надо делать бизнес, обслуживать клиентов, а владелец сидит в обнимку с айтишниками и ковыряется в особенностях работы сервисов. Аналогичное сравнение можно провести с предпринимателем, который первый раз открыл ООО и только успевает закрывать бухгалтерские задачи и отбиваться от проверок и штрафов. Есть риск разориться раньше, чем закончится аудит.
2. Отсутствие полностью готовых и гибких интеграций, нет возможности добавлять собственный функционал. Иногда я думаю, что они там сидели и думали так: “А зачем хостеру оказывать еще какие-то услуги кроме хостинга, если он хостер? Пусть делает только то, что мы решили, и хватит с него.”
3. Отсутствие личных настроек. Нам предлагают множество решений, которые невозможно полноценно брендировать. Чем я со своим сайтом и биллингом будут отличаться от конкурента? У него Billmanager с ошибками и у меня такой же с виду. Я хочу продавать лучшую клубнику в рестораны, но вынужден упаковывать ее в банки, такие же как у замороженного продукта пятилетней давности. Где же мне проявить свои преимущества и реализовать потенциал?
4. Разные интерфейсы и принципы работы. Пришел новый сотрудник, а у нас 4 сервиса с разными интерфейсами и дублированными функциями. Нужно садиться с новичком и объяснять все нюансы. И если назавтра что-то поменяется, то мы садимся снова за обучение, теряя время и, самое печальное, уверенность в достаточной подготовленности кадров.
5. Лишние и дублирующие функции сервисов. Не страшно, что за них нужно переплачивать, страшно то, что они могут конфликтовать друг с другом. Мы с этим сталкивались неоднократно и отловить конфликтующие сервисы сложнее, чем баги внутри одной системы. В этих случаях нужно тестировать всю цепочку сервисов, постепенно отключая каждый элемент (сервис) и проводить тесты. Решение может занять 5 минут, а на то, чтобы отловить проблему может понадобиться несколько дней. При том, в идеале тесты должны проводиться на полностью дублированной инфраструктуре, а не на боевом проекте. Как думаете, со всеми ли сервисами можно договориться, чтобы бесплатно дали свой продукт еще и на dev? Подскажу: далеко не со всеми.

1. Долгосрочный горизонт развития.
2. Гибкость, а точнее ультра-гибкость.
3. Свобода от навязанных решений.
4. Фундаментальность принципов и логики (еще раз повторюсь, что Drupal - это не CMS, а логический принцип.)
5. Сообщество профессионалов. Самое большое из известных мне среди профессионалов open-source web-решений.

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

Мы свои выводы сделали, дело за вами.

Снижение внутренних рисков

• Контроль качества программного продукта. Исключение миграции на другую платформу в случае изменений в команде разработчиков или ее полной замены.
• Минимизировать зависимость системы и бизнес-процессов от дочерних сервисов (минимум подключенных сторонних сервисов).
• Единая система управляющая всеми бизнес-процессами.

Масштабируемость

• Кросс-платформенные стандарты для back-end/front-end для упрощенного обновления всей группы сайтов по специализированным хостингам для CMS.
• “Бесшовный” интерфейс для клиентов (единый дизайн для сайта/биллинга/личного кабинета).
• Гибкий универсальный биллинг.
• Единый центр обслуживания клиентов по принципу омниканальности.

Бизнес-процессы

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

Мы имеем возможность воссоздавать аналогичные и дочерние проекты в десятки раз дешевле и быстрее.

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

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

Drupal дал нам свободу развития. И при всей его свободе мы избавлены от бесконечного допиливания и переделок решений, от причудливой архитектурную энтропии, от привязки к конкретным разработчикам. Мы контролируем систему сами.

Продукты:

• Гибкая система тарификации хостинг-тарифов.
• Продажа услуг (администрирование, обслуживание).
• Продажа продуктов типа SSL-сертификатов, выделенных серверов, лицензий CMS.
• Установка наценок на продукты и их свойства (опции, атрибуты).
• Возможность указания цены товаров (включая опции и атрибуты) в иностранных валютах с автоматической конвертацией в рубли по текущему курсу ЦБ.
• Установка платежных циклов на основе атрибутов с возможностью добавления скидок за единовременную оплату больших циклов (например, скидка 10% при оплате за 12 месяцев хостинга). Смена платежного цикла из личного кабинета клиента.
• Включение режима демо-периода (триал) для услуги.
• SMS-верификация при оформлении триал-услуг.
• Выбор автоматической установки CMS при заказе продукта.
• Выполнение бизнес-процессов (например: создание тикета с отправкой уведомления в отдел) при заказе продукта.
• Разбивка продуктов в заказе на отдельные заказы.
• Трансляция данных о продукте в личный кабинет клиента.
• Внутренний интернет-магазин с возможностью покупки товаров за накопленные бонусные баллы.
• Полное управление продуктами из таблицы: тип продукта, название, категории, описание, атрибуты и опции, фото, наличие (остатки), наценки, валюты, метки, цены, бонусные баллы, промо-коды, ограничения по количеству единиц и времени, выбор родительской группы (промо-страницы с продуктами), рекомендации, аксессуары, запуск процессов, верификация при покупке, тип заказа (триал, без оформления, обычный), автопродление, изменение платежного цикла, выгрузки во внешние сервисы и др.
• Замена продукта и опций (при смене тарифного плана).
• Передача данных из опций атрибутов товара после завершения заказа в новый тикет (например, когда клиент оформил новый хостинг с миграцией сайта > автоматически создается тикет с данными доступа оставленными клиентом при заказе).
• Индивидуальные справочные материалы к продукту (индивидуальные блоки F.A.Q.).
• Смена тарифного плана (продукта) через промо-страницу (вместо неприглядного списка с тарифами, как в обычных биллингах). Заменяемый продукт временно маркируется для процесса для вывода вспомогательной информации на промо-странице (режим замены).
• Выбор опций генерации отчетных документов по продукту (период формирования актов, актов-сверок и др.).
• Экспорт продуктов в сторонние сервисы (например: Яндекс.Маркет, Google Merchant Center, Admitad и др.).
• Группировка продуктов по типам (product-kit).

Автоматизация управления хостинг-панелями:

• Управление аккаунтами в панелях Cpanel, ISPmanager (версии lite и pro), SolusVM, ProxMox (beta).
• Подготовленный API для интеграции с дата-центрами (для выделенных серверов), удостоверяющими центрами (SSL) и др.
• Универсальная форма авторизации (форма-посредник) в личном кабинете на сайте (с возможностью сброса/восстановления пароля).
• Менеджмент серверных парков (группы по типам серверов настроенных под определенные CMS).
• Индивидуальные логические сценарии для серверов разного типа (shared/vps/dedicated) и настроек под CMS: Битрикс, Drupal, WP и т.д. Например: для shared-хостинга под Битрикс по тарифу “N” при создании нового хостинг-аккаунта можно отправлять клиенту определенное email-сообщение с индивидуальным описанием и оформлением.
• Гибкость подстановки данных различного типа за счет использования дополнительных токенов (в шаблонах, в условиях (rules) и др.).
• Балансировка загруженности серверов для автоматизации процессов: на каком сервере создавать новый хостинг-аккаунт, уведомления о нагрузках свыше указанной нормы (штатная нагрузка не более 45%) и др.
• Логирование всех действий клиентов при работе с тарифами (апгрейд, блокировка, удаление, создание и т.д.).

Управление доменами:

• Reg Ru - поддержка регистрации менеджмента доменов в различных зонах (beta).
• Встраиваемая в ноды формы проверки доступности доменов (whois) с возможностью моментального оформления регистрации (beta).
• Редактирование DNS-записей (beta).

Центр поддержки:

• Универсальная справочная система с разграничением прав доступа к материалам (пользователи, клиенты, сотрудники). Категоризация и тегирование.
• Поиск по всем справочным материалам;
• Часто задаваемые вопросы с подсветкой вариантов по мере набора текста пользователем (клиентом);
• Тикет-система для клиентов с обновлением сообщений в реальном времени.
• Интерпретация тикетов в виде доски канбан, календарь и настраиваемыми списками.
• Гибкая настройка канбан-досок по статусам и на основе отделов поддержки в т.ч. по типам услуг и продуктов.
• Треккинг времени работы с тикетом.
• Внедрение форм и счетов на оплату в сообщение тикета.
• Автоназначение сотрудников поддержки в зависимости от установленных приоритетов по отделам и сотрудникам, а также по степени их загруженности (учет количества назначенных тикетов по определенным статусам).
• Проверка нахождения сотрудника online в системе при назначении тикета.
• Эскалация тикетов с трекингом в лог.
• Готовые шаблоны ответов (база ответов) для ускорения реакции поддержки по типовым вопросам.
• Автоматические ответы в случае задержки ответа.
• Отправка уведомлений сотрудникам поддержки в случае задержки реакции на тикет.
• Возможность публикации скрытых комментариев в тикетах (для общения в тикетах между сотрудниками).
• Форма согласия с условиями обращения в техническую поддержку перед созданием тикета.
• Онлайн-чат с поддержкой с возможностью приема/отправки файлов, проведения оплат и формирования тикетов из лога чатов.
• Скрытая капча (антиспам) для форм создания тикетов, обратных форм и онлайн-чата.
• Сортировка поступающих обращений в зависимости от уровня поддержки клиента (устанавливается в зависимости от статуса клиента).
• Импорт входящих email-сообщений в систему в реальном времени. Интерпретируются в тикеты. Ответы сотрудников дублируются на email клиента. Отметка о прочтении email приходит в сообщение тикета (скрытый пиксель).
• Возможность отправки ответа из тикета целенаправленно на email и/или sms. Хранение отметки о типе отправки.
• Импорт и экспорт сообщений из групп в социальных сетях (VK, Facebook, Instagram). Интерпретируются в тикеты. Ответы сотрудников дублируются в приватные сообщения клиентам в социальных сетях.
• Просмотр всех обращений от пользователя с фильтрацией по типам.
• Автоматическое определение устройства, IP-адреса, местоположения и другой информации.
• Трекинг входящих и исходящих звонков (VoIP) (beta).
• Трекинг временных затрат по каждому обращению.
• Построение отчетов для службы контроля качества (beta).

Клиенты:

• Установка статуса клиента в автоматическом режиме (на основе используемых способов оплаты).
• Установка статуса клиента в автоматическом режиме: в зависимости от купленных продуктов и/или пороговых значений LTV.
• Юридическое или физическое лицо.
• Смешанный баланс личного кабинета (баланс может пополняться как по безналичному расчету, так и по банковским картам и эл. деньгам от физического лица). В дальнейшем система учитывает эти особенности при формировании отчетных документов и очередности списаний.
• Сбор и хранение данных о пользователе (360 customers profile view).
• Автоматическая регистрация в системе при отправке сообщения в онлайн-чат, создание обращения через тикет (можно отправлять анонимам), email, социальной сети и заполнении форм.
• Сбор и конкатенация данных клиентов (телефоны, email, компания, Ф.И.О. и др.).
• Организация клиентских групп по признакам (organic groups).

Маркетинг:

• Бонусные баллы (кэшбэк) по индивидуальным настройкам каждого продукта.
• Оплата с баланса и/или бонусными баллами с указанием допустимой доли.
• Управление адресными рассылками (email, sms, внутренние в личном кабинете).
• “Нарастающие” скидки (как часть engagement-процессов).
• Ограничение по времени для возможности заказа продукта или пополнения баланса.
• Скидочный таймер под каждый продукт или группу продуктов с привязкой по уникальному ID и cookies.
• Скидки на опциях атрибутов товаров.
• Автоматическая генерация промо-кодов (например, за подписку на новости).
• Продажа подарочных сертификатов. Передача другому пользователю, применение подарочных сертификатов с авторегистрацией пользователя. Привязка к конкретной покупке, либо зачисление суммы сертификата на баланс ЛК.
• Продажа наборов продуктов (product kit) с общей скидкой.
• A/B тестирование промо-страниц.
• Назначение персональных скидок клиентам.
• Возможность управления рассрочкой для дорогих продуктов (beta).

Заказы:

• Возможность авансирования клиентов.
• Учет долговых обязательств клиента.
• Расчет остатка неиспользованных средств по услугам (при отмене услуги и возврате на баланс личного кабинета).
• Обработка и коррекция данных по ФИАС или КЛАДР.
• Виртуальный буфер корзины (когда требуется разделить набранные товары в корзину на несколько разных заказов в виду особенностей оплаты).
• Эквайринг Paymaster для резидентов РФ;
• Эквайринг Stripe для иностранных контрагентов (beta);
• Эквайринг PayPal (отключен, пока PayPal жестит с постоянными проверками);
• Shared-корзина (общая корзина на несколько сайтов на разных доменных именах).

Партнерская система:

• Привязка суб-аккаунтов (партнер вручную создает записи для своих клиентов);
• Аффилированная ссылка (классический учет привлеченных клиентов);
• Промо-коды со скидкой для клиентов (применение промо-кода связывает клиента с партнером);

Бухгалтерия:

• Генерация счетов и отчетных документов (актов и актов-сверок) для юр. лиц.
• Выгрузка готовых документов в СЭД (“Диадок”) для дальнейшего подписания и отправки (beta).
• Добавление в систему нескольких юр. лиц компании (часть услуг и продуктов мы предоставляем от своих дочерних структур).

Сотрудники:

• Расчет по KPI на основе скорости реакции на входящие заявки и качества их решения.
• Типизация задач с премированием за соблюдение установленных сроков выполнения.
• Единый интерфейс и логический принцип всех внутренних инструментов в системе.
• Разграничение прав доступа.
• Гибкая настройка уведомлений на основе приоритетов задач, загруженности сотрудников и отделов.
• Омниканальная система уведомлений сотрудников в случаях превышения установленного времени (задержки) реакции на задачу, инцидент или тикет.
• Просмотр назначенных тикетов и задач на сотрудника (виды: канбан, календарь, список).

Front-end:

• Стандартизация front-end. Исключение переписывания или перекрытия стилей в случае существенных изменений в дизайне.
• Ускорение оформления на 30% в сравнении с классическим написанием стилей на CSS.
• jFlex (см. видео-презентацию). Наша классоориентированная библиотека на SASS. Аналог bootstrap, но с более гибким управлением дизайном (микрошаблонизация) и функциональными возможностями (множество собственных и заимствованных jquery-плагинов с универсальным назначением).
• Адаптив + мобильная (отдельный рендеринг для мобильных устройств).

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

Можно считать, что этот кейс про хостинг-проект является примером решения сложнейших задач. Этот вид бизнеса подразумевает применение комплекса сложных технологий, масштабируемость, скорость и непрерывность работы. Стоит ли сравнивать с разработкой даже крупных интернет-магазинов? =)

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

На какой раскрученной CMS или модном фреймворке писать сервис для нас не имело никакого значения: вся суть в стратегии, перспективах и конечной выгоде.

К сожалению, в России рынок enterprise веб-решений на Drupal пока не так развит, как в других странах (просто у Drupal нет масс-маркетинга, да и по-сути он не нужен, ведь кому надо – разберутся и будут пользоваться), но уверен, что в скором времени ситуация будет меняться кардинально быстрее. Когда до предпринимателей дойдет, что знания и технологии НУЖНО капитализировать, а не перебиваться времянками и “скакать” с платформы на платформу, потому что программист ушел =)

По всем вопросам можете обращаться в здесь в ЛС, skype: a.4477, telegram: alex4477

Коллеги, поздравляю всех с Днем Победы!
По иронии этот текст был написан именно к 9 мая.

Полагаю, что сообществу будет интересен наш кейс, как мы пришли от хостинга к платформенным веб-решениям на Drupal.

Получилось “очень много букв”, но это про 5 лет работы с Drupal. Сложно написать одновременно кратко и емко.

Наша история началось аж в 2005, с хостинг-компании… Посчитав это направление интересным и перспективным мы с партнером вложились в свой первый бизнес.
Наивные, мы не понимали во что ввязались =) Следующие 2.5 года в качестве отдачи получали лишь только опыт.

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

Как и многие мы делали себе сайты на Joomla (Mambo), WP, Битрикс и в конце концов на Drupal. Пытались связать сайт с биллингом (чего только мы не использовали: WHMCS, Plesk, Billmanager и др.). Потом с 1С и другими решениями для автоматизации бизнес-процессов.

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

Ежедневные задачи: работа с тикетами, внутренними и клиентскими задачами, контроль качества работы сотрудников поддержки, обработка email, ведение и учет клиентов, работа с воронками, формирование финансовых отчетов, отправка email/sms-уведомлений и целевых рассылок… и еще куча всего.
У конкурентов были партнерки, продажа SSL, доменов, CMS-лицензий, услуги по администрированию, серверное железо и нам хотелось продавать это тоже. Это означало, что нам нужно еще более универсальное биллинг-решение.
Это далеко не полный список “must-have” для хостинговой инфраструктуры.

Арендовали кучу сервисов и пытались (< ключевое слово) их связать между собой, биллингом и сайтом. Про стабильность работы всей этой "системы" я промолчу. Вся структура была похожа один большой “костыль”. Да, мы знали все нюансы и косяки, предугадывали проблемы наперед. Но, назвать это комфортной работой было нельзя.
Еще раз повторюсь, чтобы хостинг окупался (речь не о прибыли) должно быть ОЧЕНЬ много клиентов. Технические риски росли по мере подключения нового функционала. Как масштабироваться с таким “вело-набором”? Очень большие риски.

Крупные конкуренты обладали ресурсами и работали на самописных решениях. У них были деньги на армию разработчиков, а у нас нет. Если бы мы наняли 3-4 разработчиков для написания сложного кастома, с нуля, то в случае, если кто-то из ниш решил бы уйти от нас - мы бы остались с кучей кода в котором вряд ли кто-то бы хотел разбираться. Пришлось бы писать новые костыли и повторить все круги ада. Этот путь проходили многие, мы знаем от коллег по веб-разработке и от клиентов.

Пришлось остановиться и хорошенько во всем разобраться. И вообще, больше ДУМАТЬ перед тем, как принимать решение и делать.

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

Прикинув возможности Drupal было предложено сделать все на нем, с нуля. Партнеру моя идея не понравилась =) Мы долго спорили, считали риски и в итоге не нашли консенсуса. Каждый пошел своей дорогой. Компанию перепродали крупному хостеру. А я остался с сотрудниками и решил все начать с нуля, а именно с создания комплексного решения на Drupal под новый хостинг-проект.

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

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

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

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

Вместе с командой разработчиков составили список необходимых нам решений с подробным описанием каждой функции.

Вот что получилось:

• Кросс-стандарты для front-end и back-end;
• Универсальный биллинг для “чего-угодно“ (взять лучшие решения у Plesk, WHMCS и др. и добавить в свое);
• Центральное управление хостинг-панелями из Drupal (ISPmanager, CPanel, SolusVM, Proxmox);
• Удобное и понятное отображение и управление товарами и услугами для клиентов;
• Регистрация и продление доменов, интерфейс управления DNS;
• Helpdesk (+тикетницу) и как минимум не хужче, чем это реализовано в WHMCS;
• CRM с системой уведомлений, воронками, канбаном, дэшбордами, realtime-аналитикой, группировкой клиентов по различным условиям, управлением задачами, учетом KPI сотрудников, интеграцией с 1С, трэкингом телефонии, обработкой email, сообщений из соц. сетей, мессенджеров и др.;
• Рекламные и персональные уведомительные рассылки;
• A/B тесты предложений на сайте;
• Сбор, хранение и управление данными о посетителях и клиентах (сейчас это модно называть "360 customers profile view");
• Личный кабинет: баланс (смешанный: для физ. и юр. лиц), бонусные баллы, нарастающие скидки и промо-коды;
• Партнерка (реферальные ссылки, промо-коды, суб-аккаунты, whitelabel);
• Онлайн-чат с возможностью приема оплат, выставлением счетов;
• Автоматика выставления счетов для юр. лиц (РФ) и формирования закрывающих документов;
• Простой учет и отображение доходов и расходов (в реальном времени);
• Менеджмент документов;
• Обучающие курсы для сотрудников и клиентов (в т.ч. с платным доступом);
• Интеграция эквайринга (прием платежей в РФ, Европе и США);
• Службы доставки (для физической доставки товаров);
• Собственные интеграции: DaData, Admitad, GA, Tagmanager, VoIP (UIS), Яндекс-сервисы и еще с десяток других;
• Маркетплейс товаров и услуг;

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

Про время и деньги
Проект получился дорогой и долгий. Нужно было отбивать зарплаты и приходилось браться за некоторые клиентские проекты. Нам повезло запустить крупные ecommerce-сайты для нескольких известных брендов (Великобритания, Германия, Россия). Называть компании не буду (NDA), но уверен, что каждый читающий этот кейс что-то у них покупал =)
Кстати, задачи у наших клиентов были примерно похожи: от нас требовалось в максимально короткие сроки запустить достаточно сложный функционал с интеграциями 1C, SAP и кастомными корпоративными ERP. Наши универсальные наработки позволяли сократить сроки в 4, а то и 10 раз. Не скажу, что все было идеально, но на тот момент критичные задачи бизнеса решались. Искренне благодарен нашим клиентам за их веру и поддержку в нас в и Drupal!

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

Сейчас все хорошо. Мы реализовали все, что когда-то планировали. Протестировали систему на наших и на клиентских проектах. Система в боевом режиме, работает как часы. Разумеется highload.

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

• интернет-магазины
• провайдеры услуг и сервисов
• маркетплейсы
• продажа digital-контента
• online-образование

Если кому интересно, вот некоторые скриншоты вида “под капотом”:

Список реализованных функций с описанием (не полный, еще пишем).

Разумеется, мы буду рад продемонстрировать систему всем желающим. Пишите мне в ЛС и я отправлю доступы к инстансу.

Существует некая иллюзия “идеальной” CMS среди их огромного множества. Если нужно создать масштабируемое решение с перспективой развития на несколько лет, то выбор сильно сужается до фреймворков и Drupal. Да, кстати, Drupal – это не CMS. Drupal – это логический принцип.

Drupal сегодня наилучшим образом подходит для построения платформ. Под платформами я имею в виду узкоспециализированные (целевые) CMS, конструкторы, CRM, биллинги, сервисы (SAAS-модель), хелпдески и др.
Drupal хорошо подходит для быстрого запуска сложных веб-проектов.
Drupal отлично подходит для сопровождения групп сайтов (применяя кросс-стандарты).
Drupal сложен для профессионального использования. Профессиональный разработчик скорее всего предложит “написать свое”, чем разбираться в особенностях Drupal.
Drupal – дорогое решение для небольших и средних веб-проектов из-за отсутствия целенаправленных готовых решений. О бесплатных билдах речи не идет, они чаще не адаптированы под конкретные задачи и представляют собой сборку модулей с так себе продуманной архитектурой.

Конечным потребителям:
Для создания простеньких сайтов лучше выбрать Joomla, WP или даже конструкторы типа WIX, Squarespace, uKit, A5. А для очередного мелкого интернет-магазина лучше купить CS-Cart, InSales, 1С Битрикс, UMI или же перебиваться на OpenCart.

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

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

Drupal – это о долгосрочных перспективах.

Желаю, чтобы как можно больше компаний в России начали применять Drupal и на достойном уровне. Так как это делается во всем остальном мире.

Все в наших руках, если очень захотеть =)

И еще раз всех с Победой!

Насколько критично: средне (14/25)

8 мая командой безопасности Drupal были выпущены обновления, закрывающие критические уязвимости в библиотеке typo3/phar-stream-wrapper.

Цитата специалиста по безопасности (google translate):

Чтобы перехватывать вызовы файлов, такие как file_exists или stat в скомпрометированных архивах Phar, необходимо определить и проверить базовое имя, прежде чем разрешить его обработку потоком PHP Phar. [...]
Текущая реализация уязвима для обхода пути, приводящего к сценариям, когда оцениваемый архив Phar не является фактическим (скомпрометированным) файлом.

Необходимо в срочном порядке обновить ядро до версии 7.67, а также 8.7.1 и 8.6.16.

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

Аккурат год перед тем я заступил на должность старшего Друпал-разработчика в рекламной компании “Wunderman”, а именно, в её пражском отделении. Попал я туда на редкость неудивительным способом - рекрутер нашёл меня на LinkedIn, последовало тестовое задание (весьма меня удивившее своей примитивностью - я искал в этом скрытого смысла, но, как вы дальше увидите, зря), собеседование по Скайпу и предложение работы. Предложение не подкупало ни щедростью, ни возможностями, но я всё-таки решил поехать. Как говорил Наполеон, “ввяжемся, а там видно будет”. Привлекала возможность окунуться в другую среду - язык, культура, вот это всё. Дальше последовал несуразно продолжительный процесс получения рабочей визы, и таки месяцев через 7-8 после первого контакта с рекрутёром я занял своё место в опенспейсе на втором этаже офисного здания у Смиховского вокзала.

Несмотря на то, что я довольно много путешествовал по разным странам и континентам, опыта постоянной жизни в другой стране у меня не было. Вид изнутри, конечно же, отличается. Во-первых, иллюзия близости культуры и характера чехов к русским исчезла довольно быстро. Вообще, идея славянства довольно уникальна. Никому не придёт в голову уподоблять, скажем, норвежцев немцам, или итальянцев французам на том основании, что их языки относятся к одной языковой группе. Но про славян это не так - почему-то подразумевается, что народы, говорящие на славянских языках, что-то объединяет. Не объединяет, не обольщайтесь. Чехи довольно замкнутый и ксенофобный народ - это не плохо, это просто продиктовано их историей. Любой малый народ, не имевший своего государства, должен защищать свою идентичность. Так что в целом чехи не любят ни русских, ни немцев, ни американцев. Они любят собак, которым здесь можно всё - например, сидеть на стульях в кафе. Потом, языковой барьер. Если у вас есть иллюзия, что вы заговорите по-чешски за три месяца, подышав воздухом пражских садов, выбросьте её. Скорее всего, вы по-чешски не заговорите никогда. Это такой же иностранный язык, как, например, суахили, и если 20% слов напоминают на письме русские, то неизвестно ещё, это в помощь или во вред, потому что означают они не совсем то и употребляются по-другому. Плюс чешское произношение, самое утробное и адское из всех, которые я видел. Полно русских, которые живут здесь годами и чешским владеют, ну, так себе. Не говоря уж об американцах и прочих неславянах. Но те, кто дают себе труд, говорят - хоть турок, хоть швед, хоть китаянка. При этом Прага город хоть и маленький, но вполне космополитичный. Местные жители в большинстве неплохо владеют английским, а неместных в некоторых местах больше, чем местных. И мне пришлось переоценить свои требования к владению иностранными языками - мой английский в России считался вполне неплохим, плюс я могу читать и изъясняться на французском, и при надобности разобрать тексты ещё на паре языков. В русскоязычной среде, и при удалённом взаимодействии с зарубежными коллегами, это более чем. Но когда стоит вопрос о том, чтобы свободно излагать абсолютно всё, как на русском, с той же скоростью и оттенками смысла, и понимать не меньше - это совершенно другой уровень, и достичь его не так-то просто, даже живя в стране носителей этого языка.

Сама по себе Чехия, конечно, тоже не совпала с идиллической картинкой с ТрипАдвайзора. Такое ощущение, что в различных областях отстаёт от передового человечества от 20 до 200 лет. Страна, попросту говоря, деревенская. Чешская кухня - мясо, пиво, картофан. Даже пряности им неизвестны. Любимое развлечение - “гриловать” (то есть жарить на костре мясо) и ездить на свою “халупу” (это как дача, только они там ничего не выращивают) и собирать грибы. При этом народ спортивный: бегают, крутят педали, гребут в байдарках, лезут по скалам, играют во флорбол. Условия для всего - отличные. Люди сами по себе достаточно приветливые, но отстранённые и прохладные. Всё везде поделено, частная собственность - святое. Это очень непонятно и неприятно для русского. Несмотря на свою спортивность, в работе чехи несравненны в своей медлительности и каком-то таланте делать всё через одно место. Даже эскалатор в метро едет в 2 раза медленней, чем в Москве. Рабочий день кончается часов в 4-5 (начинают, правда, рано), в пятницу и того раньше.

Теперь про работу и Друпал. Эта часть рискует напомнить главу “Серп и Молот - Карачарово” поэмы “Москва - Петушки”, потому что, кроме мата, сказать особенно нечего. Вкратце говоря, такого позора Друпала я ещё не видел, хотя повидал всякое. Напомню, речь идёт о рекламном агентстве Вундерман. Не думаю, что раскрою какие-то коммерческие тайны в своём рассказе. Вундерман имеет пяцоттыщ сотрудников по всему миру и чёртову уйму офисов. Пражский офис включал несколько сот человек, из которых было примерно 10 разработчиков. Чем занимаются остальные - фиг пойми. За разработчиков-то я точно могу сказать, что мы не делали ровным счётом ничего. Остальные собирались чуть ли не с девяти утра в отгороженных стекляшках и дружно втыкали в экран или на доску. Структура отделения разработки непрерывно менялась, но примерно можно сказать, что была одна команда под названием “бэкенд” (непосредственно друпалисты), в момент расцвета включавшая 5 человек (2 русских, 2 чеха и один бельгиец) с тимлидом - итальянцем, и две примерно такого же размера и интернационализма команды фронтендеров (разве что там, как и в компании в целом, доминировали латиносы). Надо всем этим сидел такой добрый чувак лет 40, который всех сотрудников через пару месяцев начинал возбуждать просто хичкоковской тайной - а что он делает? Выяснить это не удалось ни самым решительным, ни самым умным, ни самым внимательным. Плюс приходилось взаимодействовать с некоторым количеством проектных менеджеров. Основным заказчиком для команды друпалистов выступал Нестле и бренд “Пурина” в частности. При этом наивно полагать, что мы могли сами взять и сделать сайт. В Нестле сидит своё подразделение бракоделов под гордым названием Digital Solutions Unit (вообще, как показывает опыт, чем помпезней название должности, тем больший идиот её занимает). Они испохабили профиль Lightning и сварга́нили своё произведение под названием Lightnest, добавив багов, присыпав несовместимостью версий и немного обернув в проблемы с доступом. Естественно, все клиенты Нестле должны разрабатывать сайты на основании этого г...на. Причём мы могли бы починить все их баги, привести в порядок сам процесс инсталляции (потому что они не осилили даже документацию к blt и вместо нормального запуска composer'а обошлись своим главным орудием - cut&paste), но нам было строго запрещено это делать. Сначала я этого не понимал, выступал с предложениями, как сделать нормальный процесс разработки, объяснял, что такое Drupal best practices, а потом понял. Понял, что главная задача нашего подразделения - ничего не делать. И наш тимлид достиг определённого мастерства в создании сложностей на ровном месте, хотя надо отдать должное его деловым партнёрам - все они окончили факультет переливания из пустого в порожнее с красным дипломом. Причём для людей, проводящих большую часть жизни в таких конторах, характерна позиция "все кругом п###расы, один я - д'Артаньян". Все жалуются на бестолковость кругом, бесконечные совещания, то что им не дают ничего сделать. Тем не менее, они иногда умудрялись. Например, тот самый тимлид однажды редактировал руками composer.lock и удивлялся, что не помогает. Уровень управления проектами - когда я ещё пытался объяснить людям, что к чему, что есть, например, работа с контентом, процессы, роли, ПМ Катерина посмотрела на меня как на идиота: "Контент же управляется из Друпала." Деплой через гит, перетаскивание базы руками, потому что южноафриканское подразделение не поняло, как поменять site uuid при работе с конфигом. Месяц созвонов слепого с глухим, чтобы выставить на стейджинге trusted_host_patterns. В самом процессе выкатывания сайтов (которым Друпал вообще нахрен не нужен, потому что это статические рекламные визитки) участвовало по крайней мере 3 подразделения с кучей менеджеров, программистов и диджитальных архитекторов: Южная Африка, которая из говна и палок накидала параграфов, сделав полностью непригодной админку (это произведение было гордо названо White Label и продано руководству как универсальное решение всех проблем); пражское подразделение, которое пыталось собирать сайты из этих параграфов (как правило, код писать было запрещено, поскольку это подразумевало последующее прохождение security scan'а - мануальной инспекции сайта на предмет безопасности несколькими неторопливыми идиотами в Швейцарии); и на последней ступеньке пищевой цепочки индусы в Бангладеш, которые получали в Экселе контент для этих сайтов и перетаскивали его.

Глубины идиотизма можно описывать бесконечно, но пора обедать, поэтому перейду заключениям. Дрис, конечно, молодец - он продал Друпал. Только, как это часто бывает, деньги приносят позор и профанацию. Это напоминает продажу цыганами жестянок с надписью "биткойн" доверчивым гражданам. Друпала там, ей-богу, не больше чем Биткойна в этих жестянках. Чем больше компания, тем больше разрыв между теми, кто принимает решения, и теми, кто их выполняет. Очень похоже на Россию во все времена, кстати. Какой-то супер-топ менеджмент Нестле принял решение, что все сайты теперь будут на Друпале. Единственная проблема в том, что никто в том Нестле понятия не имеет, что такое Друпал. Они набрали спецов по объявлению, пошли к своим старым друзьям типа Вундермана - “могёте Друпал?” - “Г...о вопрос!” И понеслась. Единственная надежда на то, что деньги у Нестле никогда не переведутся и они никогда не заинтересуются, сколько на самом деле стоила бы разработка их сайтов.

В конечном итоге, естественно, все хоть на что-то способные разработчики разбежались из этой конторы. Более того, за ними пошли и ветераны. "Я ж, - говорит, - начинал здесь как контент редактор. Всему научился, но сравнивать было не с чем. А теперь Дмитрий и Эдуардо объяснили мне, и я не могу больше." Учитывая то, что все эти Дмитрии и Эдуардо были привезены из далёких стран с визами и билетами, менеджменту компании можно поаплодировать. Я, впрочем, не сомневаюсь, что тот, кто принимал решение их привезти, пошёл на повышение. Да, и из последних новостей - фронтендера Макса, который ни одной строчки не написал на ПХП, назначили друпалистом вместо ушедших.

Я не скажу, что из первых, но понял, что пора валить, после визита большой делегации из Нестле, когда было просто запрещено обсуждать вопросы по существу. Казалось бы, вся чешская пресса пишет, что нехватка кадров в ИТ, полно вроде бы вакансий. Ну я пошёл посмотреть. Поржал. Во-первых, Друпала в Чехии нет. Все чешские друпалисты (все 6) работают по удалёнке на австралийскую контору, которую основал их соотечественник. В Чехии куда ни пойдёшь (по крайней мере в плане ИТ) - всё крупнейшее в Центральной Европе. Это примерно как в Воронежской области. Центральная Европа - это Чехия со Словакией, Польша, из которой после вступления в ЕС уехало на заработки всё что движется, Венгрия и Румыния, откуда уехало в ЕС всё что движется воровать у тех, кто уехал в ЕС из Польши на заработки. Всё это крупнейшее в Центральной Европе разрабатывается то на чердаке, то в гараже за зарплаты, которые тоже не впечатляют. Ну и сама по себе работа двигать таски - не очень. Бизнес решает, а ты сиди и латай дыры. Тем не менее, я сделал пару тестовых заданий ради интереса. Их даже не проверили. То в отпуске, то заболел, то некогда. Ну и излишне говорить, что во всех этих крупнейших в Центральной Европе разработках нет ни одной чешской кроны - всё это по большей части немецкое ну или ещё с примесями иностранного капитала. Либо же - Вундерман отнюдь не единственная международная корпорация в Праге - сияют стеклом и неоном офисы Johnson&Johnson, Oracl’a, Novartis’a, банков. Но переезжать из одного болота в другое - как говорится, плавали, знаем. Отдельным анекдотом мог бы рассказать историю про переговоры с Новартисом, но уже не буду. И так никто до конца не дочитал.

Так что будете у нас на Влтаве - заходите в гости, не будете - спрашивайте, что интересно.

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

Модуль называется Rules Telegram и позволяет отправлять уведомления в телеграм через правила модуля rules.

Идея модуля была взята из репозитория Алексея Дёмина. Основная фишка кроется в том, что модуль позволяет использовать прокси сервер, т.к. телеграм на территории РФ заблокирован или работает нестабильно.

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

18 апреля командой безопасности Drupal были выпущены обновления, закрывающие критические уязвимости в ядре Drupal 7 и Drupal 8.

Необходимо в срочном порядке обновить ядро до версии 7.66, а также 8.6.15.

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

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

Хорошая и важная новость заключается в том, что переход с Drupal 8 на Drupal 9 должен быть действительно простым — кардинально более простым, чем переход с Drupal 7 на Drupal 8.

С единственной оговоркой, что необходимо будет внимательно проверить использование функций и кода, отмеченных как «устаревшие» и обновить их соответственно.

Если в модулях и темах на вашем сайте не используется устаревший код, который планируется удалить в Drupal 9, обновление до Drupal 9 будет очень простым. В действительности, это должно быть так же просто, как и обновление до минорной версии (например, с Drupal 8.6 на Drupal 8.7).

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

Например, в Drupal 8.0.0 мы отказались от \Drupal::l($text, $url). Вместо \Drupal::l() необходимо использовать Link::fromTextAndUrl($text, $url). Функция \Drupal::l() была отмечена к удалению в рамках работ по очистке кода, так как в Drupal 8 было слишком много способов генерировать ссылки.

Обычно устаревший код продолжает функционировать еще некоторое время, прежде чем он будет удалён окончательно. Например, функция \Drupal::l() по-прежнему доступна в Drupal 8.7, несмотря на то, что она была отмечена как устаревшая в Drupal 8.0.0 более трех лет назад. Это дает разработчикам модулей достаточно времени для обновления своего кода.

С релизом Drupal 9 наиболее устаревший код будет удален. Так, например, функция \Drupal::l() будет недоступна в Drupal 9.

Другими словами:

• Модули для Drupal 8, не использующие устаревший код, продолжат работать в Drupal 9.
• Модули для Drupal 8, использующие устаревший код, должны быть обновлены до выхода Drupal 9, иначе они перестанут работать в Drupal 9.

С более подробной информацией о политике депрекации кода в Drupal можно ознакомиться на странице https://www.drupal.org/core/deprecation.

Есть несколько способов проверить, используется ли на вашем сайте устаревший код.

Если вы разработчик сайта на Drupal, запустите утилиту drupal-check. Мэтт Гламан (Centarro) разработал инструмент статического анализа PHP под названием drupal-check, с помощью которого вы можете проверить кодовую базу сайта на наличие устаревшего кода. Я рекомендую сделать автоматический запуск drupal-check частью вашего процесса разработки.

Если вы веб-мастер или владелец сайта, установите модуль Upgrade Status. Этот модуль был разработан компанией Acquia. Модуль предоставляет графический интерфейс пользователя для утилиты drupal-check. С его помощью можно будет легко оценить готовность вашего сайта к переходу на Drupal 9.

Если у вас на поддержке имеются проекты на Drupal.org, включите тестовую инфраструктуру Drupal.org, чтобы обнаружить использование устаревшего кода. Есть два взаимодополняющих способа: вы можете запускать статический анализ кода и/или добавить в существующие тесты сбой при вызове устаревшего кода. Оба варианта можно настроить в конфигурационном файле drupalci.yml.

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

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

В документации по API вы можете найти инструкции по обновлению кода.

Я призываю вас начать прямо сегодня. Используя в модулях и темах новейшие версий API Drupal 8, вы сразу же получаете все преимущества от этих улучшений. Вовсе не обязательно ждать выхода Drupal 9.

Релиз Drupal 8.8.0 будет последним перед выходом Drupal 9. Но на данный момент список всех депрекаций еще не определен.

Drupal 9 планируется выпустить в июне 2020 года, а разработка Drupal 8 будет прекращена в ноябре 2021 года.

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

Мейнтейнерам проектов на Drupal.org необходимо помнить о политике расширенного выпуска релизов безопасности, согласно которой Drupal 8.8 будет поддерживаться до тех пор, пока не будет выпущен Drupal 9.1. Для модулей и тем оформления, которые будут поддерживать как Drupal 8.8, так и Drupal 9.0, могут потребоваться отдельные ветви в репозитории Drupal.org.

Дуэйн МакДэниел (Pantheon) проанализировал 7000 модулей для Drupal 8 утилитой drupal-check.

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

Перевод статьи «How to prepare for Drupal 9» из блога Дриса Бёйтарта.

Пробуем различные компоненты Bootstrap на своем сайте на Drupal 8.

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

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

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

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

• более миллиона зарегистрированных пользователей со 160+ стран мира;
• более 79 000 проектов локализации;
• основной инструмент компаний, которые хотят легко поддерживать свои продукты на нескольких языках и быстро добавлять новые;
• позволяет работать со штатными переводчиками, фрилансерами и профессиональными переводческими агентствами;
• поддерживает некоммерческие проекты с открытым исходным кодом;
• обеспечивает удобным функционалом как маленькие проекты так и проекты с более чем 10 000 переводчиками.

Я верю, что сотрудничество с Crowdin поможет нам значительно ускорить перевод документации Drupal и полезных статей на русский язык.

В течение ближайшего времени мы подготовим все необходимое для совместной работы над переводами и разместим отдельный пост с дальнейшей информацией.

Следите за новостями!

20 марта командой безопасности Drupal были выпущены обновления, закрывающие критические уязвимости в ядре Drupal 7 и Drupal 8.

Необходимо в срочном порядке обновить ядро до версии 7.65, а также 8.6.13.

14 марта командой безопасности Drupal были выпущены обновления, закрывающие критические уязвимости в ядре Drupal и контрибных модулях.

Если вы используете модуль Views на вашем Drupal 7 сайте, вам нужно немедленно его обновить.

Также необходимо в срочном порядке обновить ядро Drupal 8 до версии 8.6.11 или до версии 8.5.12 (если вы по какой-то причине не перешли на ветку 8.6)

Следом за ними 15 марта были выпущены версии 8.6.12 и 8.5.13

Ядро Drupal 7 обновлять не нужно.

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

Для связи с командой можно использовать личные сообщения. Ссылки на профили участников команды перечислены на странице «Контакты».

А вопросы по использованию сайта drupal.ru и модерации теперь можно задавать в телеграм-бот @drupalrusupportbot.

Исходный код drupal.ru с момента его открытия размещался на GitHub, при этом в качестве инструмента CI использовался сервис zen.ci. К сожалению, некоторые технические моменты затрудняют деплой кода на dev- и live-серверы проекта.

Мы решили перенести репозиторий на GitLab и воспользоваться встроенным в него GitLab CI. В наших личных проектах Gitlab и его CI показали себя отлично!

Проект drupal.ru доступен по адресу https://gitlab.com/drupal.ru

Пробный импорт репозитория из GitHub в GitLab прошел успешно. Теперь мы ожидаем, что участники сообщества, авторы тикетов (issue) и комментариев, создадут учетные записи в GitLab. Затем, приблизительно через неделю, мы сделаем повторный импорт репозитория, чтобы в GitLab отразилось авторство тикетов и комментариев.

Если вы создавали тикеты и участвовали в дискуссиях в репозитории drupal.ru на GitHub, то, пожалуйста, зарегистрируйтесь в GitLab с теми же данными, что в GitHub.

20 февраля командой безопасности Drupal были выпущены обновления, закрывающие критические уязвимости в ядре Drupal и контрибных модулях.

Если вы используете модули RESTful Web Services, JSON:API, Link, вам нужно немедленно их обновить.

Также необходимо в срочном порядке обновить ядро до версии 8.6.10 или до версии 8.5.11 (если вы по какой-то причине не перешли на ветку 8.6)

Ядро Drupal 7 обновлять не нужно.

Всем привет!

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

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

Мы хотим особенно отметить самых активных участников нашего сообщества и в знак признательности вручить памятные футболки.

• Александр Василенко @VasyOK
• Алексей Ещенко @dgastudio
• Алексей Кузнецов @gun_dose
• Андрей Постников @andypost
• Андрей Токмаков @Andruxa
• Батор Кореев @BatKor
• Борис Шрайнер borisshrayner
• Василий Лукасевич vlucas
• Вадим Бардачев vbard
• Геворг Мкртчян @ArmRus
• Иван Абраменко @levmyshkin
• Мирослав Ли miroslav-li
• Надежда Лях @DivaDii
• Никита Малышев @Niklan
• Николай Шаповалов drup8
• Семен Драгунов @whiesam
• Ярослав Лушников @zvse

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

Мы также хотим поблагодарить прошлых и нынешних участников команды drupal.ru за помощь в развитии сайта:

• Андрей Ивницкий @itcrowd72
• Антон Карпов @bumble
• Борис Сёмов @bsyomov
• Вадим Валуев @gease
• Виктор Степаньков @Semantics
• Максим Баев @mbaev

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

Дизайн футболки:

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

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

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

Из наиболее видимых изменений стоит отметить следующие:

1. Размер шрифта в материалах увеличен до 16px для улучшения читаемости
2. Базовым шрифтом установлен «IBM Plex Sans»
3. Шрифтом для сниппетов кода выбран «IBM Plex Mono»
4. Цвет ссылок в материалах установлен в значение #0678dd — это новый фирменный цвет drupal.ru
5. Изменены цвета текста, заголовков в списках, ссылок материалов.
6. Переработана страница материала
7. Переработан список комментариев к материалу
8. Переработано меню материала и комментария для улучшения пользовательского взаимодействия
9. Переработано отображение таксономии материала
10. Изменен внешний вид сниппетов.
11. Изменен внешний вид цитат
12. Переработаны списки материалов (страницы и блоки раздела «Трекер»)
13. Переработана страница «Блог» в профиле пользователя
14. В профиль пользователя добавлена страница «Комментарии», отображающая все комментарии пользователя

Кардинальные изменения были внесены в php-, html- и lesscss-код шаблонов страниц, списков и элементов:

1. Переработаны поля и отступы в материалах, комментариях, списках материалов, элементах для согласованности их внешнего вида. Размеры полей и отступов построены на базе сетки 5×5px.
2. В шаблонах материала, комментария и списков для css-классов применена BEM-like нотация с состояниями вида `.is-*`.
3. Унифицирован html- и lesscss-код, отвечающий за стили материалов, комментариев и списков.
4. Там где возможно, стили были переписаны с использованием Flexbox и CSS Grid.
5. Удалено большое количество устаревшего и неиспользуемого кода

Sorry, your browser doesn't support embedded videos,
but don't worry, you can download it
and watch it with your favorite video player!

Sorry, your browser doesn't support embedded videos,
but don't worry, you can download it
and watch it with your favorite video player!

Список проблем и багов, а также статус их исправления можно отслеживать в нашем репозитории в issue https://github.com/DrupalRu/drupal.ru/issues/1276

Laoyut Builder - это один из модулей ядра Drupal, который появился в ветке 8.5 в списке экспериментальных модулей, сейчас в ветке 8.6 он по-прежнему экспериментальный, но уже уже не альфа, а бета и уже вполне пригоден к использованию, а движуха в issues даёт понять, что разработчики твёрдо нацелены сделать этот модуль стабильным.

Зачем же нужен этот модуль? Он позволяет настраивать отображение любых сущностей с использованием Layout API,то есть берём шаблон (лэйаут) и вставляем в его регионы блоки. Помимо всех стандартных блоков (Block Content, Views и прочее) есть блоки с полями сущности. Пытливый читатель уже наверняка задался вопросом, зачем это всё, если есть Page Manager, Panels, Display suite и Panelizer? Ответ прост - перечисленные модули были популярны в 7 версии Drupal, а с выходом 8 версии эти модули наспех были портированы, в то время, как в ядре параллельно велась работа по созданию этого функционала с нуля, учитывая особенности архитектуры восьмёрки. Как итог - Page Manager на данный момент практически заброшен своими создателями, которые переключились на разработку Layout Builder. Разработчики Panelizer признают, что Layout Builder полностью заменяет его, и ведут разработку способов миграции с Panelizer на Layout Builder. Кроме того, интерфейс Page Manager и Display Suite выглядит совершенно дубовым для 2019 года. Раньше я во всех своих проектах использовал Page Manager и Panels и за это время уже надоело, что с выходом каждой минорной версии ядра Page Manager начинает глючить и приходится ставить всё новые патчи. К слову в моей заготовке composer.json было три патча для пэйдж менеджера, один для панелей и один для ядра, который был необходим для нормальной работы пэйдж менеджера. Использование Layout Builder позволило отказаться от всего этого.

Перейдём к делу - как пользоваться модулем? Тут всё невероятно просто: нужно включить модуль, а затем включить его функционал на странице управления отображением нужной сущности:

Как видно, у каждого режима отображения появляются две галочки - первая просто включает Layout Builder для данного типа сущности и вместо привычного списка полей появляется кнопка Manage Layout. Вторая галочка - наиболее интересная - она позволяет настраивать лэйаут для каждой сущности отдельно! Причём это не значит, что поставив её, скажем для статей, вам придётся постоянно собирать лэйаут каждой статьи. По умолчанию в каждой статье будет использован лэйаут, который вы настроите в Manage Layout, а при редактировании и просмотре статей будет просто ещё одна вкладка "Макет" (в английской версии Layout), где вы при необходимости можете настроить вывод отдельно взятой сущности.

Страница редактирования макета выглядит так:

Разделы (они же Sections) представляют из себя отдельные лэйауты. Тут очень важное преимущество перед Panels - можно поледовательно поставить в столбик несколько лэйаутов, в то время, как Panels позволяет использовать одновременно лишь один лэйаут. Как видно на картинке, один лэйаут добавлен, и можно добавить лэйаут до и после него. Когда лэйаутов много, можно вставлять лэйауты между ними, а также перетаскивать. Также можно перетаскивать блоки из региона в регион и из лэйаута в лэйаут. На картинке выбран двухколоночный лэйаут, поэтому горят две кнопки "Добавить блок" по одной в каждом регионе. Кстати, интересный момент, при вставке блоков с полями сущности можно настраивать форматтер поля как угодно - отображение лэйбла поля и все настройки, например, стиль изображения для картинок. Это позволяет одно поле выводить многократно разными способами.

У некоторых лэйаутов есть настройки (см на рисунке надпись Configure Section). Всё зависит от того, как сделан сам лэйаут - у самых простых лэйаутов настроек вообще нет. Но я использую модуль Bootstrap Layouts, в котором у каждого лэйаута можно выбрать классы обёртки и классы регионов - там стандартные колоночные классы бустрапа, плюс классы оформления, плюс возможность добавить любые свои атрибуты, что порой очень полезно. Даже если вы не используете Bootstrap, я очень рекомендую вам посмотреть модуль Bootstrap Layouts, ведь вы по образу и подобию сможете сделать настраиваемые лэйауты и для вашего сайта. Ниже скрины настроек лэйаута и списка выбора блоков:
 

Кнопка Create Custom Block заслуживает отдельного внимания - она создаёт обычный блок, но параметр reusable у него имеет значение FALSE. Это значит, что этот блок нельзя будет нигде повторно использовать, он не появится на странице "Пользовательские блоки" или "Схема блоков", а редактировать его можно будет только по "карандашику" из формы редактирования лэйаута. Если вы хотите использовать блоки повторно, то создате блок обычным способом через меню Структура - Схема блоков - Добавить блок и выберите этот блок из списка.

1. Можно настраивать лэйаут как для типа сущности в целом, так и для отдельной сущности.

2. Можно ставить несколько лэйаутов подряд.

3. Более быстрый доступ к редактированию лэйаутов (по сравнению с Page Manager, где нужно было кликнуть 4 ссылки, чтобы добраться до страницы с перетаскиванием блоков) и в целом боле удобный UX.

4. Более наглядный интерфейс - редактирование происходит в теме сайта по умолчанию, то есть все стили применяются сразу, а блоки при возможности показываются с нужным содержимым (иногда используются плэйсхолдеры, в зависимости от особенностей самих блоков). Также по субъективному ощущению - формы и ajax-коллбэки у Layout Builder работают значительно быстрее, чем у Page Manager.

Обзор был бы нечестным, если бы не были затронуты недостатки.

Первый недостаток: некоторые элементы интерфейса пока сыровато свёрстаны и могут "разваливаться" на некоторых темах. Но это очень легко решается, ведь для редактирования используется основная тема сайта, мне просто понадобилось добавить несколько строк CSS в свою тему, чтобы всё смотрелось хорошо.

Второй недостаток: Layout Builder не может полностью заменить Page Manager, ведь лэйаут билдер - это просто настройка отображения сущностей, соответственно, нет возможности перекрыть существующий роут, создать разные варианты для разных ролей или создать страницу с несколькими аргументами. Правда для себя я этот вопрос решил через кастомный модуль, который создаёт ещё один тип Section Storage, который можно прикрепить к своей Config Entity, и вызвать в своём кастомном контроллере, но это вариант для очень продвинутых.

Третий недостаток: модуль пока ещё экспериментальный, поэтому есть некоторые "детские болячки" и для некоторых вещей приходится ставить патчи, но насколько мне известно, часть этих "болячек" будут исправлены с выходом версии 8.7.

Как бы то ни было, взвесив все за и против, по личному опыту использования уже более, чем на пяти проектах, я однозначно могу сказать, что Layout Builder значительно лучше, чем Page Manager.

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

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

2.1. Добавляйте в блоки параграфы. У меня есть тип "Блок с виджетами", у которого виджеты - это разные типы параграфов на выбор.

3. По аналогии с "пустым" типом нод вы можете создать пустой тип блока, в который можете собирать другие блоки.

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

Ссылка на оригинал статьи в моём блоге