Fi1osof

Если это критично, то лучше плагин написать на инициализацию MODX и все.

Попробуйте

$s = $modx->prepare('SET SESSION group_concat_max_len = 1000000;');
$s->execute();

Странная позиция: я не пользуюсь, поэтому скорее всего и вовсе никто не пользуется.
Не достаточно ли просто посмотреть статистику на гитхабе? У mocha 18+ килозвезд и используется в 850+ килопроектах. Jest итого больше.

За себя скажу: не часто, но пользуюсь. И бывает крайне полезно. В основном использую для проверки корректности конечного рендеринга. А то бывает есть несколько компонентов и вроде все работает. А потом что-то поправил, и оказывается, что где-то что-то сломалось, но логика такая разветвленная, что сразу и не замечаешь. А так тесты запустил и все.

Еще личный кейс: на одном проекте у клиента используется список грейдом (отличительные свойства товаров), и надо было реализовать сравнение (первоначальная оценка и итоговая, надо было автоматом решать выше грейд или ниже). Но это не просто числовое свойство, а число-буквенное, которое не сравнишь по простой логике. И здесь так же было целесообразно использовать тесты.

Ну а самые объемные тесты, которые я видел в сторонних проектах, это наверно в knex: github.com/tgriesser/knex/tree/master/test/unit
и в sharp: github.com/lovell/sharp/tree/master/test/unit

Без ssh я больше ничем не помогу.

Что-то очень сомневаюсь, что у вас это должно работать. На сколько я понимаю, последовательность соединений такая:
Браузер (JS) -> nginx -> js на порту 4000 -> MODX. И вы ожидаете, что js просто так возьмет и пробросит кукисы до MODX? Просто так он не будет ничего пробрасывать.

P.S. на каждом этапе проброса соединения дебажьте и смотрите, чтобы были кукисы и отправлялись дальше.

И почему проксирование на proxy_pass site.com:4000; идет? Не думаю, что у вас на порту 4000 MODX крутится. Вероятней всего у вас там JS-сервис, а оттуда вы пытаетесь вызывать php средствами js (проксируя запрос). Так?

У вас там конкретно site.com прописано, или все-таки это замена и там реальный домен прописан?

Так долго будем разбираться. Шлите в личку ssh и домен сайта, буду посмотреть. Иначе шаманство получается.

Да, «FILE» — это флаг. А логи у вас странные. Такое ощущение, что у вас php выполняется консольно, а не как веб-служба. И соответственно никакие заголовки вам туда нужные не передаются. Поэтому у вас и массив кукисов пустой.

И еще момент: Если указываете proxy_pass site.com:4000;, то в /etc/hosts пропишите 127.0.0.1 site.com, чтобы при проксировании точно сразу на локальный хост запрос летел, а не через внешний ip. Это тоже логику имеет. В моем-то примере не на site.com проксирование прописано, а на локалхост.
proxy_pass localhost:4000;

А где хост? У меня вот так:

(
    [USER] => www-data
    [HOME] => /var/www
    [FCGI_ROLE] => RESPONDER
    [SCRIPT_FILENAME] => /var/www/vhosts/www.site.ru/manager/components/console/connectors/console.php
    [QUERY_STRING] => 
    [REQUEST_METHOD] => POST
    [CONTENT_TYPE] => application/x-www-form-urlencoded; charset=UTF-8
    [CONTENT_LENGTH] => 265
    [SCRIPT_NAME] => /manager/components/console/connectors/console.php
    [REQUEST_URI] => /manager/components/console/connectors/console.php
    [DOCUMENT_URI] => /manager/components/console/connectors/console.php
    [DOCUMENT_ROOT] => /var/www/vhosts/www.site.ru
    [SERVER_PROTOCOL] => HTTP/1.1
    [GATEWAY_INTERFACE] => CGI/1.1
    [SERVER_SOFTWARE] => nginx/1.4.6
    [REMOTE_ADDR] => xxx
    [REMOTE_PORT] => 46986
    [SERVER_ADDR] => xxx
    [SERVER_PORT] => 443
    [SERVER_NAME] => www.site.ru
    [HTTPS] => on
    [REDIRECT_STATUS] => 200
    [HTTP_HOST] => www.site.ru
    [HTTP_CONNECTION] => keep-alive
    [HTTP_CONTENT_LENGTH] => 265
    [HTTP_ORIGIN] => https://www.site.ru
    [HTTP_X_REQUESTED_WITH] => XMLHttpRequest
    [HTTP_MODAUTH] => xxx
    [HTTP_USER_AGENT] => xxx
    [HTTP_CONTENT_TYPE] => application/x-www-form-urlencoded; charset=UTF-8
    [HTTP_ACCEPT] => */*
    [HTTP_REFERER] => https://www.site.ru/manager/?a=index&namespace=console
    [HTTP_ACCEPT_ENCODING] => gzip, deflate, br
    [HTTP_ACCEPT_LANGUAGE] => ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7,fr;q=0.6,it;q=0.5,cy;q=0.4,la;q=0.3,zh-CN;q=0.2,zh;q=0.1
    [HTTP_COOKIE] => xxxxxxxxxxxxxxxxxx
    [PHP_SELF] => /manager/components/console/connectors/console.php
    [REQUEST_TIME_FLOAT] => 1561467977.3899
    [REQUEST_TIME] => 1561467977
)

ОК. Но все же, дописываем в файл $modx->log(1, print_r($_SERVER, 1), «FILE»); и смотрим логи, какие заголовки прилетают.
Полезно еще дописать $modx->log(1, print_r($_COOKIE, 1), «FILE»); чтобы и куки посмотреть сразу.

Вы ws-запросы от браузера до MODX проксируете на уровне nginx? Может вы в прокси не передаете реальный хост сайта? В своем файле допишите $modx->log(1, print_r($_SERVER, 1), «FILE»); и потом после запроса в логах MODX в админке посмотрите что у вас там прилетает. Правильные ли SERVER_NAME, HTTP_HOST, HTTP_ORIGIN и т.п. прилетают? А то велика вероятность что в запросе-то у вас кукисы передаются нормально, но до MODX прилетает другой хост и он не принимает куки.

Помню. Но он не проще и не универсальней, потому что будет срабатывать только на расширенный тип ресурса. А плагин на обновление будет срабатывать на обновление любых типов ресурсов (имеется ввиду документов).

Не за что!

Нет, обходных моментов нативных нет. И да, MODX перетирает при обновлении все ТВшки при передаче tvs => 1. То есть если передан tvs => 1, то он пытается обновить все TVшки документа и если для имеющейся TVшки не было получено новое значение, то она стирается.
Это один из самых неприятных моментов в MODX, мешающих разработке кастомных интерфейсов для обновления ресурсов, так как при передаче хотя бы одного параметра надо передавать все имеющиеся. А это не только неудобно, но и не секурно (ты такой типа через управление формами скрываешь отдельные TVшки, чтобы другие манагеры их не видели и не меняли, а они тупо в hidden-полях на странице находятся и мало того, что их можно прочитать, так их еще и изменить можно (но это не точно, не помню проверяет ли он права на доступ к ТВшке при обновлении, но по-моему нет)). На мой взгляд это дичайшая дичь.

P.S. как вариант: если это ваш какой-то кастомный компонент, то можете не передавать tvs => 1, а в плагине на обновление ресурса обновлять ТВшку через $object->setTVValue($id/name, $value)

Андрей, привет!
Не могу сказать ничего однозначного на счет связки с nuxt+vue в будущем. Скорее всего нет. Но и обратного утверждать не буду.

Всем привет!

Если кому интересно, вот здесь подробней написал о разрабатываемой prisma-cms: habr.com/ru/post/448982/

РЕШЕНИЕ: в стиле «сам спросил, сам ответил»:

Решение не очень годное. Для вашего случая больше вот это подойдет: modx.pro/development/7236
И если правильно прочитаете написанное, сможете и REGEXP вызвать, но бегать регуляркой по такой строке — не самое правильное решение.

Вы в личку пришлите доступ к вашей странице, а то там по логину-паролю судя по всему доступ, я не вижу самих запросов. Вообще у вас JS должен идти на порт 2025 (и там нормально доступен), а на /api/ должны только ws-запросы идти. Но даже если он и скрипты пытается получить по адресу /api/, вам просто надо запустить в обычном режиме и посмотреть по какому адресу эти скрипты получаются, а потом настроить и для них проксирование. Правила проксирования можно настроить отдельно для разных адресов, типов запросов/файлов и т.п.
В моем конфиге полезного больше особо ничего нет, но вот еще кусок, где остальные запросы уходят на основную часть сайта:

location / {

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout 36000;

        proxy_set_header Host $server_name ;
        proxy_set_header X-Real-IP $remote_addr ;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP 127.0.0.1 ;
 

        location ~ ^/.+ {
 

            if (!-e $request_filename) {
                proxy_pass http://localhost:3000;
            }
 
        }
        
        proxy_pass http://localhost:3000;

    }