Странная позиция: я не пользуюсь, поэтому скорее всего и вовсе никто не пользуется.
Не достаточно ли просто посмотреть статистику на гитхабе? У mocha 18+ килозвезд и используется в 850+ килопроектах. Jest итого больше.
За себя скажу: не часто, но пользуюсь. И бывает крайне полезно. В основном использую для проверки корректности конечного рендеринга. А то бывает есть несколько компонентов и вроде все работает. А потом что-то поправил, и оказывается, что где-то что-то сломалось, но логика такая разветвленная, что сразу и не замечаешь. А так тесты запустил и все.
Еще личный кейс: на одном проекте у клиента используется список грейдом (отличительные свойства товаров), и надо было реализовать сравнение (первоначальная оценка и итоговая, надо было автоматом решать выше грейд или ниже). Но это не просто числовое свойство, а число-буквенное, которое не сравнишь по простой логике. И здесь так же было целесообразно использовать тесты.
Что-то очень сомневаюсь, что у вас это должно работать. На сколько я понимаю, последовательность соединений такая:
Браузер (JS) -> nginx -> js на порту 4000 -> MODX. И вы ожидаете, что js просто так возьмет и пробросит кукисы до MODX? Просто так он не будет ничего пробрасывать.
P.S. на каждом этапе проброса соединения дебажьте и смотрите, чтобы были кукисы и отправлялись дальше.
И почему проксирование на proxy_pass site.com:4000; идет? Не думаю, что у вас на порту 4000 MODX крутится. Вероятней всего у вас там JS-сервис, а оттуда вы пытаетесь вызывать php средствами js (проксируя запрос). Так?
Да, «FILE» — это флаг. А логи у вас странные. Такое ощущение, что у вас php выполняется консольно, а не как веб-служба. И соответственно никакие заголовки вам туда нужные не передаются. Поэтому у вас и массив кукисов пустой.
И еще момент: Если указываете proxy_pass site.com:4000;, то в /etc/hosts пропишите 127.0.0.1 site.com, чтобы при проксировании точно сразу на локальный хост запрос летел, а не через внешний ip. Это тоже логику имеет. В моем-то примере не на site.com проксирование прописано, а на локалхост.
proxy_pass localhost:4000;
ОК. Но все же, дописываем в файл $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)
Решение не очень годное. Для вашего случая больше вот это подойдет: modx.pro/development/7236
И если правильно прочитаете написанное, сможете и REGEXP вызвать, но бегать регуляркой по такой строке — не самое правильное решение.
Вы в личку пришлите доступ к вашей странице, а то там по логину-паролю судя по всему доступ, я не вижу самих запросов. Вообще у вас JS должен идти на порт 2025 (и там нормально доступен), а на /api/ должны только ws-запросы идти. Но даже если он и скрипты пытается получить по адресу /api/, вам просто надо запустить в обычном режиме и посмотреть по какому адресу эти скрипты получаются, а потом настроить и для них проксирование. Правила проксирования можно настроить отдельно для разных адресов, типов запросов/файлов и т.п.
В моем конфиге полезного больше особо ничего нет, но вот еще кусок, где остальные запросы уходят на основную часть сайта:
Не достаточно ли просто посмотреть статистику на гитхабе? У mocha 18+ килозвезд и используется в 850+ килопроектах. Jest итого больше.
За себя скажу: не часто, но пользуюсь. И бывает крайне полезно. В основном использую для проверки корректности конечного рендеринга. А то бывает есть несколько компонентов и вроде все работает. А потом что-то поправил, и оказывается, что где-то что-то сломалось, но логика такая разветвленная, что сразу и не замечаешь. А так тесты запустил и все.
Еще личный кейс: на одном проекте у клиента используется список грейдом (отличительные свойства товаров), и надо было реализовать сравнение (первоначальная оценка и итоговая, надо было автоматом решать выше грейд или ниже). Но это не просто числовое свойство, а число-буквенное, которое не сравнишь по простой логике. И здесь так же было целесообразно использовать тесты.
Ну а самые объемные тесты, которые я видел в сторонних проектах, это наверно в knex: github.com/tgriesser/knex/tree/master/test/unit
и в sharp: github.com/lovell/sharp/tree/master/test/unit
Браузер (JS) -> nginx -> js на порту 4000 -> MODX. И вы ожидаете, что js просто так возьмет и пробросит кукисы до MODX? Просто так он не будет ничего пробрасывать.
P.S. на каждом этапе проброса соединения дебажьте и смотрите, чтобы были кукисы и отправлялись дальше.
proxy_pass localhost:4000;
Полезно еще дописать $modx->log(1, print_r($_COOKIE, 1), «FILE»); чтобы и куки посмотреть сразу.
Это один из самых неприятных моментов в MODX, мешающих разработке кастомных интерфейсов для обновления ресурсов, так как при передаче хотя бы одного параметра надо передавать все имеющиеся. А это не только неудобно, но и не секурно (ты такой типа через управление формами скрываешь отдельные TVшки, чтобы другие манагеры их не видели и не меняли, а они тупо в hidden-полях на странице находятся и мало того, что их можно прочитать, так их еще и изменить можно (но это не точно, не помню проверяет ли он права на доступ к ТВшке при обновлении, но по-моему нет)). На мой взгляд это дичайшая дичь.
P.S. как вариант: если это ваш какой-то кастомный компонент, то можете не передавать tvs => 1, а в плагине на обновление ресурса обновлять ТВшку через $object->setTVValue($id/name, $value)
Не могу сказать ничего однозначного на счет связки с nuxt+vue в будущем. Скорее всего нет. Но и обратного утверждать не буду.
Если кому интересно, вот здесь подробней написал о разрабатываемой prisma-cms: habr.com/ru/post/448982/
И если правильно прочитаете написанное, сможете и REGEXP вызвать, но бегать регуляркой по такой строке — не самое правильное решение.
В моем конфиге полезного больше особо ничего нет, но вот еще кусок, где остальные запросы уходят на основную часть сайта: