Василий Наумкин

Отличный способ!

А &tvFilters нужен исключительно для совместимости с getResources. Никому не рекомендую его использовать.

Добавлю от себя $50.

Итого останется только согласие Ивана и найти еще $50.

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

Это отключено по умолчанию. Так же как и доступ в php и modX.

А доступ в {$_modx} включен по умолчанию и он должен быть безопасным. Сегодня ты очень сильно помог в этой задаче. Надеюсь, что больше никаких уязвимостей при конфигурации по умолчанию не найдётся.

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

Круто, богатая у тебя фантазия! Придётся отключать cacheManager совсем.

Хотя нет, не отключать, а просто запретить указывать такие настройки. Выложил новую версию, в которой параметр $options у cacheManager::set() не используется. Итого, кэш получать можно любой, а сохранять только в default.

Твой ход =)

Лично я ничего с этим делать не планирую.

Вызов Fenom чанков через Fenom синтаксис работает без проблем — лучше так и делать =)

Иван, 21 век на дворе. Трансляции делаются второклассниками без особых проблем.
…
С этим-то справитесь?

А ты будь тогда посложнее, ок? Если ты считаешь, что всё очень вежливо и по-доброму написал — то я несогласен, извини.

Я сейчас опрашиваю своих, кто может это сделать. Искренне надеюсь, что помогу.

Выясняется, что всё не так уж и просто, да?

Почему бы тебе не приехать, и не показать всем, как это просто?

Других-то дел у Ивана не будет, только бегать и видео снимать.

MODX не знает ничего про Fenom, только pdoTools с ним может работать. Соотвественно, и обрабатывать чанк нужно не через методы MODX, а через методы pdoTools.

$output = $modx->getChunk('testChunk', array('some_placeholder' => 'value'));

Смешно.

С каких это пор сам MODX научился работать с Fenom?

$pdo = $modx->getService('pdoTools');
$output = $pdo->getChunk('testChunk', array('some_placeholder' => 'value'));

$properties = $resource->get('properties');
unset($properties['some_property']);
$resource->set('properties', $properties);
$resource->save();

Всё, заменил lexicon и cacheManager с публичным свойством $modx на свои, ограниченные.

Теперь, насколько я вижу, из {$_modx} до modX добраться не выйдет. Спасибо, что указал на эту уязвимость!

Не знаю, у меня вот так всё работает:

{$_modx->getChunk('@INLINE {$some_placeholder}', [
	'some_placeholder' => 'some_placeholder'
])}

Значит, проблем с обработкой плейсхолдеров Fenom в чанке нет.

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

Всё, увидел этот баг на тестовом сайте.

Чанк с расширением нужно вызывать некэшируемым:

[[!$fenom1]]

Или можно так:

{$_modx->getChunk('fenom1')}

Тогда никаких белых страниц, всё работает.

Не вижу никакого криминала, вроде всё должно быть ок.

Посмотри, может где-то какие-то ошибки в логах есть? По идее, всё должно расширяться без проблем — сам этим пользуюсь постоянно на разных проектах.

Хм. А чанк fenom3 как выглядит?

Ты пишешь только

{extends 'fenom2'}

Или прям расширяешь его?

{extends 'fenom2'}

{block 'some_name'}
	Тут то, что расширили
{/block}

А то недавно Иван Климчук заметил, что без переопределения хотя бы одного блока ничего не работает и дописал это в доки.

А вот это я пропустил, спасибо — отключу в новых версиях обязательно.

Суть в том, что пользоваться {$_modx} можно давать кому угодно, он только для чтения, грубо говоря. Тогда как через {$modx} можно легко убить всю систему. По этой же причине и php функции отключены по умолчанию.

Да это, блин, даже на IIS работать будет, потому что работает сам MODX, а не веб-сервер

Ну вот мы её, наконец-то, и нашли.

У тебя файл .htaccess на 25 килобайт с десятками хитрых правил, которые нужно как-то переписать для Nginx, или забить в компонент Redirector для MODX. После этого все редиректы вернутся и проблем с SEO больше не будет.

.htaccess работает только в Apache2, Nginx же рассчитан на более высокие нагрузки и не может себе позволить читать дополнительный файл при каждом запросе.

Ну так нужно настроить такие редиректы, нет?

Или они в .htaccess настроены, а тут нужно их под nginx переписать и вся проблема именно в этом? Действительно, залез в .htaccess, а там:

RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/
RewriteRule ^index\.php$ http://sitename.ru [R=301,L]

Видимо таким образом Apache2 типа «сам» и делает редиректы — при их настройке, да.

То есть, вся претензия к хостингу, MODX, SEO, nginx и прочему заключается в «Мы не знали, что у вас нет Apache2 и не читали раздел настройка веб-сервера»?!