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

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

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

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

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

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

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

Ну, следует почитать вывод композера ДО этого сообщения и попытаться понять, что ему не нравится.

Кроме того, composer why ... - частый ответ на почти все проблемы установки.

В вашем случае:

composer why 'drupal/commerce:^2.39'

У меня ощущение, что у вас какая-то путаница с путями и по какой-то причине добавленный в репо файл не попадает в рабочее дерево. Т.е. git add . не обнаруживает изменений в репозитории.

VasyOK wrote: create mode 100644 src/Feeds/Target/DateRecur.php

Это и есть ваш добавленный файл?

В "Полном HTML" - не нужно (тут я механически ошибся выше), однако только если в нём отключена соответствующая опция:

1. Какой путь (относительно директории, в которой выполняется git) до добавленных файлов?

2. Так пробовали:

git add ./

или

git add --all .

Тут --all - указание принудительно обновить рабочее дерево

Комментатор выше, видимо, имел в виду что нужно настраивать текстовый формат ввода, используемый в вашем поле. У каждого формата, поддерживающего HTML ("Ограниченный HTML", "Полный HTML и т.п.) есть перечень разрешённых тегов. Вот его и нужно отредактировать, добавив нужный вам тег.

VasyOK wrote: Результат - пустой файл.

Пустой файл чего именно? .patch или тот, что вы добавили в репо?
Васёк, ну чуть детальнее и точнее можно описывать? Я уже старый, мне телепатия не поддаётся

По логике, новый/добавляемый в патч файл сначала нужно традиционно добавить в текущий локальный репозиторий гита, т.е. закоммитить. После этого уже выгружать diff.

То есть, у вас сложность не с git'ом и не с composer'ом, а с форматом diff?

Делать патчинг через композер.

https://vazcell.com/blog/how-apply-patch-drupal-9-and-drupal-10-composer
https://gorannikolovski.com/blog/how-to-apply-a-patch-in-drupal

Ну а в журнале-то что?
Почему часто забывают банально проверить журнал?

Думаю, нужно копать форматтер/виджет вывода поля, типа "Rendered attribute" (как для поля атрибута типа Color).

В 7-ке вообще-то были отдельные модули типа commerce_fancy_attributes и commerce_fancy_image_attributes, однако сейчас это всё должно быть "в коробке" Commerce.

Не совсем понятно, в чём сложность вывести картинки вариации. Вы, видимо, задумали сделать картинки кликабельными (типа вместо опций радиокнопок)и именно с этим не можете справиться?

Ну, получилось - и хорошо. Однако, это частный случай с кастомным модулем, где такой финт ещё можно применить. Во всех остальных случаях (да и для практики полезно) - лучше всё же обновления схемы БД делать через слой Drupal API. Ещё одно преимущество этого метода - в случае чего с помощью API можно откатить применённое ранее обновление схемы БД модуля по его уникальному номеру.

Да, лучше в .install файле. В том смысле, что будет избирательная загрузка тела кода хука только на операциях инсталляции/обновления. Ещё избирательнее - перетащить тело хука hook_update_N в отдельный статический метод какого-нить уникального класса вроде HookUpdateN. Особенно если хуков hook_update_N будет много - для каждого можно запилить отдельный класс с единственным статическим методом. Это ну прям вообще песня.

Журналы/логи Друпала и веб-сервера - поистине магическая вещь.

1. Записи никуда не денутся, но лучше забекапиться перед обновлением.

2. Да, вставлять в код модуля (*.module).

3. После добавления кода выполнить обновление, типа drush updb или через UI Друпала.

jura12 wrote: что с этим делать? как написать патч к этой таблице в schema?

1. Добавить hook_update_NNN ()
(https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Extension...)

2. В нём добавить новое поле для primary key (или выбрать уже имеющееся, но с уникальным значением для каждого ряда).

3. Установить для этого поля признак primary key, типа:

Тут скорее возникает вопрос, как именно создаётся термин - программно (из кастомного кода) или через UI. Если программно, то проверять, где пропущен вызов. Если через UI (т.е. в управлении терминами таксономии) - возможно действительно имеет смысл посмотреть, что не так со словарём. Однако, маловероятно на мой взгляд, что с ним внезапно (сами по себе) возникли какие-то проблемы и, скорее всего, пересохранение его не даст эффекта.

Так написано же: Field 'vid' doesn't have a default value.

vid означает vocabulary id, т.е. пропущен ID словаря, для которого создаётся термин.
Где-то в ваших вызовах забыли его указать.

Я вообще-то выше предполагал, что речь идёт о локальном сервере, для разработки. На VDS этот финт вряд ли прокатит, поскольку для создания разделов действительно нужно освобождать необходимое место и кроме того, возможно, загружаться с внешнего загрузочного диска. Доступа же к внешним носителям, на VDS, как правило у вас нет.

Вообще - по-моему политика большинства VDS-хостингов не предполагает разбиение выделяемого дискового пространства на несколько разделов. Обычно вам просто предоставляется преднастроенная виртуальная машина.