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

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

В новых виджетах я прибиваю окошки принудительно, сразу после скрытия, примерно так:

this.on('hide', function() {
	var w = this;
	window.setTimeout(function() {
		w.close()
	}, 300);
})

И анимация на месте, и лишних элементов не остаётся. Может и в Tickets когда-то это допишу, но не сегодня.

Где возможность открытия окошек формально называют утечкой? Утечкой чего, кстати?

Я вот штук 30 окон наоткрывал, да так и не увидел разницы с потреблении оперативки браузером.

Дай хоть ссылку почитать, а то утечка не пойми чего происходит, а я и не в курсе.

Why not?

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

Всё, теперь ты можешь одобрять pull-request.

А Илья просто коммитил, как и все.

Утечка-то где?

Ну вот захотелось мне открыть 100500 комментов — почему нет?

Даже и не знаю, буду ли я там когда-нибудь что-то менять в ближайшее время.

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

Видимо есть какая-то мелкая мелочь, которая ускользнула от моего пристального внимания.

Одинаковые идентификаторы.

Такое дублирование элементов в ExtJS всегда бывает, если у них одинаковые id. Если у полей твоей формы указаны id и они не нужны тебе, на самом деле, то убирай их нафиг — пусть ExtJS сгенерирует уникальные автоматически.

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

Круто!

Я о таком даже и не подумал.

У нас на modhost.pro медленные PHP запросы пишутся в отдельный лог, где их можно посмотреть и оптимизировать.

Как у тебя на хостинге — не знаю.

Учитывая, что на этом сайте открытие тикета не тормозит даже в разделе «Вопросы», где уже 5091 ресурс, думаю, что дело не в Tickets.

Смотри, может есть какие-то плагины на редактирование ресурса или еще какие-нибудь улучшения админки?

Вполне логичное и хорошее решение, учитывая возможности Fenom =)

Я не сталкивался (и некогда проверять), но могу предположить, что всё дело в принципе работы MobileDetect. Он же берёт страницу во время рендера и вырезает куски, примерно в этот же момент, где-то там и Fenom парсит эту же страницу и судя по ошибке, возникает какой-то прям fatal error.

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

Но у меня на это времени нет, уж извини.

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

Скоро будем делать так:

народ, вот приколюха по ссылке, зацените!

Я обычно комментарии лучше оформляю.

На здоровье!

Я не знаю, что тут может быть непонятного:

Fenom использует точку для доступа к значению массива, а MODX обычно выствляет так плейсхолдеры из массивов. Соотвественно, для тегов [[+tag.sub_tag]] аналогов в Fenom не предусмотрено.

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

{$_pls['tag.subtag']}

Больше ни для чего {$_pls} не нужен.

{$_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',
    )
);

А всё-таки, недоработка нашлась. Багом это назвать трудно, но по умолчанию pdoTools пытается работать с системным параметром link_tag_scheme и там указано -1.

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

То есть, используются 2 функции MODX, но ошибка выходит при работе pdoTools, забавно. Причем, я когда-то фиксил это, но только для значений, переданных напрямую в pdoTools, поэтому

[[!pdoMenu?
	&scheme=`-1`
]]

работает корректно. А вот с системным значением по умолчанию — нет.

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

Да-да, то что ты не знаешь про тег base и параметр &scheme — это баг pdoMenu, конечно.

50 000 закачек дополнения и никто такого явного бага не заметил, надо же! Просто укажи

[[!pdoMenu?
	&scheme=`-1`
	&parents=`0`
]]

и будут правильные относительные url от корня сайта. Остальные варианты здесь.

А вот и в репозиторий MODX добавили issue.

Добавил жирным в нашем анонсе со ссылкой на эту статью.