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-разработчика настолько странно сформулирован (кстати, кто-нибудь понял вообще суть месседжа?), что иначе как спам не воспринимается.

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

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

Просто для примера работы с entity wrapper - у xandeadx'а давным-давно висит вводный манул: http://xandeadx.ru/blog/drupal/549 Хорошо показано, в чём удобство работы со значениями полей сущности через врэппер.

Там рассматриваются в основном ноды. Но принципиально этот процесс не отличается от commerce_product. Тут вам уже следует погуглить самостоятельно.

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

Строго говоря, вся эта возня с полями (или непосредственно кодом значений полей) должна быть заменена на работу с методами enity wrapper (для commerce в 7.x есть такая возможность). Тогда многое решается автоматом.

С кешем ничего не мудрили - в плане установки каких-то сторонних модулей разгона сайта?

Выключите вообще к лешему nginx, вместо него поставить Apache с модулем PHP. Хотя бы временно. Дальше уже разберётесь, нужен ли вам nginx.

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

composer.json приложите сюда - в состоянии до начала обновления (и хорошо бы второе состояние - после появления ошибки).

PS. Вы вообще-то с какой версии обновляетесь?

Ну очевидно же: для обновлённых компонентов требуется версия PHP 8.1
У вас текущая 7.4.33

Разместить обычный PHP-скрипт на old.site.by, который запрашивает site.by/node/3 и тут же отдаёт в браузер. Типа: https://stackoverflow.com/questions/6425666/how-to-proxy-another-page-in...

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

Я бы не смог настолько же внятно и лаконично объяснить этот момент. +1

haver wrote: в функции <?php buildForm(array $form, FormStateInterface $form_state) ?> можно получить аргумент через
<?php $arg = $form_state->getBuildInfo()['args'][0]; ?>

Почему так сложно? Обычно принимаемые параметры можно перечислить в определении ::buildForm, типа: