Так уж вышло, что мне нужно по одному и тому же URL генерировать немножко разные страницы в зависимости от наличия/отсутствия некоей куки. В результате пришлось отключить Internal Page Cache, так как закэшится первый запрошенный вариант страницы и будет далее выдаваться всем независимо от куки. Сайт по мере роста базы данных стал ощутимо тормозить, и очень хочется всё же найти способ задействовать страничный кэш.

Когда-то давно ставил модуль Libraries API, явно не по своему желанию, а потому что какой-то нужный контрибный модуль его требовал. С тех пор прошли годы. Насколько я понимаю, на сегодня функциональность этого модуля полностью перекрывается композером, если только вдруг какой-нибудь старообрядческий модуль не использует Libraries API в явном виде. Ни один из установленных модулей в сегодняшних версиях не признается что требует Libraries API (что конечно не означает, что кто-то не может им пользоваться втихую :).

Есть ли у кого-нибудь реальный опыт работы с надежным хостингом, который предоставлял бы одновременно и shared хостинг для Друпала и мелкие vps для vpn и некоторых других вещей? Сервера должны быть не в РФ. Оплата рублями из РФ не обязательна, можно и зарубежной картой. Не обязан быть самым дешевым, но и не "от $160 в месяц" )

Обновил (композером) модуль. Теперь на странице Content всегда вижу такое:

При этом никаких видимых глазу выбранных/отмеченных записей нет. Если кликнуть на "Select/deselect all results", выбирает все и показывает их правильное количество (не плюс один), если кликнуть еще раз или на Clear, опять показывает загадочный 1 item.
update.php запускал, кэш чистил, из сессии выходил и снова входил.

Перешел на 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. Давно использую этот модуль в десктопной версии, переход осуществляется стрелочками влево-вправо.