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

Думаю, нужно копать форматтер/виджет вывода поля, типа "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-хостингов не предполагает разбиение выделяемого дискового пространства на несколько разделов. Обычно вам просто предоставляется преднастроенная виртуальная машина.

VasyOK wrote: Конфиги - это что?

Имеются в виду конфиги apache, php, nginx, mysql (и его базы) и т.д. Все (или почти все) можно настроить на кастомное расположение файлов конфигурации.

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

VasyOK wrote: А как разбить диск на виртуальном сервере?

Определённо разумно. Я так и делаю обычно. Только на мой взгляд конфиги лучше держать отдельно от раздела с ОС и тоже бекапить.

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

Плагины jQuery есть на этот случай.

Разрешения для каталогов и бинарников PHP, возможно, криво установлены.

Я бы в первую очередь обратил бы внимание именно на самописные модули. Кто их знает, что там кроме механики для статистики. Иной раз такие чудеса обнаруживаются.

А никаких сторонних модулей, потенциально влияющих на базовые поля формы материала, не установлено?

Скриншоты выше из FF. В Хроме в инспекторе тоже есть аналог:

А "весёлые названия" потому что включена агрегация CSS. Написал же выше, что нужно отключить, чтобы увидеть исходные имена файлов.

А инспектор в браузере что показывает? Там рядом со свойствами/правилами класса справа обычно имя CSS-файла отображается. А то может просто не тот файл правите. Только агрегацию/объединение CSS нужно отключить временно.

Кстати, есть же инспектор CSS-файлов, тоже такая отдельная вкладка в инспекторе. Там указываются все CSS-файлы.

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

Если не знаете, где именно лежит .css файл, который нужно править - откройте файл *.libraries.yml в папке темы. В ней в какой-то из библиотек будет путь к нужному css-файлу, например:

Представление на стороне админки? Если да, то нужно написать собственный небольшой модуль, объявляющий и присоединяющий к выдаче кастомные CSS-библиотеки для админской темы. Поскольку напрямую править код админской темы будет плохой идеей.

gera8774 wrote: Как я вижу реализацию: нужно создать кастомную php-страницу, подключить там нужные библиотеки и генерировать, что нужно.
Если мой вариант является верным, подскажите пожалуйста, как такую страницу правильнее будет создать.

Только не PHP-страницу, а полноценный контроллер.

Ещё одно самое поверхностное предположение: отвалился SQL-сервер. Либо не доступен по тем параметрам, которые указаны в settings.

Как ни крути, вопрос для беспомощного middle-разработчика настолько странно сформулирован (кстати, кто-нибудь понял вообще суть месседжа?), что иначе как спам не воспринимается.

ТС, ни в коем случае не ставьте Друпал, это будет "не успешная затея".

От меня? Нет, конечно.
Других дел полно, кроме как гуглить вопросы, связанные с позавчерашним днём.