Алексей Карташов

Тогда проще на фронте Login поставить и прописать ему

&contexts=`web,mgr`

, а после авторизации открывать sitename.ru/manager/

А, ёмаё.

впилить

я прочитал как «выпилить».
Поэтому и удивился)

Похоже свою авторизацию придется впилить

Своя авторизация? Это как?

Вот честно — больше не знаю чем помочь(

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

Если в админке удаётся авторизоваться (пусть и через базу), то я бы сейчас на твоём месте начал поочерёдно отключать плагины и создал бы нового юзера-менеджера для теста (которому можно в админке работать) и пытался бы залогиниться из под него в другом браузере после каждого отключенного плагина.

p.s. когда происходит магия — это может быть проблема с кешером. Установи настройку cache_handler в значение xPDOFileCache (если там что-то другое написано) и удали папку с кешем.
Пока других вариантов у меня нет.

А папку с кэшем удалял?)
core/cache

Тогда как вариант — неправильные права на файлы и папки установлены.

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

Я обычно устанавливаю сайты с помощью Васиного скрипта автоустановки, в котором автоматически создаётся файл в корне сайта с нужными настройками, который достаточно один раз выполнить из консоли (по ssh) после установки (или обновлении) modx и все права выставляются автоматом.

Вот у меня vps'ка как раз слово в слово по тому мануалу и настроена. А вот с перезагружающейся без ошибок страницей входа в админку периодически сталкиваюсь. 100% закономерности не выявил, но в основном это были вот такие косяки с сессиями и в меньшей степени другие причины (уже и не помню какие именно).

Найди у себя в куках id сессии (и в том, и в другом браузере), потом нади эти айдишники в таблице modx_sessions, и удали строки с этими айдишниками. Потом удали куки.
60%, что должно помочь.

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

В вашем списке нету пункта «Прописал правила для вебсервера, чтобы папка assets основного домена была бы алиасом домена assets.domain.tld».
Этот пункт выполнен?

Лично я всю папку assets не выносил, может быть как раз из-за подобных глюков, точно не помню.
Но на отдельные домены выносил папки со скриптами, стилями и картинками, которые участвуют непосредственно в вёрстке — в корне сайта лежат папки js, css, img, которые являются алиасами соответствующих поддоменов. Но скрипты и стили от компонентов с таких поддоменов грузиться не будут — вот что обидно.

Странно, что с этой проблемой (именно с apc в modx) я стал первопроходцем)

В общем, нашёл виновника.

Это (кто бы мог подумать) — APC.

В общем, когда меняешь настройку обработчика кэша с xPDOFileCache на cache.xPDOAPCCache (cache_prefix, разумеется, задан), то всё работает в штатном режиме до тех пор, пока существует папка core/cache, которая была создана ранее.
Я думал, что теперь можно спокойно удалить папку core/cache, что логично, ибо весь кэш же теперь будет в памяти, а не на фс. Но не тут-то было. Если эта папка пустая (или её нет) и в настройках включен apc, то php молча умирает (когда сохраняется ресурс или настройка. Больше ни с чем не экспериментировал). Отловить в логах нормальную ошибку с нормальным описанием у меня не получилось.
Чего-то ему видать не хватает.

Выработал порядок действий, при котором с apc всё работает нормально:
1. Установить cache_handler в xPDOFileCache.
2. Удалить папку core/cache.
3. Открыть любую страницу в админке, чтобы создались нужные файлы в кэше.
4. Установить cache_handler в cache.xPDOAPCCache.
5. Не удалять папку core/cache! :-)

Вот в такой последовательности всё работает. ХЗ почему так.

.

Так а на какой странице был вызов этой инъекции? Какие компоненты и сниппеты на этой странице вызываются? Какие плагины?

p.s. судя по again2, может стоит ожидать скорого анонса от Евгения Борисова (Agel_Nash'а)? Если мне память не изменяет, он как раз 2 крупные уязвимости на белый свет вытащил. Эта будет третьей

Вот те раз, рег-рушная шара на iis'е. Оригинально.
Да ещё и пути всему свету как на блюдечке

А для продвижения в поисковых системах тэги — зло (если не уметь их правильно готовить).
А вот кросспостинга и правда не хватает иногда. Так что ждём!

Поставь точку в начале домена. Т.е.:

.mydomain.tld

Здравствуйте! Завтра напишу, пообщаемся. Сегодня уже работать закончил

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

Но блин. Пора мне с моим везением что-то делать.
Я от phpThumbs'а ничего, кроме ресайза, добиться не могу. Т.е. вообще!
Простой кофиг:

array(
      'fltr' => array(
        'drop|1|1|000000|5',
        'gblr|20',
      ),
      'f' => 'png',
      'w' => 400,
      'h' => 400
)

А ничего, кроме ресайза не применяется. Png'шным файл не становится; какой бы радиус размытия не устанавливал — всё одинаково; тени нет вообще.
Я уж как только не пробовал комментировать эти параметры — вообще без результатно, только ресайз работает.

Ладно, думаю, верну всё как было, мало ли. Удалил php5-imagick, чтобы через gd работало и… ничего не изменилось. Т.е. как был ресайз, так он и остался — единственным работающим.

Вроде уж 2.2.15 стоит, казалось бы, ан нет. Я уж и не знаю( Надо руковыпрямитель на алиэкспрессе посмотреть, вдруг продают.

upd. php5-fpm перезапускал

Наблюдаю через htop.
Нагрузка на процессор 0-3%, свободной памяти 60МБ.

Когда обновляю страницу со сниппетом, то
Нагрузка на процессор — 100%, память отжирается вся. В этот момент и отдаёт 502.

В те моменты, когда памяти хватает, то страница загружается.

Печаль-беда. Не думал я, что отресайзить и наложить тенюшку — это такая жесть в плане производительности.

Блин, у меня последняя надежда — может это потому, что наложение тени (на уже уменьшенную картинку) через imagemagick я запускаю через exec? да-да, exec не отключен

$cmdAddShadow = "convert {$src} \( +clone -background none -shadow {$config['opacity']}x{$config['size']}{$config['offsetLeft']}{$config['offsetTop']} \) \+swap -background none -layers merge +repage -mosaic $dest";
exec($cmdAddShadow);

Может имеет смысл поставить php-библиотеку и тогда всё будет хорошо?
Иначе это вообще какая-то жесть получается.

Я помню, ты давно писал, в каком-то плагине для ресайза ты использовал не phpThumb с GD, а именно imagemagick. У тебя же всё хорошо с ним было? Я чёт найти ту заметку не могу.

Точно, 502 вторую отдаёт (мой косяк, в конфиге была прописана кастомная страница 50x-ошибок, которая физически не существует, вот он 404 и показывал.)

Редиректа на картинку нет. Выводится через

<img src="{$result}">

Картинка не очень-то и большая — 2000x2000px. А когда буду в цикле гонять штук по 10-20 — то вообще ничего работать не будет.

Справедливости ради, картинка не только ресайзится — к ней накладывается тень через imagemagick. Но всё-равно — падает-то через раз и с разными (и нелогичными) таймаутами.