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

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

С нами с 08 декабря 2012; Место в рейтинге пользователей: #1
Василий Наумкин
24 августа 2015, 16:32
0
Круто!

Я о таком даже и не подумал.
Василий Наумкин
24 августа 2015, 13:57
0
У нас на modhost.pro медленные PHP запросы пишутся в отдельный лог, где их можно посмотреть и оптимизировать.

Как у тебя на хостинге — не знаю.
Василий Наумкин
24 августа 2015, 13:36
0
Учитывая, что на этом сайте открытие тикета не тормозит даже в разделе «Вопросы», где уже 5091 ресурс, думаю, что дело не в Tickets.

Смотри, может есть какие-то плагины на редактирование ресурса или еще какие-нибудь улучшения админки?
Василий Наумкин
24 августа 2015, 12:50
+1
Вполне логичное и хорошее решение, учитывая возможности Fenom =)
Василий Наумкин
24 августа 2015, 12:45
+1
Я не сталкивался (и некогда проверять), но могу предположить, что всё дело в принципе работы MobileDetect. Он же берёт страницу во время рендера и вырезает куски, примерно в этот же момент, где-то там и Fenom парсит эту же страницу и судя по ошибке, возникает какой-то прям fatal error.

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

Но у меня на это времени нет, уж извини.
Василий Наумкин
24 августа 2015, 08:57
+8
Круто, конечно, но хотелось бы более вдумчивого оформления заметки.

Скоро будем делать так:
народ, вот приколюха по ссылке, зацените!

Я обычно комментарии лучше оформляю.
Василий Наумкин
24 августа 2015, 06:34
+1
Я не знаю, что тут может быть непонятного:
Fenom использует точку для доступа к значению массива, а MODX обычно выствляет так плейсхолдеры из массивов. Соотвественно, для тегов [[+tag.sub_tag]] аналогов в Fenom не предусмотрено.

Поэтому для подобных плейсхолдеров вам необходимо использовать вторую служебную переменную — {$_pls}:

{$_pls['tag.subtag']}
Больше ни для чего {$_pls} не нужен.
Василий Наумкин
24 августа 2015, 06:12
1
+2
{$_pls} — это плейхолдеры, переданные в чанк. А ты выставляешь и пытаешься получать глобальные плейсхолдеры.

<?php
$pdo = $modx->getService('pdoTools');

return $pdo->getChunk(
    '@INLINE
        <p>{$_pls.tag.sub_tag1} {$_pls.tag.sub_tag2}</p>
        <p>{$_pls["tag.sub_tag1"]} {$_pls["tag.sub_tag2"]}</p>
    ',
    array(
        'tag' => array(
            'sub_tag1' => 'John',
            'sub_tag2' => 'Doe',
        ),
        'tag.sub_tag1' => 'John',
        'tag.sub_tag2' => 'Doe',
    )
);
Василий Наумкин
23 августа 2015, 21:14
+3
А всё-таки, недоработка нашлась. Багом это назвать трудно, но по умолчанию pdoTools пытается работать с системным параметром link_tag_scheme и там указано -1.

Он получает этот -1 через modX::getOption() и отправляет в modX::makeUrl(). Фокус в том, что makeUrl хочет видеть этот -1 как целое число, а getOption получает его как строку. И вот из-за этой разницы типов данных возникает ошибка с генерацией адреса внутри makeUrl, потому что там строгая проверка (зачем — не знаю).

То есть, используются 2 функции MODX, но ошибка выходит при работе pdoTools, забавно. Причем, я когда-то фиксил это, но только для значений, переданных напрямую в pdoTools, поэтому
[[!pdoMenu?
	&scheme=`-1`
]]
работает корректно. А вот с системным значением по умолчанию — нет.

Добавил исправление и для него, и обновил пакет в репозитории. Больше такой проблемы не будет.
Василий Наумкин
23 августа 2015, 20:45
+1
Да-да, то что ты не знаешь про тег base и параметр &scheme — это баг pdoMenu, конечно.

50 000 закачек дополнения и никто такого явного бага не заметил, надо же! Просто укажи
[[!pdoMenu?
	&scheme=`-1`
	&parents=`0`
]]
и будут правильные относительные url от корня сайта. Остальные варианты здесь.
Василий Наумкин
23 августа 2015, 18:59
+2
Добавил жирным в нашем анонсе со ссылкой на эту статью.
Василий Наумкин
23 августа 2015, 18:56
1
+1
Плохой пример, советую переписать. Переменная {$modx} отключена по умолчанию и включать её никому не советую, иначе любой менеджер сайта может натворить дел.

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

Так что использование {$modx-> fromJSON()} отпадает, но зато мы можем использовать обычный json_decode() — он в списке разрешенных функций Fenom, вместе с
json_encode, count, is_string, is_array, is_numeric, is_int, is_object, strtotime, gettype, is_double, ip2long, long2ip, strip_tags, nl2br

Так что, правильный вариант будет таков:
{set $video_json = json_decode($_modx->resource.video, true)}

{if !empty($video_json['video'])}
	<iframe width="860" height="650" src="{$video_json['video']}" frameborder="0" allowfullscreen></iframe>
{else}
	Видео нет
{/if}

И кстати, можно заменить
{if !empty($video_json['video'])}
на
{if $video_json.video?}
См. операторы сравнения. Обожаю Fenom!
Василий Наумкин
23 августа 2015, 11:53
0
На здоровье!
Василий Наумкин
23 августа 2015, 11:49
0
Проверил у тебя на сайте, что происходит (будем считать, что здесь ты обратился в техподдержку хостинга =))

Создал страницу, удалил, нажал очистить корзину. Запрос на очистку выполнялся аж 20 секунд, но всё сделал. Почистил кэш, в админке и в БД больше нет удалённых ресурсов.

Всё в порядке. Думаю, проблема была с большом количестве ресурсов для удаления.
Василий Наумкин
23 августа 2015, 11:35
0
Тогда, похоже, это и вовсе не было связано с pdoTools.

Какая-то своя печаль. Проверяй логи на сервере (судя по пути, это modhost.pro) в директории log/.
Василий Наумкин
23 августа 2015, 10:43
0
А ошибки в логе-то пропали?

Может, не установилось у тебя что-то?
Василий Наумкин
23 августа 2015, 10:11
0
Почисти кэш везде. Если это не решит проблему, то вина уже не в pdoTools, потому что там ошибку я 100% поправил.

И у меня на тестовом сайте всё удаляется без проблем.
Василий Наумкин
23 августа 2015, 07:59
0
Моя вина, поправил.

Обнови pdoTools до 2.1.6-pl и всё наладится.