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

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

С нами с 08 декабря 2012; Место в рейтинге пользователей: #1
Василий Наумкин
05 декабря 2015, 16:59
0
Круто, богатая у тебя фантазия! Придётся отключать cacheManager совсем.

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

Твой ход =)
Василий Наумкин
05 декабря 2015, 16:04
0
Лично я ничего с этим делать не планирую.

Вызов Fenom чанков через Fenom синтаксис работает без проблем — лучше так и делать =)
Василий Наумкин
05 декабря 2015, 14:24
+2
Иван, 21 век на дворе. Трансляции делаются второклассниками без особых проблем.

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

Я сейчас опрашиваю своих, кто может это сделать. Искренне надеюсь, что помогу.
Выясняется, что всё не так уж и просто, да?
Василий Наумкин
05 декабря 2015, 13:50
+2
Почему бы тебе не приехать, и не показать всем, как это просто?

Других-то дел у Ивана не будет, только бегать и видео снимать.
Василий Наумкин
05 декабря 2015, 11:32
+1
MODX не знает ничего про Fenom, только pdoTools с ним может работать. Соотвественно, и обрабатывать чанк нужно не через методы MODX, а через методы pdoTools.
Василий Наумкин
05 декабря 2015, 11:12
0
$output = $modx->getChunk('testChunk', array('some_placeholder' => 'value'));
Смешно.

С каких это пор сам MODX научился работать с Fenom?
$pdo = $modx->getService('pdoTools');
$output = $pdo->getChunk('testChunk', array('some_placeholder' => 'value'));
Василий Наумкин
05 декабря 2015, 09:43
+3
$properties = $resource->get('properties');
unset($properties['some_property']);
$resource->set('properties', $properties);
$resource->save();
Василий Наумкин
05 декабря 2015, 09:41
+1
Всё, заменил lexicon и cacheManager с публичным свойством $modx на свои, ограниченные.

Теперь, насколько я вижу, из {$_modx} до modX добраться не выйдет. Спасибо, что указал на эту уязвимость!
Василий Наумкин
05 декабря 2015, 09:39
0
Не знаю, у меня вот так всё работает:
{$_modx->getChunk('@INLINE {$some_placeholder}', [
	'some_placeholder' => 'some_placeholder'
])}
Значит, проблем с обработкой плейсхолдеров Fenom в чанке нет.

Если я неправильно понимаю, чего ты хочешь добиться — покажи свою проблему на чистом тестовом сайте.
Василий Наумкин
04 декабря 2015, 22:56
+1
Всё, увидел этот баг на тестовом сайте.

Чанк с расширением нужно вызывать некэшируемым:
[[!$fenom1]]
Или можно так:
{$_modx->getChunk('fenom1')}
Тогда никаких белых страниц, всё работает.
Василий Наумкин
04 декабря 2015, 22:50
0
Не вижу никакого криминала, вроде всё должно быть ок.

Посмотри, может где-то какие-то ошибки в логах есть? По идее, всё должно расширяться без проблем — сам этим пользуюсь постоянно на разных проектах.
Василий Наумкин
04 декабря 2015, 22:35
+1
Хм. А чанк fenom3 как выглядит?
Василий Наумкин
04 декабря 2015, 22:18
0
Ты пишешь только
{extends 'fenom2'}

Или прям расширяешь его?
{extends 'fenom2'}

{block 'some_name'}
	Тут то, что расширили
{/block}
А то недавно Иван Климчук заметил, что без переопределения хотя бы одного блока ничего не работает и дописал это в доки.
Василий Наумкин
04 декабря 2015, 21:56
+2
А вот это я пропустил, спасибо — отключу в новых версиях обязательно.

Суть в том, что пользоваться {$_modx} можно давать кому угодно, он только для чтения, грубо говоря. Тогда как через {$modx} можно легко убить всю систему. По этой же причине и php функции отключены по умолчанию.
Василий Наумкин
04 декабря 2015, 18:57
+1
Да это, блин, даже на IIS работать будет, потому что работает сам MODX, а не веб-сервер
Василий Наумкин
04 декабря 2015, 06:49
+3
Ну вот мы её, наконец-то, и нашли.

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

.htaccess работает только в Apache2, Nginx же рассчитан на более высокие нагрузки и не может себе позволить читать дополнительный файл при каждом запросе.
Василий Наумкин
04 декабря 2015, 06:39
0
Ну так нужно настроить такие редиректы, нет?

Или они в .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 и не читали раздел настройка веб-сервера»?!
Василий Наумкин
04 декабря 2015, 05:30
+1
Опять это «к сожалению на modhost установлен nginx», как будто где-то он сегодня не установлен, или на Apache2 такого поведения нет. Приведу ответ Василия из поддержки modhost.pro:

Еще раз — какое отношение к вашей проблеме имеет хостинг? Почтайте, что ли, о ЧПУ. Её суть заключается в том, что запросы, которых реально нет на сервере отправляются на index.php с параметром.

То есть, если на сервере есть файл site.com/filename.txt, то nginx его отдаст сам. А если нет, то будет вызван
/index.php?q=/filename.txt
А дальше уже сам сайт определяет, что отдать на этот запрос — файл, редирект или 404.

Таким образом, при прямом запросе index.php?id=10 friendly urls и редиректы сервера не используются вообще. Движок получает команду показать 10ю страницу и сам её обрабатывает.

Версия MODX 2.2 при этом умела делать редиректы на канонический адрес. Новые версии, почему-то, перестали. Но каким образом за вас это должен исправлять хостинг — я отказываюсь понимать.

Откуда nginx вообще знает, какой именно адрес соответствуют 10 странице в MODX? Это знает только MODX. Ну и откуда у вас на сайте такие ссылки, чтобы к ним обращался поисковик — отдельный вопрос.

И
Покопался еще, и выяснил, что за это отвечает системная настройка request_method_strict, отключенная по умолчанию.

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

В плагине и правда нужно добавить проверку на $modx->context->key != 'mgr', тут я не доглядел.

P.S. Это АнтиСЕО началось с версии 2.3, насколько я могу судить. Это ж тысячи сайтов должны были просесть в выдаче.
Василий Наумкин
04 декабря 2015, 05:25
+1
Документация у нас открытая, можно редактировать через GitHub.

Допиши, что считаешь нужным, и пришли pull-request. Тогда эта информация добавится на сайте.

Все сетуют на плохую документацию, но никто, почему-то, не хочет её улучшать.
Василий Наумкин
03 декабря 2015, 20:20
2
0
Ну естественно, это мега-тайна, что все ТВ выбираются с префиксом tv. по умолчанию. В документации прям нет этого параметра. includeTVs, prepareTVs, processTVs и дальше пустота.

Можно и не делать пустой &tvPrefix, но тогда, не поверишь, нужно выводить ТВ вот так:
[[+tv.name]] - MODX
{$_pls['tv.name']} - Fenom
Про вывод через точку я тебе давал ссылку еще 2 часа назад.

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