Всё не так сложно.
Давном-давно известный field_group создаёт хоть табы (вертикальные-горизонтальные), хоть аккордеоны (кстати, есть и форматеры других типов, кроме этих). Как на формах (группируя поля ввода, и это основное), так и на контенте (выводе материала). Есть стыковки с Views: (field_group_views

Тогда бы как минимум отрабатывала сабмит-функция (т.е. происходила сначала перезагрузка страницы), а потом - вываливалась простыня ошибок.

1. Что в журнале Друпала после нажатия любой из этих кнопок?
2. Случаем не переключали поведение кнопок "сохранить" на AJAX - с помощью, например, какого-либо модуля?

В ЛС.

Москвабад wrote: Только вот анонимам не даёт добавлять изображения в редакторе

Насколько я помню, редактор подключается для ролей не в управлении общими разрешениями, а на странице настроек конкретного профиля редактора (basic_html, full_html, ...etc).

В любом случае не знаю, что вам предложить.

Ну, кстати, для D7 было такое: optional_mail

Для пароля, припоминаю, вроде тоже что-то было на D7.

А на D8, помню, на одном проекте сами написали модуль, делающий и первое и второе. Там регистрация/логин через СМС были, поэтому не нужно было ни то, ни другое.

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

Москвабад 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