JastaFly

Решил проблему подправив конфиг php.ini под memcached:

session.save_handler = "memcached"
session.save_path="127.0.0.1:11212"
memcached.sess_locking = Off

Решил проблему добавив прослушивание 443 порта в конфиге nginx:
listen 443 ssl default_server;
Затем сгенерировал SSL, сертификат:

openssl genrsa -out rootCA.key 2048
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem

и потом прописал его в том-же конфиге:

ssl_certificate      /etc/nginx/ssh/rootCA.pem;
ssl_certificate_key  /etc/nginx/ssh/rootCA.key;

После перезагрузки Nginx сайт стал открываться по протоколу https

Ну да, webpack-svgstore-plugin устарел, заменил его на svg-sprite-loader от JetBrains

Помогло добавления пакета с пресетами в package.json:
"@babel/preset-env": "^7.26.0",
В webpack.config.js замени старые пресеты babel-preset-env:

{
                test: /\.js$/,
                exclude: /(node_modules|vendor)/,
                loader: 'babel-loader',
                query: {
                    cacheDirectory: true,
                    presets: ['babel-preset-env']
                }
            },

На новые @babel/preset-env:

{
                test: /\.js$/,
                exclude: /(node_modules|vendor)/,
                loader: 'babel-loader',
                options: {
                    cacheDirectory: true,
                    presets: ['@babel/preset-env']
                }
            }

Решить проблему помогла замена экспорта модулей с:
exports.sliders = sliders
На:

export {
    sliders,
    .....
}

В главном JS файле сборки (Webpack 5)

Починить сборку помогло удаление плагина postcss-preset-env из конфига вебпака

Проблему решить помогло смена версий пакетов:

"postcss": "^8.4.32",
    "postcss-loader": "^7.3.4",
    "postcss-preset-env": "^9.3.0",

Спасибо szQocks за совет)

Проблема была в том что PHP, в дефолтных репозиториях моей ОС (в данном случае это была Alma Linux), PHP шёл без модуля для апач и от того в директории с модулями: /etc/httpd/modules отсутствовал модуль libphp.so. Чтобы решить проблему я, удалил установленный пакет PHP:
dnf remove php
Затем добавил репозиторий реми:

sudo dnf -y install http://rpms.remirepo.net/enterprise/remi-release-9.rpm -y

Сбросил старый модуль с PHP:
sudo dnf module reset php -y
И установил новый PHP из репозитория реми:
sudo dnf module install php:remi-8.1
Более подробная инструкция. Только репозиторий реми там 8-й версии, в моем случае нужен был 9-й (в своём примере я это подправил)

В итоге смогу получить результат на адресе: 192.168.0.164 (обычный нешифрованный http + IP адрес через который я подрубался по SSH. Если использовать https, то ничего не выйдет). Данный адрес я нашел на виртуалке по команде ifconfig:

Ранее не удавалось подрубиться по http из-за ошибки в PHP скрипте, которую смог найти в error логе Nginx

В итоге остановился на варианте с созданием нового свойства для инфоблка, так как особых альтернатив нет, а все прочие варианты только усложняют логику

Проблема была в отсутствующем поле UF_SORT у проблемного HighLoad блока. Написал миграцию добавляющую её:

namespace Sprint\Migration;

class AddSortFieldInHighloadBlock20240926165615 extends Version
{
    protected $author = 'https://github.com/JastaFly';
    protected $description = 'Добавляет поле сортировки в Highload-блок';
    protected $moduleVersion = '4.12.6';
    private HelperManager $helperManager;
    private int $hlBlockManufacturersId;

    /**
     * @throws Exceptions\HelperException
     * @return bool|void
     */
    public function __construct()
    {
        $this->helperManager = $this->getHelperManager();
        $this->hlBlockManufacturersId = $this->helperManager->Hlblock()->getHlblockIdIfExists(
            'highloadBlockName'
        );
    }

    public function up()
    {
        $this->helperManager->Hlblock()->saveField(
            $this->hlBlockManufacturersId,
            [
                'FIELD_NAME' => 'UF_SORT',
                'USER_TYPE_ID' => 'double',
                'XML_ID' => '',
                'SORT' => '100',
                'MULTIPLE' => 'N',
                'MANDATORY' => 'N',
                'SHOW_FILTER' => 'N',
                'SHOW_IN_LIST' => 'Y',
                'EDIT_IN_LIST' => 'Y',
                'IS_SEARCHABLE' => 'N',
                'SETTINGS' => [
                    'PRECISION' => 4,
                    'SIZE' => 20,
                    'MIN_VALUE' => 0.0,
                    'MAX_VALUE' => 0.0,
                    'DEFAULT_VALUE' => NULL,
                ],
                'EDIT_FORM_LABEL' => ['en' => 'Sorting', 'ru' => 'Сортировка'],
                'LIST_COLUMN_LABEL' => ['en' => 'Sorting', 'ru' => 'Сортировка'],
                'LIST_FILTER_LABEL' => ['en' => 'Sorting', 'ru' => 'Сортировка'],
                'ERROR_MESSAGE' => ['en' => 'Sorting', 'ru' => 'Сортировка'],
                'HELP_MESSAGE' => ['en' => 'Sorting', 'ru' => 'Сортировка']
            ]
        );
    }

    public function down()
    {
        $deleteResult = $this->helperManager->Hlblock()->deleteField($this->hlBlockManufacturersId, 'UF_SORT');

        if ($deleteResult) {
            $this->outSuccess('Всё ok. Свойство сортировки добавлено');
        } else {
            $this->outError('Не ok. Свойство сортировки не добавлено');
        }
    }
}

В итоге написал свою либу на PHP, на основе данного обсуждения
composer require jasta-fly/phpdfer

Разобрался. Решение оказалось до банальности простым, софт который я использовал внутри exec() был установлен в контейнера с сервером, а вот в контейнере с PHP, нет. Установил его и там и всё заработало. Спасибо всем за помощь)

В итоге переписал всё с использованием библиотеки DOMDocument где можно нормально работать с CDATA. Спасибо огромное IvanU7n за подсказку)

В итоге это оказалось косяком разработчиков модуля Сотбит: SEO умного фильтра – мета-теги, заголовки, карта сайта. Пофиксилось удалением хуков на индексацию которые вешаем данный модуль при установке:

Данные хуки нужны чтобы на сайте работал поиск по SEOшным тайтлам но эта фича нередко ломает индексацию на сайте и по сути является маловостребованной. Может в будущих версиях баг пофиксят, но пока только так

Разобрался, лимит из конфига перебивался в файле local/php_interface/init.php:
ini_set('memory_limit', '4096M');
Увеличил там значение на 2Гб и всё заработало.
P.S. Сайт на Битриксе

Решение оказалось до боли простым, статус заказа не менялся из-за базовой авторизации на сайте где тестировался новый модуль

В итоге я выбрал свой, хоть и костыльный но зато быстрый метод, а именно повесил обработчик на событие формирования меню:

AddEventHandler('main', 'OnBuildGlobalMenu', 'deleteForbiddenMenuItems', 200);

И тупо удалить всё ненужное из массива с элементами меню:

function deleteForbiddenMenuItems(&$aGlobalMenu)
{
    unset(
        $aGlobalMenu['global_menu_sitecore'],
        $aGlobalMenu['global_menu_custom_core'],
        $aGlobalMenu['global_menu_content'],
        $aGlobalMenu['global_menu_marketing'],
        $aGlobalMenu['global_menu_services'],
        $aGlobalMenu['global_menu_marketplace'],
        $aGlobalMenu['global_menu_crm_site_master']
    );
}

Правда тогда появляется сайд эффект в виде кнопок заглушек со стрелочками в главном меню. Их я скрыл добавив в админку следующий CSS:

.adm- {
    display: none;
}

Спасибо всем за помощь)

Решил проблему. Оказалось что Centos почему-то плохо дружит с нодой установленной через nvm, установил нужную версию другим способом и ошибка ушла