Дмитрий

Действительно. Судя по результатам webpagetest скорость ответа от сервера увеличилась в два с половиной раза! Кроме того, судя по тесту, при повторном прогоне, скорость ответа снова порезалась почти в 2 раза. Обычное кэширование страницы здесь ни причем, ибо тест со стандартным методом возвращает ответ с одинаковой скоростью при первом и втором прогоне.
Итого, прирост скорости в моем случае, в 4.5 раза.
Спасибо!

А что касается прямых запросов к бд?
Регистрация сервиса в modx каким-то образом увеличит скорость? (я сомневаюсь)

Почему я сомневаюсь в правильности решения.
Например, у меня есть смутное сомнение, что $modx->getChunk() в цикле не есть хорошо, ибо все 500 раз запускается и отрабатывает по новой. Возможно есть более дешевый способ?

Например, как в jQuery: можно потрогать и записать кусочек DOM в переменную $var, и затем анализировать его как угодно, не трогая документ снова.

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

Капец. Не ожидал найти их в меню «Содержимое».

Не могу понять как в 2.4.0 создавать группу ресурсов.

По всей видимости, нужно дорабатывать frontendjs.
Жаль, что в «assets/components/pdotools/js/pdopage.js» нет комментариев к коду.

Попробовал. Данные в сниппет передаются. Однако при Ajax — запросе, параметр where не учитывается, увы.
Параметры:

assetsUrl: "/assets/components/pdotools/"
link: "#pdopage .pagination a"
mode: "button"
more: "#pdopage .btn-more"
moreTpl: "<button class="btn btn-default btn-more glyphicon glyphicon-refresh"></button>"
pageLimit: 4
pageVarKey: "page"
pagination: "#pdopage .pagination"
rows: "#pdopage .rows"
wrapper: "#pdopage"

Вероятно, дело в параметрах:

&context=`[[*context_key]]`
            &action=`buy`
            &item_type=`all`
            &status_filter=`offline_too`
            &my_lang=`[[!user_lang]]`

Которые не указываются во встроенном запросе.
Каким образом можно передать дополнительные параметры в Get запросе?

Спасибо! Я чуть в mysql уже не полез))

Как же я мог так жестко протупить?)) Добавил строку в свою регистрацию, и все работает.)

$user->joinGroup('Users','Member');

Вопрос на засыпку: есть ли встроенный способ массово добавить всех пользователей в группу?)

Может быть что-нибудь не так с правами доступа к контекстам? Админскую учетку пускает в любой контекст. Может быть проблема в том что у простых пользователей нет прав на просмотр данного контекста? Хотя я никаких настроек прав не делал вообще, да и незарегистрированным пользователям контекст en доступен.

Простите, я ошибся. Мне пора привыкнуть к тому, что нельзя тестировать вход админской учеткой.
Это помогает логиниться во всех контекстах сразу, однако не решает основную проблему редиректа.

Похоже, что это работает! Огромное спасибо! Вы очень помогли.
Как показывает практика, Англоговорящие сообщества не отличается терпимостью к подобным ошибкам.
Впрочем, их понять можно, мы ведь тоже по корейским сайтам не ходим.

Спасибо за подсказку. Скопировал case, заменил на en и все работает. :)

Вот еще пара скриншотов:
www.facebook.com/photo.php?fbid=10207010403160039&set=p.10207010403160039&type=1&theater
www.facebook.com/photo.php?fbid=10207010405440096&set=p.10207010405440096&type=1&theater

Судя по скришотам в sessionid -> path должно стоять "/en/", а не "/" верно?
Подскажите, что пишет в Sessionid, login?

Запустил английскую версию. У некоторых пользователей наблюдается такая же ошибка. Спасает — очистка кукисов. Однако если после этого сделать релог, человек вновь не может попасть на английскую версию.

Грешил на сниппет логина, указал в нем используемые контексты:

[[!Login?
            &loginResourceId=`0`
            &rememberMeKey=`rememberme`
            &contexts=`web,en`
]]

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

Скриншот куков пользователя: www.facebook.com/photo.php?fbid=848346311915473&set=p.848346311915473&type=1&theater

В чем может быть дело? Судя по всему проблема с каким-то из сниппетов?

В чем конкретно дело?
Может все потому, что vp обрабатывает маршрут до обработки плагином мультиязычности, поэтому modx вообще не вкурсе что сменился контекст?

то-есть id одинаковый для всех контекстов — это всего лишь номер строки предмета в базе.

Может ли каким-то образом препятствовать Apache?
Слышал, что Modx лучше работает на nginx

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