Перешел на 9.3 (с 8.9). Уже слегка задолбался отлавливать мелкие не сразу заметные баги, но большинство вылечилось имеющимися патчами.

Давно-давно написал восьмерочную версию модуля KML. Большую часть "ООП-обвязки" просто скопипастил оттуда и отсюда, не всегда на 100% понимая что делаю, но модуль работает у меня и еще нескольких десятков человек

Нечасто пользуюсь клавиатурной навигацией в формах, но тут заметил, что при нажатии на tab курсор перепрыгивает не на следующее поле, а хз куда. Глянул в код - у всех инпутов стоит tabindex=-1. Раньше этого точно не было.
Что делал в последнее время - обновлял ядро с 8.9.13 на 8.9.16 и целую кучу контрибных модулей.
Что бы это значило? Гугл не даёт лёгкого ответа.

Есть content type с полем image. Оно было и есть required. Раньше оно было single value, и сохранить ноду с пустым полем image было невозможно: выдавалась стандартная ошибка Друпал типа "поле должно иметь значение". Какое-то время назад я изменил allowed number of values в field settings с 1 на 24. Теперь почему-то при сохранении ноды с незаполненным полем image никакой ошибки не выдаётся, и спокойно сохраняется нода с пустым обязательным полем. При этом поле в форме снабжено красной звёздочкой как обязательное, как и раньше.

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

она теперь не открывается даже в phpMyAdmin ;)))

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

Юзкейс: в типе материала имеются три поля: street address (дом и улица, просто текст), city и country (эти два ER на соответствующие справочники). В куче мест нужно вывести полный адрес в формате "street address, city, country", как на страницах нод, так и в разнообразных views. Сейчас это реализовано довольно бардачно: где-то вручную выводятся отдельные поля (а потом секс с css чтоб они были на одной строке и с запятыми между ними), а где-то используется token field от Display Suite. Token field в Display Suite прекрасно работает на страницах нод, но views его не видит.

Имеется сайт на восьмерке, который пока не ведется в композере (ну так вышло, виноват, сейчас не об этом). Позарез нужно поставить один компонент, который корректно ставится только композером (autoupload, PSR-4 и т.д.). Сам композер есть (от хостера), composer.json тоже какой-то есть (из дистрибутива, не соответствует реальной конфигурации).
Вопрос: если я тихонечко запущу

Трафик сайта стал стабильно превышать 50 ГБ в месяц, что у ра-дона сто́ит 1300 рублей. Сумма не то чтобы напрягает, но заставляет задуматься об оптимизации.
90% трафика составляют jpg-файлы, то есть по факту проходит мимо друпала. Суммарный объем jpg-файлов на сервере порядка 20-25 ГБ.
Возникла мысль проработать хранение всей этой мультимедии не на ра-доне, а на некоем отдельном хостинге, на мультимедию заточенном.

Жена с группой единомышленниц, задумавших уйти с некоего популярного в узких кругах тематического форума в связи с несогласием с политикой его хозяев, просят сделать им новый форум. Это не форум как приложение к некоему сайту, а именно новый сайт, на котором кроме форума ничего (пока) и не планируется. Язык исключительно русский, пользователи - тётки, далёкие от IT, функциональность - ну обычная для форума - картинки, цитирование, модерация, поиск и т.п.

Тут довольно часто люди спрашивают как удалить из Гугла/Яндекса кучу "несуществующих" страниц, которые каким-то образом оказались в поисковых базах. На это всегда следует ответ, что Гугл и Яндекс адресов никогда не выдумывают, а могут их взять только с существующих страниц. И как правило в каждом конкретном случае находится вполне рациональное объяснение тому, откуда и как эти мусорные страницы появились в базах поисковых систем.

Есть такой замечательный модуль - Entity Pager. Он позволяет со страницы ноды одним кликом перейти на "следующую" и "предыдущую" ноду. Естественно, из контекста должно быть интуитивно понятно, что такое "следующая" и "предыдущая" нода, иначе смысла нет. Порядок нод задается через специальное view. Давно использую этот модуль в десктопной версии, переход осуществляется стрелочками влево-вправо.

Имеются два сайта - прод и дев, версия ядра идентична: 8.8.5. Некоторое время назад экспортировал какие-то изменившиеся блоки и вьюхи с дева и успешно импортировал их в прод.

В десктопной версии есть сразу несколько отдельных меню, раскиданных по разным углам страницы:
- Main navigation
- User account menu
- Language switcher
- Footer

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

Офф, конечно, но описание форума говорит "применительно к размещению Drupal и не только", так что может быть ничего?
Волею судеб давным давно имею маленький хостинг на reg.ru, от которого фактически пользуюсь только почтой. Ну и там же зарегены все мои домены, что удобно.

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

Разбираюсь с Search API.
Цель: сделать человеческий поиск по сайту с осмысленными подсказками в поле поиска и красивыми результатами (список, фотогалерея, карта).
Получается нужно сделать четыре разных вьюхи для результатов (autocomplete callback, список, фотогалерея и карта). Вьюхи, само собой, достаточно разные, хотя в чем-то пересекаются. А вот как идеологически правильно разобраться с индексами, у меня нет полного понимания.

Пытаюсь настроить Content Moderation (D8) на простейший и казалось бы вполне логичный воркфлоу - не выходит каменный цветок.
На данный момент юзеры имеют право добавлять контент (unpublished), видеть собственный unpublished content и редактировать собственный unpublished content. При этом видеть чужой unpublished content им не положено. Это всё легко настроено и работает.
Теперь хочу дать возможность всем юзерам вносить правки в любой контент, но в статусе черновик/draft, чтобы никто другой кроме самого правщика и админа, этих правок не видел до их одобрения админом.