Fi1osof

Fi1osof

С нами с 05 мая 2014; Место в рейтинге пользователей: #6
Отправить деньги
Fi1osof
19 мая 2019, 01:50
0
Помню. Но он не проще и не универсальней, потому что будет срабатывать только на расширенный тип ресурса. А плагин на обновление будет срабатывать на обновление любых типов ресурсов (имеется ввиду документов).
Fi1osof
18 мая 2019, 18:12
0
Нет, обходных моментов нативных нет. И да, MODX перетирает при обновлении все ТВшки при передаче tvs => 1. То есть если передан tvs => 1, то он пытается обновить все TVшки документа и если для имеющейся TVшки не было получено новое значение, то она стирается.
Это один из самых неприятных моментов в MODX, мешающих разработке кастомных интерфейсов для обновления ресурсов, так как при передаче хотя бы одного параметра надо передавать все имеющиеся. А это не только неудобно, но и не секурно (ты такой типа через управление формами скрываешь отдельные TVшки, чтобы другие манагеры их не видели и не меняли, а они тупо в hidden-полях на странице находятся и мало того, что их можно прочитать, так их еще и изменить можно (но это не точно, не помню проверяет ли он права на доступ к ТВшке при обновлении, но по-моему нет)). На мой взгляд это дичайшая дичь.

P.S. как вариант: если это ваш какой-то кастомный компонент, то можете не передавать tvs => 1, а в плагине на обновление ресурса обновлять ТВшку через $object->setTVValue($id/name, $value)
Fi1osof
29 апреля 2019, 08:00
0
Андрей, привет!
Не могу сказать ничего однозначного на счет связки с nuxt+vue в будущем. Скорее всего нет. Но и обратного утверждать не буду.
Fi1osof
27 апреля 2019, 18:08
+2
Всем привет!

Если кому интересно, вот здесь подробней написал о разрабатываемой prisma-cms: habr.com/ru/post/448982/
Fi1osof
25 апреля 2019, 01:02
0
РЕШЕНИЕ: в стиле «сам спросил, сам ответил»:
Решение не очень годное. Для вашего случая больше вот это подойдет: modx.pro/development/7236
И если правильно прочитаете написанное, сможете и REGEXP вызвать, но бегать регуляркой по такой строке — не самое правильное решение.
Fi1osof
24 марта 2019, 23:31
0
Вы в личку пришлите доступ к вашей странице, а то там по логину-паролю судя по всему доступ, я не вижу самих запросов. Вообще у вас 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;

    }
Fi1osof
24 марта 2019, 14:05
0
то получаю бесконечные аякс запросы:
Зато в них видно, что кукисы летят. Осталось только сервер нормально настроить.

P.S. я ушел к Морфею, так что отвечу только через несколько часов, если еще будут комменты.
Fi1osof
24 марта 2019, 14:03
0
Так не надо поднимать его на 80-ом. На 80-ом у вас сайт крутится, а сокет-сервер крутится на своем 2025-ом. Запросы у вас должны идти на /api/ вашего сайта, а не сокет-сервера. Просто на уровне сервера вы запросы на /api/ которые идут проксируете на 2025-ый порт. Для фронта это все неведомо, фронт ничего не знает про то, что и как там на сервере. Но отправляя на /api/ текущего домена, передаются и кукисы, потому что это тот же самый домен, а не другой. На уровне nginx вы /api/ запросы проксируете на 2025, вместе с кукисами они улетают, не доходя напрямую на сайт. А вот на уровне сокет-сервера, получив таким образом запрос с кукисами, вы уже должны получить $modx с инициализацей.
Fi1osof
24 марта 2019, 13:08
0
Велика вероятность в том, что у вас разные хосты. Домен один, а порты разные. Сам сайт на 80-ом порту, а запросы идут на порт 2025. Скорее всего это проблема именно в этом. Я делаю так: создаю на уровне nginx подмену для адреса /api/ и все запросы сокета летят туда, а там уже проксируется на сокет-порт. Пример конфига:
location /api/ {
        
    
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout 36000;

        rewrite ^/api/(.*) /$1 break;
        proxy_pass http://localhost:4000;
        proxy_redirect     off;
        proxy_set_header   Host $host;

        proxy_set_header X-Real-IP $remote_addr ;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    }
Попробуйте для начала без конфига настроить сокет-запросы на тот же домен, просто посмотрите будут ли передаваться кукисы в запросах или нет. Ответа корретного не будет, но хотя бы в запросах кукисы должны появиться. Если появятся, то уже проксирование настраивать. А пока куки не будут передаваться, то и ловить на стороне сервера нечего.
Fi1osof
24 марта 2019, 10:13
+2
Николай, я не знаю как именно у вас реализована работа MODX-API внутри сокет-сервера, то надо учитывать несколько моментов:

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


2. На стороне сокет-сервера, где вы подключаете MODX-API, вам надо поймать куку PHPSESSID и скормить в инициализацию $modx. Так же убедитесь, что у вас эта кука там в наличии, а главное, инициализация $modx идет с контекстом, в котором пользователь авторизован.

3. У вас сокет-соединение не понимает авторизацию вообще всегда, или после авторизации если перезагрузить страницу, то все ОК, а просто проблема именно после авторизации без перезагрузки страницы? Просто это важный момент, так как сокет-соединение не отсылает кукисы в каждом запросе. Кукисы отправляются только при установке сокет-соединяния. То есть после авторизации и на логаут надо сокет-соединение реконнектить. Надо смотреть в сторону socketio.close(false, false);

В общем, подробней распишите что и как получилось сделать, а на какой стадии какие затыки. Наверняка разобраться можно будет, но здесь не все так просто и парой строчек кода не отделаться.
Fi1osof
15 марта 2019, 12:33
0
Не полная расшифровка получилась… Еще ищет и с условием, что топик содержит в тексте «pdoTools»
Fi1osof
15 марта 2019, 11:16
+1
Не за что.
Так же и конец строки можно проверять /(.+|$)/
Fi1osof
15 марта 2019, 10:59
+1
Бага: ссылка вида https://домен/topics/modx-klub-2.14.0-filtry-by-@prisma-cms/filters.html разбивается на две части. Ты выше писал, почему так происходит, но это не оправдание, надо проверять маской /(^| )\@/ или типа того, то есть упоминание должно работать только если символ @ в начале строки или после пробела. Все остальное не должно восприниматься как упоминание.
Даблбага: если на произвольном тексте создавать ссылку через кнопочку и вставлять такую ссылку с собачкой в середине строки, ссылка формируется на отправку почты.
Fi1osof
15 марта 2019, 10:46
0
Неправильно понимаете. Эти фильтры универсальны практически для любого источника на GraphQL. Отличие будет лишь в том, если кто-то использует не where параметр, а какой-то другой, и под это просто надо будет в фильтре указать другой параметр и все. А далее стандартно все — запрос на сервер улетает с указанными параметрами, GraphQL-сервер отдает ответ, обрабатывая запрос вообще не интересует фронт как. И не важно что там на бэке, MODX, призма, ларка или что еще. И это работает и для того варианта с modxclub.ru, когда бэк был на MODX, а призма была только миддлом.
Как это работает, подробно описано здесь: modxclub.ru/topics/modx-klub-2.14.0-filtry-by-@prisma-cms/filters.html (ссылку копируйте и вставляйте в браузер, она тут баженно обрабатывается)
Fi1osof
15 марта 2019, 10:33
+1
Я скажу для чего его можно использовать, на примере того же modx.pro. modx.pro — довольно старый сайт с кучей контента. И каждый раз, когда хочется что-то здесь найти, это просто ппц. У меня более 1000 комментариев. Когда я вижу чей-то вопрос, который уже задавали и на который я уже давал развернутый ответ и хочу найти этот коммент, чтобы дать ссылку, какие у меня есть для этого инструменты? Только два — 1. текстовая поисковая строка на общей странице комментов/топиков. 2. Пагинация. Не редко 15 минут потратишь и не найдешь ничего.
А вот пример запроса с использованием GraphQL: modxclub.ru/topics?filters=%7B%22CreatedBy%22%3A%7B%22username_not%22%3A%22Fi1osof%22%7D%2C%22Comments_every%22%3A%7B%22CreatedBy%22%3A%7B%22username_not%22%3A%22Fi1osof%22%7D%7D%2C%22Comments_some%22%3A%7B%7D%2C%22Blog%22%3A%7B%22name%22%3A%22%D0%BF%D0%B5%D1%81%D0%BE%D1%87%D0%BD%D0%B8%D1%86%D0%B0%22%7D%2C%22Tags_some%22%3A%7B%22Tag%22%3A%7B%22name_contains%22%3A%22pdo%22%7D%7D%2C%22contentText_contains%22%3A%22pdoTools%22%7D
Расшифровка: «Получить все топики, созданные не мной, в блоге Песочница, с тегом pdo, в которых есть хотя бы один комментарий и все комментарии написаны не мной». И это далеко не последний уровень вложенности запросов. Покажите на MODX хоть один проект с подобными фильтрами.
Fi1osof
14 марта 2019, 20:39
0
Не соглашусь. Возьмите любой средний магазин с популярными вопросами «а как мне получить категории, в которых есть товары» или «где есть такие-то опции» и т.д. и т.п. Каждый день здесь же куча вопросов на эту тему. И каждый пишет свои костыли. Но когда система полностью клиент-серверно стандартизирована, подобных вопросов становится значительно меньше. Выигрыш в итоге не в скорости работы, а в скорости разработки, надежности и простоте сопровождения. Ну и взаимосовместимость различных модулей. Когда все они боле менее придерживаются стандартов, их удобно совместно использовать.
Fi1osof
14 марта 2019, 20:35
0
В том числе и это. То есть можно в одном запросе получить данные сразу из разнызх источников. Условно, мы не задумываемся о том, где и как сервер получает данные. Мы просто смотрим схему, пишем запрос в соответствии с ней и получаем ответ. Запросить что-то лишнее (отсутствующее в схеме) не получится. Это исключает распространенные случаи с классическим REST, когда на сервере логика и структура данных уже поменялась, а с фронта все еще прилетают старые запросы и мы получаем не ясно что.