Fi1osof

Пожалуйста.

Загружать и сохранять после D&D — это правильно. А вот base64 — увольте. Я еще понимаю на выходе кодировать base64 при генерации страницы (для мобильников это приятно), но в контенте хранить в 64 неее.

Запретите права на обновление файлов github.com/modxcms/revolution/blob/2.x/core/model/modx/processors/browser/file/rename.class.php#L15
Нефиг обновлять. Тогда ОК будет.

И еще у вас дыра серьезная есть: права new_tv true. Можно создать TV-ху с EVAL-ом и обновиться до судо.

Кстати, это дыра MODX-а. Нельзя загружать php-файлы, но можно загружать разрешенное, и потом переименовывать в .php

Ну вы по логам посмотрели все, да?

Это дикое зло… У клиента сайт есть, в контенте прям картинки в base64, да такие, что браузер загибается насмерть, потому что редактор замучивается обрабатывать весь полученный контент.

Сорри… joxi.ru/p278ek3h0WBjpA

Вернул sudo = 0 обратно.

Пожалуйста!

Не за что!

Если ключ не хотите светить, то однозначно запрос надо слать с вашего сервера на донора. В MODX есть готовый CURL-клиент. Вот код для примера:

$client = $modx->getService('rest.modRestCurlClient');
$result = $client->request('https://ya.ru', '/', 'POST', $params = array('foo'  => 'foo'));
print $result;

Можете с этим кодом к консоли поиграться.

Не за что!

Вот это еще глянь, должно пригодиться: modx.pro/help/7278/#comment-52671

Кстати, Василий, только сейчас вот переосмыслил вот эту твою фразу (с учетом этой информации):

Это потому, что парсер pdoTools подлезает в самом конце, уже после сохранения кэша документа.

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

Не за что!

Конечно нет))

Да не, все верно. Я вообще отметил набирающую оборот тенденцию: много кто стал просто переделывать чужие пакеты. То есть не создавать что-то новое, а именно переделывать. ИМХО или PR, или что-то принципиально новое. К примеру, как ты меня когда-то обвинил в том, что я modSociety запулил, хотя есть Articles. Да, эти решения примерно направлены на одно и то же, но они принципиально разные. Это не копии, это абсолютно разные решения. А сейчас как делают? Скопируют Articles, назовут по другому, и скажут, что вот тут есть принципиальные улучшения. Ну ты понял.

Сорри за долгий ответ, отвлекся.

Но по моему, дело в том, что теги Fenom на странице отрабатывают после процессинга документа

Все верно. Из-за этого и была проблема. Дело в том, что $modx->regClientStartupScript() и подобные методы работают со свойствами самого $modx, а вот при сохранении кеша используются свойства самого ресурса. А так, как в отработанных уже после процессинга тегах выполняется типа $modx->regClientStartupScript() (который устанавливает свойства для $modx, но не устанавливает их для $modx->resource), то при генерации кеша документа этих скриптов в кеше просто нет. joxi.ru/4Ak3wb9tMX8nGA
Решение: пишем плагин на событие OnBeforeSaveWebPageCache, простейший вид:

$modx->resource->_jscripts = $modx->jscripts;
$modx->resource->_sjscripts = $modx->sjscripts;
$modx->resource->_loadedjscripts = $modx->loadedjscripts;

И тогда при генерации кеша документа будут сохранены все скрипты. joxi.ru/LmGVQx0uRJN1Xr
При чем это будет выполняться только при первом заходе на страницу. Когда документ уже закеширован будет, это не будет выполняться.

UPD: Может даже имеет смысл это в ядро запулить (то есть код кешманагера поправить), так как очень похоже на багу самого MODX-а. Какая-то глупость в двух отдельных сущностях хранить эти переменные и создавать/получать в разных местах на разных этапах.

Насколько я вижу, половина логики Twiggy скопирована из pdoTools, поэтому и отвечаю на твои вопросы =)

Я так и понял :) Предполагаю, что тебе даже не очень-то и нравится такая объемная копируемость :)

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

Да не, вы — это я во множественном числе. Сначала ты, потом Володя, до него еще кто-нибудь (я же не очень пристально за вашими компонентами следил и не знаю кто когда еще подобный трюк выполнял). Это вот сейчас я стал больше интересоваться унификацией, вот и поглядываю иногда :)

А вообще, тут всё просто. Без этой правки скрипты и стили из кэшируемых сниппетов, вызванных через Fenom, не добавлялись на страницу. А с ней — добавляются.

Тут ответ однозначный: где-то неверная последовательность вызова/вывода. Ты четко знаешь когда бага возникает. Если не лень, создай тестовый сайт с этой багой (феном + минифи), закомментируй этот свой хак и пришли доступ, я посмотрю. Уверен, найду суть проблемы.

Такого ответа я и ожидал. Но вы изначально все не правильно делали. Эти скрипты известны документу еще на уровне получения его из кеша. Все, что вам нужно было — это плагин навесить на правильное событие и присвоить документу эти данные. И все бы у вас было ОК.
Почему я про этот кусок кода спросил? Во-первых, этот метод парсера в процессе отработки документам может быть вызван не один раз. Во-вторых, в разные стадии вызова его в массивах этих могут содержаться разные наборы скриптов (что не страшно, конечно же, ибо все равно они будут в шаблон подставлены только в одном месте, но как минимум бессмысленно).

Второй вопрос как раз и задал человек комментарием выше. И совершенно не без основательно. Вот мы смотрим кеш документа с твоим шаблоном:

'_content' => '{% extends "BaseTemplate" %}

{% block title %}Главная{% endblock %}
{% block head %}
    {{ parent() }}
    <style type="text/css">
        .important { color: #336699; }
    </style>
{% endblock %}
{% block content %}
    <h1>Главная</h1>
    <p class="important">
        Приветсвую на своем потрясном сайте!
    </p>
{% endblock %}',

Он же не скомпилированный. Кеширование отдыхает тогда в принципе. Это то, что было долгое время в самом MODX (я раньше не однократно писал про его проблемы, из-за того, что он даже кешируемые теги в кеш пишет как есть, и потом все равно каждый раз реплейс делает), и что в MODX наконец-то поправилось (теперь он в кеш пишет сразу конечный HTML из кешируемых элементов), и теперь ты это достижение ломаешь. Шаблоны будут чуть более гибкие, но зато более тормознутые.

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

Хранить в конечном html очень даже есть смысл, в этом и есть смысл кеширования ресурсов. А вот то, что иначе не будет отрабатываться каждый раз — так вот для этого и были придуманы не кешируемые MODX-теги. Напиши один сниппет вида [[!twig?tpl=`some_tpl`]] и все. И где надо некешируемые блоки вставлять — там его и прописывать в шаблонах.
Еще раз: в MODX с точки зрения шаблонизации только два минуса:
1. нет компиляции в нормальный php (чтобы логика была)
2. нет расширения шаблонов.
В остальном она довольно продвинутая (особенно крут вложенный парсинг).
Ты добавляешь расширяемости и логики, но ломаешь родное кеширование.

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

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