А вот это уже какая-то странная настройка преобразовывать i в em. Наверное b в strong тоже переделывает. В разрешённых тэгах есть?

Проблема в том, что вы вставляете пустой тэг, а CKEditor пустые тэги удаляет, независимо от никаких настроек. Но выход довольно прост:

Можно написать свой процессор, который повырезает все эти штуки перед индексом.

А после сохранения получилось переиндексировать?

а если эту ноду открыть на редактирование и сохранить, ошибка есть?

Заменить галочку на список + Rules? Что-то не похоже на упрощение

Проще всего через шаблон:

Тут одно из двух, либо на продакшене не та кодировка базы, либо туда залили дамп не в той кодировке. Такое бывает, что обе базы в utf8mv4, но при экспорте выбирают обычную кодировку и потом всё ломается

В журнале нет ошибок, что что-то не удалось проиндексировать?

Не видя код, очень тяжело что-то посоветовать.

Это потому что в Entity reference полях нет свойства value. Если нужно название сущности, на которую ссылаются, то обращаться нужно так:

drupalSettings - это просто объект в javascript. Имя модуля добавляют только с той целью, чтобы ключи сеттингов не пересекались, а то ведь случайно можно написать такой ключ, который перепишет настройки другого модуля и что-нибудь сломается. То есть имя модуля желательно конечно добавить, но
это не является обязательным.

Через drupalSettings.
Например в php пишем

Проблема в том, то в этом огромном диффе никто не будет разбираться. Поэтому если в композере что-то пошло не так, например, не применился патч, этого никто не увидит. В итоге версии в composer.json и composer.lock не будут соответствовать реально установленным.
Если же работать по нормальному - без вендоров, ядра и контриба в гите, то в случае непредвиденности на проде всё теми же стандартными средствами гита можно откатить composer.json и composer.lock на другую версию и выполнить composer install.

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

Там же по ссылке серым по белому написано, что в переменной контекст есть ключ entity, в котором находится сущность.

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

Контриб и ядро в гите - это удобно до тех пор, пока на проекте не появляется код ревью.

Хорошая статья! Лично для меня, пожалуй, ничего нового, но многим будет полезно. Единственный вопрос, который остался за кадром - это хранить ли скомпилированные стили и скрипты темы. Лично на мой взгляд, если над проектом работает сразу несколько разработчиков, то лучше не хранить, т.к. замучаешься мерджить изменения в этих файлах. А если на проекте всего один разработчик, либо всего один разработчик работает с темой, то удобнее и проще будет всё же хранить стили и скрипты в репе.

Во-первых, почему бы просто не удалить токен [node:summary], если он не нужен?
Во-вторых, почему бы не использовать hook_metatags_alter?

Если блок с чекбоксами неудобен, надо сначала определиться, что будет удобно. Кроме того, в фасетах по умолчанию есть настройка, чтобы изначально показывать часть опций, а остальные скрыть под кнопкой "показать ещё". Плюс есть сортировка опций. Можно отсортировать их по количеству результатов, тогда под "показать ещё" уйдут самые редкие опции.

Да, именно так. Есть ещё модуль Search API Autocomplete, с ним вообще красиво)