Номер будет присвоен после записи в базу, т.е. уже после сабмита формы, и он не обнуляется раз в год.
Но ход мысли правльный.
Дело в т.н. race condition - два пользователя сабмитят форму с небольшим интервалом по времени, и если присваивать номер на фронте, то он продублируется в их отправлениях.
Лучше поручить друпалу разруливать уникальность номеров.
Т.е., я предполагаю какой-то такой алгоритм:

С двух слешей надо начинать урл - будет работать и так и так.
//static-maps.yandex.ru/...

Conditional Fields

Inline Entity Form должен подойти

похоже на опечатку bottom

На страницах термина таксономии в body добавляются классы, среди них есть и id термина, и машинное имя словаря.

Вот так еще можно:
mysqldump | sed 's/2019/2020' | mysql

В семёрке? Вряд ли проще. Его сначала надо прикрутить к семёрке.

Я так понимаю, что автору нужно что-то вроде таких ссылок.

Странно. А кеш как сбрасывали?

нет, остальное все так же.
Возможно, приоритет у названий шаблонов неверный.
Попробуйте
$vars['theme_hook_suggestions'] = array('html__landing__page');

О, это маразм в квадрате.
Вот так, например, создается payment_transaction:

С таким может бороться и сам drupal, но конечно эффективнее убрать с него нагрузку после какой-нибудь попытки.

fail2ban умеет экспоненциально увеличивать время блокировки

некоторым удавалось и 5хх возвращать

project и datestamp тоже закомментировал

надо курить маны к wget, да в общем-то, какая там нагрузка

/usr/bin/wget -r -l 0 --spider --delete-after -P /tmp http(s)://site.com - проходит по всем встретившимся на

bumble wrote:

Все это заведомо приводит к созданию "хрупкой" системы, и кроме прочего, привязываясь к другому компоненту, мы получаем ряд неудобств. А зачем? Ради экономии кода?

Нода - единица контента, и для дисплея продукта она подходит полностью, что в общем-то и подтверждается практикой commerce 1.
Сам физический продукт - да, имеет мало общего с контентом, и его перенос в отдельную сущность полностью оправдан. Но создание на ровном месте еще одной сущности, дублирующей функционал контента - ничем не обоснован.

завязывание на другие компоненты является unix-way, а не плохой практикой, а тут колхозят explorer.exe

Каталог - это базовый функционал интернет-магазина. Разумеется, если речь не идет об LP с 2-3 товарами.
Как правило, необходимость добавления магазина возникает в b2b: сделали сайт-каталог продукции, спустя время, если сайтом занимались, приходит понимание, что можно увеличить его отдачу, добавив функционал формирования и оформления заказа.
В первую очередь, это касается дилерских продаж: вывели номенклатуру списком, фильтры-автокомплиты, и сиди себе набивай заказ.

Ну, проект всегда следует строить с прицелом на дальнейшее масштабирование.

Кстати, это первое что мне не понравилось в коммерце2.
В первом можно было создать сайт-каталог из нод, и со временем расширить его до магазина, сделав этот тип нод дисплеем.
В восьмерке такое масштабирование невозможно - придется мигрировать ноды в продукты, с переносом путей, метатегов, отзывов-комментариев и прочих файвстаров.
Чего ради это было сделано? Чтобы юзеры не путались между продуктом и дисплеем? Сомнительное решение.

Вот, кстати, отличный пример анти-юзабилити: http://mta-industry.ru/service#tech-support-entityform-edit-form