Fi1osof

то получаю бесконечные аякс запросы:

Зато в них видно, что кукисы летят. Осталось только сервер нормально настроить.

P.S. я ушел к Морфею, так что отвечу только через несколько часов, если еще будут комменты.

Так не надо поднимать его на 80-ом. На 80-ом у вас сайт крутится, а сокет-сервер крутится на своем 2025-ом. Запросы у вас должны идти на /api/ вашего сайта, а не сокет-сервера. Просто на уровне сервера вы запросы на /api/ которые идут проксируете на 2025-ый порт. Для фронта это все неведомо, фронт ничего не знает про то, что и как там на сервере. Но отправляя на /api/ текущего домена, передаются и кукисы, потому что это тот же самый домен, а не другой. На уровне nginx вы /api/ запросы проксируете на 2025, вместе с кукисами они улетают, не доходя напрямую на сайт. А вот на уровне сокет-сервера, получив таким образом запрос с кукисами, вы уже должны получить $modx с инициализацей.

Велика вероятность в том, что у вас разные хосты. Домен один, а порты разные. Сам сайт на 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;

    }

Попробуйте для начала без конфига настроить сокет-запросы на тот же домен, просто посмотрите будут ли передаваться кукисы в запросах или нет. Ответа корретного не будет, но хотя бы в запросах кукисы должны появиться. Если появятся, то уже проксирование настраивать. А пока куки не будут передаваться, то и ловить на стороне сервера нечего.

Николай, я не знаю как именно у вас реализована работа MODX-API внутри сокет-сервера, то надо учитывать несколько моментов:

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


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

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

В общем, подробней распишите что и как получилось сделать, а на какой стадии какие затыки. Наверняка разобраться можно будет, но здесь не все так просто и парой строчек кода не отделаться.

Не полная расшифровка получилась… Еще ищет и с условием, что топик содержит в тексте «pdoTools»

Не за что.
Так же и конец строки можно проверять /(.+|$)/

Бага: ссылка вида https://домен/topics/modx-klub-2.14.0-filtry-by-@prisma-cms/filters.html разбивается на две части. Ты выше писал, почему так происходит, но это не оправдание, надо проверять маской /(^| )\@/ или типа того, то есть упоминание должно работать только если символ @ в начале строки или после пробела. Все остальное не должно восприниматься как упоминание.
Даблбага: если на произвольном тексте создавать ссылку через кнопочку и вставлять такую ссылку с собачкой в середине строки, ссылка формируется на отправку почты.

Неправильно понимаете. Эти фильтры универсальны практически для любого источника на GraphQL. Отличие будет лишь в том, если кто-то использует не where параметр, а какой-то другой, и под это просто надо будет в фильтре указать другой параметр и все. А далее стандартно все — запрос на сервер улетает с указанными параметрами, GraphQL-сервер отдает ответ, обрабатывая запрос вообще не интересует фронт как. И не важно что там на бэке, MODX, призма, ларка или что еще. И это работает и для того варианта с modxclub.ru, когда бэк был на MODX, а призма была только миддлом.
Как это работает, подробно описано здесь: modxclub.ru/topics/modx-klub-2.14.0-filtry-by-@prisma-cms/filters.html (ссылку копируйте и вставляйте в браузер, она тут баженно обрабатывается)

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

Пожалуйста.

Не соглашусь. Возьмите любой средний магазин с популярными вопросами «а как мне получить категории, в которых есть товары» или «где есть такие-то опции» и т.д. и т.п. Каждый день здесь же куча вопросов на эту тему. И каждый пишет свои костыли. Но когда система полностью клиент-серверно стандартизирована, подобных вопросов становится значительно меньше. Выигрыш в итоге не в скорости работы, а в скорости разработки, надежности и простоте сопровождения. Ну и взаимосовместимость различных модулей. Когда все они боле менее придерживаются стандартов, их удобно совместно использовать.

В том числе и это. То есть можно в одном запросе получить данные сразу из разнызх источников. Условно, мы не задумываемся о том, где и как сервер получает данные. Мы просто смотрим схему, пишем запрос в соответствии с ней и получаем ответ. Запросить что-то лишнее (отсутствующее в схеме) не получится. Это исключает распространенные случаи с классическим REST, когда на сервере логика и структура данных уже поменялась, а с фронта все еще прилетают старые запросы и мы получаем не ясно что.

Таки да.

Вот так мы подошли к ключевой разнице. GraphQL — это client-first API, то есть основная его часть активная в плане составления запросов уходит на сторону клиента. Приведу поясняющий пример. Возьмем этот же запрос

query {
  posts { # это массив
    title
    body
    author { # мы может пойти глубже
      name
      avatarUrl
      profileUrl
    }
  }
}

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

query {
  posts { # это массив
    title
    body
  }
}

то и получать и отдавать сервер будет только топики. А вот авторов он не будет получать. То есть нет лишней нагрузки.

В случае же с приведенным примером на MODX Graph, серверный запрос всегда будет получать все описанные в исходном запросе данные. И всегда отдавать их все. То есть если и использовать с этим GraphQL, то в лучшем случае мы получим меньше данных в запросе (сэкономим трафик), но нагрузка от этого сильно не упадет. И второй момент: мы не сможем получить больше, то есть запрос полный описан уже, и если мы туда что-то забыли прописать на серверной части, то больше запросить и не сможем. В полноценной же реализации можно получать результаты с очень большой вложенностью.

Само по себе REST API в MODX очень ограниченное. Не буду объяснять почему, но если есть возражения, вполне могу аргументировать. И если вы спрашиваете про то, были ли попытки сделать на базе этого REST для готовой MODX-базы, то да, конечно были. Подробная статья: modxclub.ru/topics/izmenennaya-versiya-modxclub.ru-na-prisma-cms-poka-chto-eshhe-v-svyazke-s-modx-2817.html
Тогда еще основной бэк modxclub.ru был на MODX, но фронт уже на JS. Между ними как раз и был GraphQL-сервер на призме. Часть запросов слалось на MODX-коннекторы, а часть запросов — прямая работа с БД через ORM knex.

Я не могу в двух словах объяснить что такое GraphQL и для чего он нужен. Хотя можно очень коротко сказать, что это просто замена традиционному REST. Но для более полного понимания советую к прочтению: habr.com/ru/post/326986/

Не за что.

Эта процедура довольно непростая, потому что помимо того, что надо сменить кодировку таблиц, надо еще сменить кодировку всех текстовых колонок. То есть в рамках одной таблицы может быть несколько колонок с различными кодировками. Руками проходиться — довольно муторно и долго.

Примерный сценарий следующий:
1. Восстанавливаете исходную базу данных (пусть и с неправильной кодировкой). Главное — чтобы через тот же phpMyAdmin отображались символы верно (PMA автоматически определяет кодировку и выводит с конвертированием). Если этого не получится сделать, то ничего более не получится сделать. Верю, что у вас есть живой бэкап.
2. Надо запустить запрос, который выполнит конвертирование всех таблиц и колонок. Судя по всему эти запросы описаны здесь: www.ryadel.com/en/mysql-convert-database-tables-specific-collation-character-set-charset/

Смотря что делать. Я не могу ответить да или нет, не понимая, какая задача стоит. Но скажу так: во фронте мы используем JS и часто кучу всяких сторонних JS-библиотек. То есть здесь как бы не важно MODX крутится или что (хоть статический .html). Но если говорить про клиент-серверную реализацию, то вопрос в том, куда и в каком виде запросы будут слаться и какие ответы будут прилетать. Так вот, основное ядро упомянутых технологий — GraphQL. Реализация этой технологии есть и на PHP. То есть вполне можно пилить компоненты под MODX, которые будут поддерживать GraphQL, отдавать схему, обеспечивать API и т.п. Но это не будет работать в полной мере так, как это описано у меня, потому что для того, чтобы все это работало с обработкой на сервере (включая работу с данными в БД), помимо схемы надо еще резолверы прописывать, то есть функции, обрабатывающие запросы. Чтобы было понятно о чем я, можно посмотреть на ранее опубликованные здесь топики про vue: modx.pro/search?query=vue Попытка была предпринята на замену ExtJS. Но ExtJS не работает с базой данных напрямую, он может только куда-нить слать запросы. Вот и здесь, хоть и взяли на замену ExtJS, все равно на сервере логики не прибавилось, она ограничена возможностями API MODX и установленных компонентов. Вот и с моими компонентами, их можно использовать для того, чтобы придать жизни фронту, но они не добавят логики MODX. Тем не менее, я ранее описывал, что создавал прослойку Фронт — node-server with GraphQL — (MODX || DB). Вот в таком варианте мы получали значительный прирост к гибкости API.

Николай Савин может отлично делать только две вещи:
1. Массово ставить минуса всему, что попадется.
2. Помогать никак.

Вот здесь я подробнейшим образом описал процесс восстановления: modxclub.ru/topics/virus-pronik-na-modx-sayt.-v-papke-assets-v-modx-unichtozheny-vse-skripty.reshenie..html Вариант почти 100%

На правах рекламы.

Мне не посетители нужны в цифровом исчислении, а обратная связь. Просто я что-то сделал опять нормальное и хочу поделиться. Но как это часто бывает, не многие могут понять сразу. Обычно потом, через год-два-три начинается «О, а вроде норм штука». Видимо опять тот случай. Ну ладно, кому-нибудь может все же будет интересно.