Штош. Не чокаясь.

OldWarrior wrote: Каким образом можно во views задать условие типа:

- если нет переопределения, то выводим дефолтное имя термина
- если задано переопределение для термина, то выводим его вместо дефолтного имени

вот тут: in_array('administrator', $account->getRoles())
доступ будет закрыт для пользователя с ролью администратора.

Сталкивался с чем-то подобным, когда пользовался Content Synchronization
Проблема была в том, что ID параграфов в базе идут не последовательно: какие-то параграфы удаляются, какие-то заменяются новыми, из-за этого в нумерации появляются пропуски.

zaharovrd wrote: Интересно?

да чет не очень - новый фреймворк, с непонятными перспективами, стоит ли тратить время/силы на его изучение, пригодится ли?

У вас на сайте серт самоподписанный. DevOps'ы реально крутые?

Пожалуй, апну.
Прошло 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.