Москвабад wrote:
У меня 11 версия Drupal. Там в comment.html.twig просто created, а не comment.created

Стоп, а откуда вы вообще берёте created в Twig-шаблоне комментария? У вас какой-то кастомный препроцесс записывает это значение в отдельную переменную? Потому что у меня (взял первый попавшийся проект из рабочих) в шаблоне комментария сделано так:

Москвабад wrote: Может я неправильно написал: <?php{{ created | date ('d.m.Y H:i') }}?>

Пробел между date и её аргументами совсем не нужен. Честно говоря, я бы и вокруг оператора | убрал все пробелы:

Москвабад wrote: 1. Установил чистый Drupal 11
2. Создал пользователей наделив их админскими правами
3. Заходил под именем каждого пользователя и вставлял копии комметариев

И что? Не понял смысл месседжа.

Москвабад wrote: В coment_entity_statistics у меня всего одна строка

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

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

1. У меня есть мысль, что в таблице сущности комментария (comment_field_data) помимо правки поля created всё же нужно такое же значение (или не менее) ставить и для поля changed. Иначе тут возможны коллизии. Эти два поля обычно стандартные для всех типов сущностей и присутствуют в BaseFieldDefinition во всех случаях.

Вы что-то частично наконвертили не то. Проверил через свой конвертер дат (сделал когда-то на локалке).

Москвабад wrote: 28.09.2024 - 1736307164 - на сайте отображается как 01.10.2024

1736307164 - это вообще сегодняшний день. А именно 08.01.2025 - 06:32:44

Москвабад wrote: А этот штамп - 1727969955 - вообще как 08.10.2024 отображается на сайте, хотя это 03.10.2024

1727969955 у меня конвертируется как 03.10.2024 - 18:39:15. Т.е. здесь всё верно.

Москвабад wrote: Выставляю правильный timestamp, а на сайте дата отличается на 2 дня и даже минуты не соответствуют таймстампу.

Почему вы так уверены, что выставляете правильный таймштамп?

Я было хотел посоветовать проверить PHP date.timezone (в php.ini), но поскольку вы сообщаете, что при размещении комментария через форму всё ОК, то причина не в этом.

Остаётся сомнение в "правильных" таймштампах. Как вы их генерируете/получаете?

gera8774 wrote: В принципе вроде как получилось это сделать с помощью hook_entity_presave. Но как при этом отслеживать изменения?

Ещё как вариант - запустить MariaDB 10.3.39 в Docker'е для D7 (если получится с докером справиться).

Думаю, в этой ситуации только писать свой модуль. Из "коробки" нет готового решения. Частично что-то можно нагородить рулсами-вьюсами, но соединить всё в органично работающий механизм вряд ли получится.

PS. https://www.drupal.org/project/optional_email
Модуль, судя по всему, в dev'е, но если вдруг не заработает - хотя бы можете посмотреть код, как это потенциально решается.

Потому что просто так костылить формы модулей ядра не получится.
Например, помимо атрибутов а-ля required полей формы - есть PHP-методы валидации форм (вызываются перед сабмит-методами класса), где так же производится проверка полей.

Как некуда? Есть же контакты: https://drupal.ru/about/team

Думаю, следует просто подождать, пока модераторы одобрят ваш аккаунт. Видимо, что-то когда-то меняли в политике сайта. А вы, видимо, давно не заходили.

y-vo wrote: Вопрос в том насколько это сложнее или во сколько и вообще реализуемо ли подобное?

Да реализуемо. Но писать придётся прилично. Собственно, для коммерца в случае кастомизации тоже обычно нужно писать немало.

Не потеряете. На самом деле причин потерять данные намного больше в других случаях.

Что критического в этих сообщениях, кроме того, что модули не поддерживаются? Что мешает использовать их далее?

Я думаю, что иначе, как тупо отключать внутренний/динамический кеш страниц не получится решить вопрос. Решение так себе (мягко говоря), но если прям очень важно, то можно попытаться отключить что-то из Internal Dynamic Page Cache или Internal Page Cache (скорее второе навскидку).

gera8774 wrote: Если нет, то каким образом это лучше сделать?

Через хуки hook_entity_insert / hook_entity_presave и (например) Guzzle HTTP client.

Насчёт готового - не знаю.

Популярные материалы - скорее всего блок работает на основе модуля statistics (считает кол-во просмотров каждого материала). Возможно, стоит проверить, включен ли модуль. Да и во views блока тоже стоит заглянуть - какая там ситуация.