Пожалуй, апну.
Прошло 2,5 года - и, рыночек порешал. Периодически просматриваю вакансии на разного рода hh (просто мониторю) - количество вакансий друпал-разработчиков сократилось если не на порядок, то все же - в разы.
Госов среди работодателей совсем нет.
Штош, здобулы.

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

Ну, не проблема. Своим модулем по крону тянуть в private:// по ссылке файл, я бы еще проверял md5-хэш файла с предыдущим - если файл не менялся, то и незачем тратить ресурсы зря.
Затем, конвертировать его, програмно дергать фиды из модуля, подсовывая им сконвертированное.

Возможно, site.ru указан в явном виде в settings.php, или в настройках сайта, погрепайте файлы конфигураций в папке config/sync, так можно будет быстрее понять, в каких именно настройках это было указано.
Если не поможет - ищите в кастомных модулях и темах, там тоже может быть хардкод.

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

структура похожа на xml, который Feeds умеют парсить
вместо написания собственного парсера, кмк проще написать свой конвертер, что-то вроде

Тут прекрасно буквально всё. Я б включил флаг sticky, чтобы висело вверху трекера.

Это вот что

Мда. Держать БД (данные, не кеш) в ОЗУ - это прям оптимизм и отвага.

Ситуация следующая: твой виртуальный диск /dev/vda объемом 250Гб содержит один раздел /dev/vda1, который занимает весь объем диска, и создать дополнительный раздел нет возможности, поскольку для него нет свободного места.
В данной ситуации можно попробовать уменьшить размер раздела /dev/vda1, и на освободившемся на диске месте создать новый раздел /dev/vda2
Но поскольку раздел /dev/vda1 смонтирован в корень файловой системы - / то отмонтировать его так просто не получится.

VasyOK wrote: "The maximum number of messages to keep in the database log. " - в моем понимании это число, которое держать на сайте, а не очищать по крону.

Да, именно так.

VasyOK wrote: Если это действительно так, то как ограничить число записей, которое возможно вообще?

Никак, новые записи добавляются в таблицу лога, старые удаляются по крону.

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

Скорее всего - скриптом на фронте: https://api.jqueryui.com/datepicker/#method-show

Нет, никто

morgusha wrote: Так что такая ситуация мало вероятна

Закон Мерфи суров, но это закон.

morgusha wrote: Есть варианты ?

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

А если в очереди были письма, которые надо было отправить, но этого пока не произошло - на то она и очередь?

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

На вьюсах, с раскрытыми фильтрами, сайт на D7, он нагугливается за раз по тексту https://****.ru/....

например, utm-метки в урлах: site.com/something?utm_source=xxxx и site.com/something?utm_source=yyyy - абсолютно одинаковый контент, get-параметр нужен исключительно для отслеживания пользователей, в canonical указано site.com/something, и все довольны.

По обеим ссылкам действительно одинаковый контент, а точнее - сообщение, что по заданным критериям фото не найдены. Решается это заменой раскрытых фильтров на фасеты, которые предотвращают публикацию ссылок, по которым будет пустая выдача.
Как на Я.Маркете - выбрали тип кабеля "оптический", и варианты разъемов "usb" будут недоступны или вообще скрыты, поскольку нет оптических usb-кабелей.
Это удобно и пользователям - они сразу видят, какие сочетания фильтров допустимы.

В гите - кроме vendor, web/sites/default/files и остальное по мелочи, типа settings.php, robots.txt.
Хотя, в свете последних событий, безопасники требуют чтобы vendor тоже лежала в гите. И один раз так нашлась папка vendor/vendor.

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

Чужие сайты на поддержке тоже лучше добавлять в гит - чтобы потом было понятно, что было сделано до, что - после приемки сайта.
Если версия 8+, то сначала беру comoser.json и composer.lock, делаю composer install, коммит, а затем сверху заменяю файлами проекта - сразу тайное становится явным.

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

В старых версиях Drupal (< 8.2) в settings.php можно было указывать разные префиксы для разных таблиц, выглядело это так:

Чтобы bash-скрипты (*.sh) можно было запускать из консоли - у них должен быть установлен флаг x - eXecutable.
Почему у одних скриптов он есть, а у других нет - мне неизвестно, лучше спросить у разработчиков ядра.
Я этими скриптами никогда не пользовался, и обычно сбрасывал флаг x.

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