width=320, ...

Не надо 2 вьюпорта, одного достаточно:
<meta name="viewport" content="width=device-width, minimum-scale=1.0, initial-scale=1.0">

и user-scalable=no - лучше не надо

А если:
1. JS_LIBRARY вместо JS_DEFAULT
2. Объединение файлов JavaScript (чекбокс)
3. Очистить кэш

Странная логика.

Ведь если views теперь часть ядра и если так - https://www.drupal.org/project/drupal/issues/1979468

То ты утверждаешь, что использовать js под эту задачу будет правильным решением?

Какое еще "хамство". Тебя уже не раз пинали за дело (бесполезные/вредные советы и низкий КПД).
Тут уже глупо разыгрывать карту с "обиженкой" на "хамское поведение".

P.S. Вот тебе то откуда знать, что я знаю и что умею?

Но ведь можно подсветить ссылку через jQuery.

А это не костыль что ли? С учетом того, что раньше l() автоматом добавлял класс на текущую страницу.

Вот я бы твой тезис, полноценно к тебе применил...
Топик темы "Связанные (зависимые) поля в форме", а ты пользователя на параграфы отправляешь.
Вот гарантирую, что после твоего "совета", пользователь тебя спросит "А почему не работает как надо?". Ты же его тупо проигноришь.

По сабжу:

Я вам искренне завидую, что вам не приходилось с этим сталкиваться.
Модуль ниже.

Оффтоп: дайте icq'шный смайлик (башкой бьется об стену).

Внимательней смотрите, там есть для 8ки.

Во, через модуль еще костыльнуть можно:
https://www.drupal.org/project/link_trail_by_path

Как обычно, патчи:
https://www.drupal.org/project/drupal/issues/2652000

P.S. Ну и костыли под кэш, по необходимости.

Ну и самое главное по сабжу:

Если проект становится удачным, имеет шикарный траффик. Он автоматом отцепляется от мультисайтинга. Живет своей инфраструктурой, поддержкой, обслуживанием, финансами и т.д. Это аксиома.

Давайте от "обратного":

Я сильно сомневаюсь, что вы сейчас найдете такие проблемы "БД перегружена, сайт крашится/сервак не справляется".
Не спорю, могут быть сайты на вордпресс, которые загоняют проц в 100%. Либо проекты, жрущие оперативку хлеще винды10 с хромом (100+ вкладок)... Но это уже совсем другие истории.

Если что-то и услышите, то не факт что это будет применимо именно к вам.

По своему опыту: свои серваки, все летает. Если вдруг станет не хватать какой-то железки (ssd, оперативки)
- куплю, они копейки стоят.

Конкретно кейс.

Вы опасаетесь чрезмерной нагрузки на БД? Забудьте, времена уже давно не те.

Что Вы думаете о решении проблемы

В чем конкретно проблема?

А так, 4 пункт наиболее приемлемый, если нужно что-то расшарить. Иногда DA - профитней. От кейса отталкиваться нужно.

Параграфы разве умеют dynamic dependency по полям/значениям?
Или опять из серии "пальцем в небо"?

"отзывы" являются "синонимом" "комментариев"

Правильно. Кого волнует, что бывают кейсы "комментарии и отзывы на одной странице/товаре"...
Че они там понимают в своих интернет-магазинах...

Истина. Как минимум надо будет менять слово "комментарий" на "отзыв".

P.S. Предвижу коммент "Переводы и вообще не надо ничего кодить" )))

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

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

Обгоню тебя скорее всего. Сайт свежий, еще на деве, после переноса, 32к товаров, в каждом тизере форма корзины.

Читер! Накрутка!

База по размеру ни о чем.

Вопрос решен чисткой таблиц с cache.

Возвращайтесь через неделю, как таблицы заполнятся.

P.S. Учитесь, как надо:

Этот заголовок генерируемый на форму в зависимости от того что заказывает пользователь.

Какой нафиг заголовок?

Так ты определился или нет?

Если знаете как его сделать адаптивным с многострочностью - пожалуйста.

display: block;
width: 100%;
height: auto;

onsubmit прямо же на форму ставится, а не на кнопку

😊 - когда увидел годный топик на 1 апреля
😩 - когда прочитал ник автора