Друпальчики

Возвращение к истокам произошло

graker_editor — Thu, 29 Oct 2026 09:30:00 +0000

Свершилось то, о чем так долго говорили большевики. Моя домовая страница переехала на Drupal 11! И, надо заметить, года все-таки не прошло.

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

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

заметки в бложеке сделал на параграфах, и это самое клёвое. Теперь можно втыкать в середину поста что угодно, например тизеры всякие. На следующем обзоре сериальчиков испытаю.
галереи можно смотреть целиком в лайтбоксе, независимо от пагинации.
всякое сео-гео-шмео и микроразметка стали гораздо лучше (во всяком случае, полнее).
поиск на search api куда круче того, что в октобере был.
админка на gin, reorder фоток в альбомах, апгрейд бутстрапа с 3 до 5 и много разных удобных мелочей.

Единственное, что в Октобере мне нравилось больше — это маркдаун-редактор, в который удобно втыкать тексты из Обсидиана. Наверно сделаю себе такой же.

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

Вообще конечно Клод Код тут оказался чистой магией под кончиками пальцев. Не только хорошо собрал на Друпале то, что задано — он еще и парсер для импорта материалов написал так, чтобы сразу по параграфам раскладывать, и медиа тоже импортнул с разделением на типы, как надо, и focal point поставил. До кучи написал юнит-тесты на кастомный код и визуальные регрессии на BackstopJS, чтобы проверять как дизайн перенёсся.

Тут дело (помимо качества самого Клода, естественно) в двух вещах:

У Друпала огромная инфраструктура и сообщество. Масса материалов, примеров, кода, практик. Через это Claude Code очень хорошо умеет в Drupal.
У меня несколько проектов на D11 сделанных уже есть. Соответственно, есть наработки, чеклисты, джентльменский набор модулей и практик. Клоду можно это показывать — и он сразу сделает как мне нравится.

PageSpeed на десктопе после переезда показывает вот чего:

Сильно круче, чем было. У мобилок перформанс немного похуже, но победим и это.

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

Заодно я кстати переехал в селектель, заменив последнюю копию надоевшей панельки ispmanager на traefik + docker compose окружение. Но про это в другой раз.

В общем, крайне доволен. Теперь надо доделать новый сайтик студии и заживём!

Нейросети и анализ кода

graker — Wed, 22 Jul 2026 09:15:00 +0000

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

Отчет структурированный, нейросеть проверяла всех четырёх всадников попокалипсиса в проекте: Уязвимости, Баги, Тормоза и Грязный код. Изначально из переданного отчета получалось гораздо больше задач, но процентов на 30% я сразу won't fix навесил. Там и глюки нашлись, и непонимание контекста. Но 40 тикетов тем не менее осталось.

Среди них тоже в основном таски с минимальнейшим приоритетом, типа

в кастомном модуле не проставлена зависимость от чего-нибудь типа paragraphs;
где-то в коде наглый программист вызвал \Drupal::service() вместо инъекции зависимостей;
где-то deprecated-версии Друпала не убраны из поддерживаемых версий и тому подобное.

Нашлось и несколько более серьезных претензий:

парочка проблем N+1;
несколько XSS-уязвимостей (доступных только админам, но всё же);
несколько мест, где отсутствуют проверки на наличие ключа в массиве (спамит в лог предупрежденими);
и даже одна уязвимость типа timing oracle.

Да, грязненький код — признак грязненьких мыслей :) Да, хорошо бы всё это почистить. Но за вычетом 3–4 претензий, это получается больше ста часов работы суммарно, а выхлоп — немножко более чистый код, причёсанное legacy, немножко меньше техдолга и warning/debug-записей в логе. Хорошо конечно, когда заказчик не против провести такую генеральную уборку. И честь и хвала аккаунтам, которые могут убедить заказчика в необходимости такой уборки при примерно нулевой ценности для конечного пользователя.

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

Критичное обновление безопасности в Drupal

graker — Tue, 19 May 2026 18:05:00 +0000

Как понять, что у какого-то проекта клёвая инфраструктура?

Ты прочитал письмо в рассылке, что у проекта через несколько дней выйдет обновление безопасности. Добавил в календарь, чтоб не забыть обновить всё и всех. Потом получил письмо СРОЧНО ВАЖНО от одного хостера. Потом от другого и третьего. Всё про это обновление безопасности.

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

Так что и я глаголю вам: да, завтра с 17 до 21 UTC должен выйти патч безопасности Drupal 10 и 11, вот страничка об этом. Обновление обозначено как высоко критичное, набрало 20 из 25 баллов по шкале трэша, угара и содомиии рисков безопасности. В воздухе запахло озоном, на теле заныли шрамы, полученные в ходе Друпалгеддона I и II.

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

И да — вот такая клёвая инфраструктура сейчас у Drupal. Отдельная рассылка по обновлениям безопасности. Команда, которая этими дырками занимается. Проверки дырочек не только в ядре, но и в контрибных модулях. Патчи выкладываются в определенный день с предварительным уведомлением.

И да — Drupal при этом совершенно бесплатный.

Как мы обновляем Drupal

graker — Sun, 08 Feb 2026 06:30:00 +0000

Год назад, в январе, окончательно наступил конец жизненного цикла Drupal 7. Однако заявки на обновление с «семерки» до актуальной версии появляются до сих пор. Как и в целом заявки на обновление Друпала. В связи с чем небольшой ликбез о том, как мы обновляем Drupal и

Зачем вообще что-то обновлять

Основных причин обновлять Drupal, как и другую CMS, как и программное обеспечение в общем, три:

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

И если без пунктов 1 и 2 в принципе можно жить, то пренебрегать обновлениями безопасности не следует. Дело в том, что сайты взламывают не только в кино, и не только какие-нибудь крупные, или известные. Со временем к найденным в ПО уязвимостям пишут сканеры и эксплойты — программы, которые автоматически находят сайты с незакрытыми уязвимостями и автоматически же их взламывают. А взломщику достаточно просто запустить эту программу — и вот у него уже доступ к вам на сервер.

Играюсь в Drupal Canvas

graker — Tue, 27 Jan 2026 16:15:00 +0000

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

Пока вкратце:

— прикольно;
— польза от компонентной верстки / SDC / сторибуков и этого всего — возросла;
— интеграция с остальной инфраструктурой Дру пока невысока;
— есть конечно немного багов.

Happy birthday Drupal!

graker — Thu, 15 Jan 2026 20:25:00 +0000

Официальный сайт внезапно сообщил, что сегодня Друпалу стукнуло 25 лет! И это отличный повод предаться ~~старческому ворчанию~~ воспоминаниям.

Сам я прикоснулся к прекрасному примерно 20 лет назад. Трудился я тогда в микроэлектронике, зарплаты были небольшими, зато платили их довольно нестабильно. И все ребята искали способов подзаработать. Кто-то увольнялся в коммерческую разработку, кто-то открывал параллельно малую торговлю.

Ну а я полез на веблансер искать заказы. Благо задержки зарплаты в несколько месяцев и работа рядом с домом позволяли иметь весьма свободный график. И там, на веблансере, я увидел проект шахматного портала. Сразу понял, что это знак судьбы! К шахматам я всегда относился трепетно, а незадолго до этого написал на c++ программку для игры по сети. Мы ее с товарищем яростно тестировали, мечтая устроить в зеленоградской сети локальный филиал Новых Васюков.

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

Но было круто! Мы нашли java-кодера, переписали с ним полезные части моего движка на php под сервер на Друпале, и сделали к нему клиентский джава-апплет для игры.

А особенно круто было тестировать. Я позвал знакомого кмса, чтобы он меня по 10 раз в день выносил. Ну и иногда я его, разок в неделю.

А дальше... дальше видимо сработал синдром утёнка. Шахматный портал не выжил, но Друпал остался ждать.

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

Подтянулись интересные люди. В коммьюнити Drupal.ru нашёл их ещё больше. Некоторые из них кстати здесь с нами, в этой комнате. Здоровья вам и успехов, друзья и коллеги!

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

Что тут скажешь. ~~Вот чего шахматы с людьми делают~~ С днём рождения, Drupal! Many happy returns!

Друпал жыв!

graker — Fri, 12 Dec 2025 11:10:00 +0000

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

И довольно часто слышу в ответ что-то вроде: «Друпал? А он что, еще жив?»

Понять можно. Если человек сталкивался с ним когда-то давно, в начале 10х годов например, и тогда показалось что он не очень актуален, то сегодня-то тем более. Тогда Друпал критиковали за всякое — и за «отсутствие ООП», и излишнюю функциональность, и за принцип not invented here, и за сложность перехода от одной мажорной версии к другой. Хотя лично мне и D6, и D7 хорошо заходили.

Это как встретить старого приятеля, которого не видел 20 лет. Сознание не очень-то интерполирует его «возможный жизненный путь» и не натягивает его на эти 20 лет. Поэтому может показаться, что он все такой же, как «тогда». А он уже не такой.

Вот и Друпал уже не такой. Правда, за эти годы он нажил не седину, геморрой и алименты. А наоборот — стал гораздо краше! В конце 2015-го с ним произошло лучшее, что могло произойти: вышла версия 8, в которой сделали:

— Конфиги на yaml. То есть всё, что ты накликал в админке, лёгким движением руки выгружалось в файлики и автоматически разворачивалось в продакшне. Это упростило в разы не только разработку, но и поддержку: теперь можно легко увидеть, чего там клиент в настройках нажал и всё сломалось. Увидеть и отменить.

— Установку и обновление всего через composer. Апгрейд мажорных версий тоже упростили. Для перехода с 8 на 9, 10 и 11 переписывать сайт целиком уже необязательно.

— Темизацию на Twig, медиа-библиотеку а ля Wordpress, поддержку REST для вывода контента в JSON/XML и получения headless CMS, и много чего ещё.

— Отринули критикуемый многими принцип not invented here, по которому не любо было тащить в ядро сторонние решения. Отринули и тут же затащили под капот Symfony.

Это такой крутой фреймворк на PHP, на котором можно писать в три раза больше кода, чем в Laravel, зато он будет чистый и правильный.

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

Ляпота, короче. «Свинья в помаде» (для тех кто не помнит) превратилась в ~~прекрасную бабочку~~ серьезный современный продукт. С высоким по-прежнему порогом вхождения и с чувством полного удовлетворения от своей работы, если этот порог преодолеть.

— Так что, да, Друпал жив! — глаголю я вам в ответ, дорогие друзья. И уж точно поживее многих.

Да, в нашей стране ситуация с ним не очень удачная: всё вокруг поглотил 1С Битрикс. Хотя обидно не это, так бывает. Мне как разработчику обидно, что на то нет никаких технических причин. Писал про это в статье CMS vs Framework.

При этом во всем остальном мире с Друпалом полный порядок. Серьёзные контентные сайты, крупные, со связанными поддоменами, университеты, e-com, государственные порталы — везде ему находится применение. Поработал с парой десятков проектов в Европе и США, за последние 7 лет 1 каталог перешел на ~~битрикс~~ WordPress, 1 магазин на Shopify — в связи со сменой маркетинговых команд, которым на входе конечно надо всё переделать. Остальным всё круто, работают годами. Хотелось бы конечно и на нашем рынке с ним чаще работать.

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

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

Вернёмся к истокам

graker — Fri, 28 Nov 2025 14:20:00 +0000

Обсуждал тут улучшения своих сайтиков с чатом жопотэ, дипсиком, перплексити и другими сказителями. Идей роботы озвучили очень много, и внезапно я понял, что нужно возвращаться к истокам: взять и переписать эту домовую страницу и лендинг студии обратно на ~~Turbo Pascal~~ Друпал.

Эксперимент с October CMS был по-своему прекрасен, узнал и сделал много нового, и CMS неплохая. Но ряд вещей, которые я хочу сделать, на Друпале сделать тупо в 2–3 раза быстрее.

Перенести в принципе недолго, сделать всё на вьюзах, а шаблоны фронта в October уже сделаны на twig. Можно даже управиться к Новому году. Надо только понять, к какому.

О выборе между CMS и фреймворками и некоторых мифах этого выбора

graker — Fri, 14 Nov 2025 14:50:00 +0000

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

— CMS только для несложных / шаблонных проектов;
— если нужна нестандартная логика — поможет только фреймворк.

Посмотрим, так ли это, всегда ли это так, а заодно рассмотрим несколько, возможно, странных, но настоящих мифов и возражений заказчиков.

CMS — Content Management System, система управления контентом. Популярные CMS — это Wordpress, Drupal, ModX, Joomla и, конечно же, 1С-Битрикс. В CMS предполагается наличие административного интерфейса и настроек.

Фреймворк (framework) — это набор инструментов, библиотек и способов написания кода, который обычно не предполагает уже существующих настроек и конфигураций, а предполагает их программирование. Популярные фреймворки веб-разработки — это, например, Laravel, Symfony, Django, Yii, Ruby on Rails, Next.js.

Кэш

graker — Wed, 08 Oct 2025 13:40:00 +0000

Если бы не работа на европейских проектах с CMS Drupal, никогда бы и не узнал, что

по-русски     — кэш
по-английски  — cache
по-французски — cache
по-испански   — caché
по-итальянски — cache
по-шведски    — cache
по-румынски   — cache
по-немецки    — Zwischenspeicher

Про разработку и поддержку магазина на Drupal 9

graker — Mon, 08 Sep 2025 20:40:00 +0000

Как-то сделали мы крутой магазин на Drupal 9 американскому отделению известного бренда, называть который конечно же не следует.

Импорт товаров, постоянная синхронизация складов, десяток видов доставки, трекинг, фасеты. Поиск и каталог на Apache Solr с кастомизированным индексом: заказчик хотел, чтобы некоторые атрибуты товара отображались в каталоге как отдельные позиции, а страница у товара была при этом одна.

Пару лет поддерживали, до Drupal 10 поапгрейдили. А потом решил заказчик сменить всю маркетинговую команду, а команда, соответственно — субподрядчика по сайту, то есть разработчика.

А потом новые подрядчики приходят и говорят — проконсультируете нас по коду, если что, расскажете чего зачем?

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

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

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

Думаю только — вот бы и нам такие проекты на поддержку передавали.

Деплои и удаление зависимостей

graker — Fri, 23 May 2025 12:55:00 +0000

Note to self: когда есть задача выключить из проекта тот или иной контриб-модуль, никогда не надо в этой же задаче требовать убрать сам код модуля из проекта.

На примере Drupal и PHP: во всех деплой-скриптах, что мне доводилось видеть или писать, composer install (установка/обновление/удаление зависимостей) всегда идет первее drush updb (миграции БД) и drush cim (импорт загруженной из гита конфигурации). И это разумно в большинстве случаев: сначала при деплое мы тянем из интернета новые зависимости, затем запускаем миграции БД, требуемые этими зависимостями, затем применяем конфиг для этих зависимостей, включая yml-файлы с настройками нового модуля.

Однако при удалении модуля всё происходит наоборот: сначала нам нужно применить конфиг, в котором модуль «выключается» из системы, при этом будут удалены yml с его настройками, а также вызваны нужные обратные миграции БД. И только потом уже нам нужно вызвать composer install чтобы композер заметил отсутствие модуля в зависимостях и удалил его из кода.

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

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

VS Code и Codeium

graker — Tue, 19 Nov 2024 18:55:00 +0000

Перешел не так давно на VS Code с phpstormа, работает неплохо, плагины есть, в целом доволен. А сегодня поставил Codeium — ИИ-плагин, чтобы вкалывали, значит, роботы, а не человек.

Сначала говорю ему: — чат жопотэ, напиши чтобы я нажимал на иконку, а из неё плашка выпадала с уведомлениями!

Он написал. И даже once не забыл, и переделывать почти не пришлось. Потом попросил сделать плашку белой, с синим скругленным бордером и тенью. 2 секунды, сделал, про position absolute сам догадался.

Решил попробовать что-нибудь друпальное. Вот что я получил по промпту Count workflow notifications where recipient is current user id and viewed is NULL.

$query = $this->entityTypeManager->getStorage('workflow_notification')->getQuery();
$count = $query
    ->condition('recipient', $this->currentUser->id())
    ->condition('viewed', NULL, 'IS NULL')
    ->count()
    ->execute();
return $count;

Никакой специальной подготовки, плагин сам все нужные Drupal API увидел. Просить просто «for current user, not viewed» не стал — забоялся. Причем не знаю, чего больше — что не поймет и придется второй раз вбивать, или что все равно поймет и сделает. Попросил сгенерировать к этому коду комментарий, оказалось, всё понимает:

 /**
   * Count the number of workflow notifications that belong to the current user
   * and are unread.
   *
   * @return int
   *   The number of unread notifications.
   */

В целом этого достаточно уже, чтобы пользоваться повседневно. Как говорится, the future is here ~~this is how I disappear~~.

Завтра заставлю роботов писать за меня юнит-тесты. А также нажму манящие кнопки Refactor и Explain рядом с кодом.

Хакаем Drupal правильно

graker — Fri, 11 Sep 2020 11:35:00 +0000

С переходом в Drupal 8 на composer запихивать контрибные модули и само ядро в git стало совсем не удобно и не правильно. Но хакать (точнее, делать лучше!) модули и ядро все равно хочется. К счастью, с композером это даже удобнее.

Допустим, мы внесли изменения в модуль contrib_module и хотим их увековечить в своем гите. Действия следующие:

Ставим пакет cweagans/composer-patches:
```
composer require cweagans/composer-patches
```
Хакаем, собственно, модуль.
Переходим в директорию с модулем и делаем патч:
```
git diff HEAD > contrib_module_patch_1.patch
```
Если в директории модуля отсутсвует .git и патч поэтому сделать не получается — удаляем модуль и ставим заново:
```
composer require drupal/contrib_module --prefer-source
```
Теперь патч должен получиться.
Переносим патч в какую-нибудь отдельную директорию, например /patches в корне проекта.
Сбрасываем изменения в директории модуля:
```
git checkout .
```

В composer.json в секцию extra добавляем:

"patches": {
    "drupal/contrib_module": {
        "patches/contrib_module_patch_1.patch": "patches/contrib_module_patch_1.patch"
        // тут будут другие патчи этого модуля
    }
    // а тут патчи других модулей
}

Теперь при запуске composer install патч будет применяться автоматически. И если код модуля обновится так, что патч станет неприменим (например, его включат в код модуля) — композер ругнется и мы сможем проверить, в чем дело.

Дополнительная плюшка: в patches можно добавлять не только рукотворные патчи, но и прямые ссылки на патчи, например, с D.org.

P.S. Ну и кинуть патч в ишью самого модуля не забудьте, для общего блага.

Формула плюрализации в Drupal 8

graker — Fri, 24 Jul 2020 09:40:00 +0000

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

Но оказалось, что в Drupal 8 эта проблема начинается уже с экспорта. Экспортированный ru.po с сайта, где с плюрализацией всё в порядке, внезапно содержал дефолтную английскую формулу. Попытка выкачать и вставить нормальную формулу со старого сайта на Drupal 7 тоже не помогла. При импорте просто ничего не происходило, формула оставалась дефолтной.

Пришлось поковыряться в коде и оказалось что в Drupal 8 формула плюрализации хранится (в state) не в виде строки, а в виде массива вариантов. Пришлось сделать сначала

drush eval "print_r(\Drupal::state()->get('locale.translation.formulae', []));"

на нормальном сайте для получения русской формулы.

После чего оформить её в правильный массив и выполнить вот такой код:

$formula = Array(
  'ru' => Array(
    'plurals' => 3,
    'formula' => Array(
      1 => 0,
      2 => 1,
      3 => 1,
      4 => 1,
      21 => 0,
      22 => 1,
      23 => 1,
      24 => 1,
      31 => 0,
      32 => 1,
      33 => 1,
      34 => 1,
      41 => 0,
      42 => 1,
      43 => 1,
      44 => 1,
      51 => 0,
      52 => 1,
      53 => 1,
      54 => 1,
      61 => 0,
      62 => 1,
      63 => 1,
      64 => 1,
      71 => 0,
      72 => 1,
      73 => 1,
      74 => 1,
      81 => 0,
      82 => 1,
      83 => 1,
      84 => 1,
      91 => 0,
      92 => 1,
      93 => 1,
      94 => 1,
      101 => 0,
      102 => 1,
      103 => 1,
      104 => 1,
      121 => 0,
      122 => 1,
      123 => 1,
      124 => 1,
      131 => 0,
      132 => 1,
      133 => 1,
      134 => 1,
      141 => 0,
      142 => 1,
      143 => 1,
      144 => 1,
      151 => 0,
      152 => 1,
      153 => 1,
      154 => 1,
      161 => 0,
      162 => 1,
      163 => 1,
      164 => 1,
      171 => 0,
      172 => 1,
      173 => 1,
      174 => 1,
      181 => 0,
      182 => 1,
      183 => 1,
      184 => 1,
      191 => 0,
      192 => 1,
      193 => 1,
      194 => 1,
      'default' => 2,
    )
  )
);

\Drupal::state()->set('locale.translation.formulae', $formula);

Тогда нормальная формула вернулась на место.

На эту тему есть несколько ишью, залинкованных между собой, и пока не закрытых. Вот например. А пока — экспортируем и импортируем переводы осторожно.

Делайте дампы правильно

graker — Mon, 13 Jul 2020 10:32:00 +0000

Прислали тут мне дамп друпальной БД в таком формате. Сначала описание таблицы без ключей, затем вставка данных в таблицу, затем, в конце файла после всех таблиц и данных — объявление ключей для каждой таблицы. Хрен его знает, чем и зачем этот дамп так сделали. Но оказывается — в таком формате его нельзя импортироать в MySQL, настроенную на работу в кластере. На этапе вставки данных будет ругаться, что primary-ключей еще нет. Вот так:

ERROR 3098 (HY000) at line 40: The table does not comply with the requirements by an external plugin.

А чтобы вылечить, надо накатить этот дамп куда-нибудь локально, без кластера. И затем сделать дамп уже обычным mysqldump. Там ключи сразу объявляются, в описании структуры таблиц.

Бобёр

graker — Wed, 25 Sep 2019 07:50:00 +0000

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

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

Участвовали мы в разработке сайта bober.ru — это сайт телеканала «Бобёр», который принадлежит организации «Первый канал. Всемирная сеть». Тематика канала — разнообразные рецепты и советы на тему DIY (то есть, Сделай сам). Как сажать смородину, снять-повесить радиатор, или собрать портативный ядерный реактор из часов, трусов и противогаза. Помимо «централизованного» контента, делиться всяким на сайте могут и пользователи.

Дизайн и верстку сайта (html, стили, js) сделали на стороне заказчика. А мы делали бэк-энд на Drupal 8 и натягивали предоставленный фронт на тему Друпала. Делали авторизацию через социальные сети, поиск на Solr, пуш-уведомления, почтовые рассылки, QnA, комменты, блоги, модерацию и всякие вещи помельче.

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

Спасибо всем, кто участвовал!

Отдельное спасибо руководителю проекта на стороне заказчика — за внимание, понимание, поддержку и высокий профессионализм. Было круто!

Drupal 7 AWS S3 и проверка файла на существование

graker — Thu, 21 Mar 2019 07:15:00 +0000

Есть в Drupal такой модуль, S3FS, создает стрим-враппер s3:// для работы с файловыми бакетами на Amazon S3. Модуль в принципе удобный и работает, но вот только не все файловые функции умеют в такой стрим. Например, если мы хотим проверить, существует ли в бакете файл, то file_exists('s3://myfile.txt') всегда вернёт FALSE.

Если заглянуть в код класса S3fsStreamWrapper, то там для проверки используется $this->s3->doesObjectExist(). Можно было бы сделать красиво, вот так:

file_stream_wrapper_get_instance_by_scheme('s3')
  ->s3
  ->doesObjectExists('my-bucket', 'myfile.txt');

Только вот незадача: $this->s3 — клиент S3 Aws\S3\S3Client, вокруг которого работает стрим-враппер — это protected-свойство.

Пришлось ковыряться и делать некрасиво:

$config = _s3fs_get_config();
$s3 = _s3fs_get_amazons3_client($config);
$s3->doesObjectExist('my-s3-bucket', $filename);

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

А мораль такая. Если вы пишете враппер вокруг какого-нибудь сервиса, и решили сделать свойство, содержащее объект сервиса, недоступным снаружи — подумайте. Может хоть геттер добавить стоит, если уж не реализуете обертку над каждым полезным методом?

Drupal и фильтр по редакциям

graker — Tue, 19 Feb 2019 07:45:00 +0000

Как я уже упоминал, в коробке Drupal 8 есть такой полезный модуль Content Moderation. Он позволяет модерировать материалы на базе редакций (revisions): материал может быть в состоянии (moderation_state) черновик, опубликован, или в архиве. Названия состояний можно менять, можно добавлять и новые состояния, и переходы между ними. При каждой смене состояния материала создается новая редакция. Благодаря этому можно, например, оставить проверенную редакцию опубликованной для всех пользователей сайта и, в то же время, работать с более новой редакцией в состоянии черновика.

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

Drupal 8 и дефолтные редакции

graker — Fri, 15 Feb 2019 08:10:00 +0000

Есть в Друпале такая полезная штука — редакции (которые revisions). На базе редакций работает, например, модуль Content Moderation, реализующий workflow для модерации контента с помощью состояний (черновик — опубликовано — в архив, и всё такое). Благодаря управлению состояниями через редакции, можно без труда реализовать такой сценарий:

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

Возможность оставить опубликованную версию видимой достигается за счет того, что редакция материала в состоянии «опубликовано» объявляется дефолтной (revision_default). Именно её будет по умолчанию загружать Друпал для отображения, в то время как при редактировании будет загружаться последняя редакция материала.

Так вот, нам может понадобиться проверить, является ли загруженная редакция сущности дефолтной. Для этого у контентных сущностей есть метод isDefaultRevision(). Вот только работает он иногда несколько неожиданно и может этим выклевать весь мозг. Оказывается, если вызвать этот метод, например, из hook_form_alter() при редактировании существующего материала (node/$id/edit) — он внезапно будет возвращать FALSE всегда. Независимо от того, дефолтную редакцию мы правим, или нет. Видимо, для редактирования Друпал заранее создает новую не-дефолтную редакцию и сущность готовит уже в этой редакции. Или типа того.

Так или иначе, поведение это совершенно контринтуитивное. Особенно учитывая, что если в этот момент запросить у сущности revision id — то вернётся как раз id дефолтной редакции (если редактируется она). Но isDefaultRevision() все равно будет FALSE.

Возможность выкрутиться из этой странной ситуации, тем не менее, есть — в виде метода wasDefaultRevision(), который проверяет, была ли эта редакция дефолтной при последнем сохранении сущности. Из hook_form_alter() этот метод отрабатывает ожидаемо — возвращая TRUE, если редактируется дефолтная редакция, и FALSE — если последняя не-дефолтная. Такие дела.