[pdoTools] 2.10.1 - исправление кэширования скриптов и стилей
Давненько я не писал про обновления pdoTools, ведь там не происходило ничего примечательного — обычная работа над некритичными ошибками и улучшения функционала.
Но сегодняшняя версия стоит отдельного объявления, ведь в ней наконец-то исправлена работа кэширования скриптов и стилей! За отличное расследование и исправление благодарим Сергея Шлокова, а я немного расскажу, как эта ошибка вообще появилась.
Дело в том, что изначально в ранних версиях pdoTools вызывать сниппеты можно было только одним методом — $_modx->runSnippet() и он напрямую вызывал метод modX::runSnippet().
Вызовы Fenom работают уже после того, как MODX парсит кэшированные тэги, поэтому все скрипты и стили, зарегистрированные через Fenom, не попадали в кэш ресурса. Чтобы исправить это, я запихивал в этот кэш вручную всё что было, после каждого запуска Fenom.
Это было крайне неудачным решением, но другого на тот момент я придумать не смог. Так что, с добавлением еще пары костылей оно более менее работало.
Но дело в том, что со временем запуск сниппетов через Fenom был переписан, и все вызовы давно шли через метод pdoTools::runSnippet(), что позволяло, в принципе, контролировать регистрацию скриптов и стилей кэшированных сниппетов — да никто об этом не подумал, кроме Сергея.
Так что в новой версии убраны все кривые костыли, а обработка скриптов и стилей кэшированных сниппетов, запускающихся через Fenom любым способом, происходит в одном его методе. И проблем с кэшированием больше нет.
Еще некоторые изменения:
— Улучшено регулярное выражение для определения синтаксиса Fenom. Теперь ситуаций, когда в чанке один просто тег и парсер не считает его достойным обработки, должно стать гораздо меньше. А ложных срабатываний, надеюсь, не прибавится.
— Пока проверял работу кэширования скриптов и стилей, заметил баг в pdoPage. Если ему указать &cache=`1`, то он перестаёт регистрировать канонические url со второй загрузки. Исправлено.
— Сами канонические url теперь всегда прописываются полным адресом вместе с доменом, независимо от настроек, как то советует Google.
— А pdoMenu теперь должен уметь использовать &conditionalTpls для чанка по умолчанию. Не знаю, насколько это полезно при наличии Fenom, но просили добавить.
— Еще добавили новую системную настройку pdotools_fenom_save_on_errors, которая сохраняет шаблоны при ошибках компиляции в core/cache/pdotools/error/, чтобы вам удобнее было их дебажить.
Остальные изменения можно посмотреть на GitHub.
Новая версия уже в репозиториях, можно обновляться!
Но сегодняшняя версия стоит отдельного объявления, ведь в ней наконец-то исправлена работа кэширования скриптов и стилей! За отличное расследование и исправление благодарим Сергея Шлокова, а я немного расскажу, как эта ошибка вообще появилась.
Дело в том, что изначально в ранних версиях pdoTools вызывать сниппеты можно было только одним методом — $_modx->runSnippet() и он напрямую вызывал метод modX::runSnippet().
Вызовы Fenom работают уже после того, как MODX парсит кэшированные тэги, поэтому все скрипты и стили, зарегистрированные через Fenom, не попадали в кэш ресурса. Чтобы исправить это, я запихивал в этот кэш вручную всё что было, после каждого запуска Fenom.
Это было крайне неудачным решением, но другого на тот момент я придумать не смог. Так что, с добавлением еще пары костылей оно более менее работало.
Но дело в том, что со временем запуск сниппетов через Fenom был переписан, и все вызовы давно шли через метод pdoTools::runSnippet(), что позволяло, в принципе, контролировать регистрацию скриптов и стилей кэшированных сниппетов — да никто об этом не подумал, кроме Сергея.
Так что в новой версии убраны все кривые костыли, а обработка скриптов и стилей кэшированных сниппетов, запускающихся через Fenom любым способом, происходит в одном его методе. И проблем с кэшированием больше нет.
Другие изменения
Еще некоторые изменения:
— Улучшено регулярное выражение для определения синтаксиса Fenom. Теперь ситуаций, когда в чанке один просто тег и парсер не считает его достойным обработки, должно стать гораздо меньше. А ложных срабатываний, надеюсь, не прибавится.
— Пока проверял работу кэширования скриптов и стилей, заметил баг в pdoPage. Если ему указать &cache=`1`, то он перестаёт регистрировать канонические url со второй загрузки. Исправлено.
— Сами канонические url теперь всегда прописываются полным адресом вместе с доменом, независимо от настроек, как то советует Google.
— А pdoMenu теперь должен уметь использовать &conditionalTpls для чанка по умолчанию. Не знаю, насколько это полезно при наличии Fenom, но просили добавить.
— Еще добавили новую системную настройку pdotools_fenom_save_on_errors, которая сохраняет шаблоны при ошибках компиляции в core/cache/pdotools/error/, чтобы вам удобнее было их дебажить.
Остальные изменения можно посмотреть на GitHub.
Новая версия уже в репозиториях, можно обновляться!
Комментарии: 79
при обновлении зависание страницы и ошибка 500, сайт и админка в ауте
здесь подробнее описал modx.pro/help/13592/
здесь подробнее описал modx.pro/help/13592/
Классное и долгожданное обновление! А что за инструмент для тестирования регулярок на скрине изображен?
Благодарю, Василий.
Молодцы, теперь работа сайтов будет более стабильная
Добрый день!
Установил pdoTools.
Теперь выходит ошибка на сайте — HTTP ERROR 500.
В логах сервера показывает ошибку —
Установил pdoTools.
Теперь выходит ошибка на сайте — HTTP ERROR 500.
В логах сервера показывает ошибку —
Backend fatal error: PHP Fatal error: Cannot use [] for reading in /var/www/vhosts/site.ru/httpdocs/core/components/pdotools/model/pdotools/pdotools.class.php on line 373\nВерсия PHP — 5.4.16
Прочитай первый комментарий.
Отличная новость! Теперь можно вернуться к стандартному default.js в Tickets.
А на этот сайт обновление пока не ставил? Барахлит.
А на этот сайт обновление пока не ставил? Барахлит.
Первым делом поставил.
Что именно барахлит?
Что именно барахлит?
Я ни разу не словил, но на всякий случай поудалял кэш еще пару раз.
Возможно, это уже какой-то другой глюк именно на modx.pro
Возможно, это уже какой-то другой глюк именно на modx.pro
Попробуй зайти гостем на главную.
Очень смешной баг новой версии. Это происходит внутри pdoPage
и получаем добавление скриптов и стилей в modX::resource->_loadedjscripts с последующим сохранением их в кэш.
$output = $pdoPage->pdoTools->runSnippet($scriptProperties['element'], $scriptProperties);
и получаем добавление скриптов и стилей в modX::resource->_loadedjscripts с последующим сохранением их в кэш.
Я так понимаю, что похожая ситуация будет и с другими сниппетами pdoTools (mFilter и др. с параметром element)
Конечно! Выложил исправление.
$output = $pdoPage->pdoTools->runSnippet('!' . ltrim($scriptProperties['element'], '!'), $scriptProperties);
правильно я понимаю, что теперь можно кэшированный минификс пользовать?
Да.
Василий, спасибо огромное! Исчезли дубли каноникалов, про которые писали здесь modx.pro/help/12465/#comment-89059. Еще бы научится заставлять pdoPage делать каноникал в нижнем регистре, почему-то когда в файле snippet.pdopage.php делаю
$canurl = mb_strtolower($canurl);
перед $modx->regClientStartupHTMLBlock('<link rel="canonical" href="' . $canurl . '"/>');
это никакого влияния не оказывает. Как можно принудительно привести канонический url к нижнему регистру?
Тут нужно подумать, с какого перепуга у тебя вообще url не в нижнем регистре. Проблема явно не в pdoPage.
Нет конечно, проблема не в нем, какой url в адресной строке, такой он и использует. Просто если самому написать урл с большой буквы, то такой же каноникал и вставится в страницу. У меня из-за дублирования каноникала возникли проблемы с индексированием, описывал здесь modx.pro/help/12465/#comment-89059
И хотя теперь, после обновления pdoTools дублей быть не должно, в качестве превентивной меры хочу сделать принудительное приведение url к нижнему регистру, но не получается. Вот я и спрашиваю совета, как такое лучше сделать?
И хотя теперь, после обновления pdoTools дублей быть не должно, в качестве превентивной меры хочу сделать принудительное приведение url к нижнему регистру, но не получается. Вот я и спрашиваю совета, как такое лучше сделать?
пользуйтесь на здоровье
case 'OnHandleRequest':
// Приведение к нижнему регистру
$request = $_REQUEST;
$url = $request['q'];
if (!empty($url)) {
unset($_GET['q']);
$params = http_build_query($_GET);
if (strlen($params)) {
$params = '?' . $params;
}
if (preg_match('/[A-Z]/', $url)) {
$modx->sendRedirect(strtolower($url).$params);
}
}
break;
Кстати, ещё одно нововведение осталось незамеченным, которое появилось в версии 2.9.3 — возможность сохранять код в кэше в случае ошибки компиляции Fenom. Только сегодня выловил у себя ещё одну. Когда страниц много — хрен поймёшь где она. А щас открыл кэш и посмотрел. Мне кажется, было бы неплохо в статье это отменить.
Да, это вообще шайтан-фича.
Действительно, дописал.
Не знаю, у одного меня или нет. Но после обновления до последней pl2 версии. Рабочий сайт стал содержать в логах много ошибок:
Визуально причем вроде как все работает. Как выяснить на какое именно место ругается?
Кеш чистил…
[2017-10-24 08:33:17] (ERROR @ /var/www/data/www/poster/core/components/pdotools/model/pdotools/pdotools.class.php : 974) Unexpected tag 'id' in 7e3b12d6e990bd3d8307caca45f688c7 line 1, near '{id' <- there
Визуально причем вроде как все работает. Как выяснить на какое именно место ругается?
Кеш чистил…
— Еще добавили новую системную настройку pdotools_fenom_save_on_errors, которая сохраняет шаблоны при ошибках компиляции в core/cache/pdotools/error/, чтобы вам удобнее было их дебажить.
Спасибо)
Заметил что зачем то обрабатываются настройки медиасорс. Возможно на них ругань.
Стали обрабатываться с изменением
Стали обрабатываться с изменением
Улучшено регулярное выражение для определения синтаксиса FenomВопрос — а нафига они вообще обабатываются? причем в админке.
Согласен, ниже написал, что это породило у меня проблему.
Есть системная настройка pdotools_fenom_syntax, в которой можно указать свою регулярку.
del
Оказалось что ругань идет на
причем как выше Володя писал, это pdoTools выдергивает из источника файлов. Если бы он не трогал источник файлов, то все бы было нормально
[[migxResourceMediaPath? &pathTpl=`assets/MediaGallery/{id}/` &createFolder=`1`]]
. Это динамический источник файлов для Migx галереи. Можно ли гдето добавить в исключение эту конструкцию? {id}
.причем как выше Володя писал, это pdoTools выдергивает из источника файлов. Если бы он не трогал источник файлов, то все бы было нормально
Убери закрывающую фигурную скобку из регулярки.
Да, парсер в MODX проходит даже по настройкам источника файлов, чтобы парсить вот такие конструкции.
Попробуй ради интереса переписать это на Fenom
Попробуй ради интереса переписать это на Fenom
{'migxResourceMediaPath' | snippet : ['pathTpl' => 'assets/MediaGallery/{id}/', 'createFolder' => 1]}
вдруг сработает?
Понятно что сработает. Но это не выход.
Предполагается что все настройки медиасорс должны быть корректны для fenom.
И если это не так — идти их исправлять. Не всегда это вариант.
Как вариант решения этого можно ввести настройку ограничивающую обработку контекста в github.com/bezumkin/pdoTools/blob/master/core/components/pdotools/model/pdotools/pdoparser.class.php#L43
если такой вариант приемлим — я могу сделать pr.
Спасибо!
Предполагается что все настройки медиасорс должны быть корректны для fenom.
И если это не так — идти их исправлять. Не всегда это вариант.
Как вариант решения этого можно ввести настройку ограничивающую обработку контекста в github.com/bezumkin/pdoTools/blob/master/core/components/pdotools/model/pdotools/pdoparser.class.php#L43
если такой вариант приемлим — я могу сделать pr.
Спасибо!
Предполагается что все настройки медиасорс должны быть корректны для fenomОни обычно и так корректны, просто автор MIGX, зачем-то, использует фигурные скобки вместо квадратных, как в MODX принято.
И хозяин сайта включает использование Fenom везде, так что не вижу проблемы использовать его и в параметрах источника файлов в этом случае.
Как вариант решения этого можно ввести настройку ограничивающую обработку контекстаНу а если кто специально хочет использовать именно Fenom в настройках источника — им как быть?
В общем, посмотрим количество отзывов об этой проблеме.
Ну а если кто специально хочет использовать именно Fenom в настройках источника — им как быть?разрешить обработку fenom в контексте mgr
то есть в данном случае речь идет именно о настройке что отключала бы fenom в админке.
Ну ок, в админке оно обрабатываться не будет, допустим. А на фронтенде разве настройки источника файлов не парсятся?
Если хоть один сниппет MIGX грузит этот источник и делает ему initialize() — будут ровно те же записи в логах, и всё равно придётся что-то менять: или регулярку синтаксиса, или настройки источника.
Я просто с MIGX не знаком, поясните, пожалуйста.
Если хоть один сниппет MIGX грузит этот источник и делает ему initialize() — будут ровно те же записи в логах, и всё равно придётся что-то менять: или регулярку синтаксиса, или настройки источника.
Я просто с MIGX не знаком, поясните, пожалуйста.
А на фронтенде разве настройки источника файлов не парсятся?в каком месте они там парсятся?
Если хоть один сниппет MIGX грузит этот источник и делает ему initialize() — будут ровно те же записи в логах, и всё равно придётся что-то менять: или регулярку синтаксиса, или настройки источника.согласен.
Я просто с MIGX не знаком, поясните, пожалуйста.я сам им не пользуюсь.
Я вообще конкретно MIGX в данном случае не касаюсь. Есть конкретная ситуация касаемо обработки настроек в админке парсером fenom и я лишь сказал о том что неплохо ввести ограничение на это и все.
Что с этим делать решать тебе.
Что с этим делать решать тебе.Ограничить не сложно, но хотелось бы понять — есть ли смысл.
Пока, наверное, просто уберу из регулярки такие {теги}, потому что не могу придумать, где они используются в самом Fenom.
Да, текущую проблему это решает.
Спасибо!
Спасибо!
По-моему такой вариант как в — 2.10.1-pl3 является оптимальным,
Fenom перестал детектить случаи когда фигурные скобки использовались в input-ах в атрибуте pattern — например
Просто если привыкаешь к Fenom, то уже само собой напрашивается его использование везде и повсюду и, порой, даже забываешь о местах где он не должен работать.
Сегодня обновил пакет на более чем 10 сайтах, полёт нормальный. Будем наблюдать дальше.
Fenom перестал детектить случаи когда фигурные скобки использовались в input-ах в атрибуте pattern — например
<input type="tel" pattern="8[0-9]{3}-[0-9]{3}">
а также в скриптах на странице, где встречаются конструкции с пустыми фигурными скобками:function(){}
//или
catch(err){}
И при этом остаётся возможность расширять Fenom своими тегами, хоть и приходится вызывать их если они без параметров с пробелом{googlemap}//так тег не работает
{googlemap }//так без проблем
А на счёт работы Fenom в админке, Володин вариант сделать настройку для тех кому это очень надо, по-моему неплохая идея.Просто если привыкаешь к Fenom, то уже само собой напрашивается его использование везде и повсюду и, порой, даже забываешь о местах где он не должен работать.
Сегодня обновил пакет на более чем 10 сайтах, полёт нормальный. Будем наблюдать дальше.
А на счёт работы Fenom в админке, Володин вариант сделать настройку для тех кому это очень надо, по-моему неплохая идея.Тем кому уж очень нужно могут создать плагин и отключить Fenom в админке
// Событие OnHandleRequest
if ($modx->context->key == 'mgr') $modx->getParser()->pdoTools->config['useFenom'] = false;
Ну вот, тоже отличное решение. Просто я бы до него не догадался бы никогда) Поэтому создание настройки мне показалось как удачное решение, требующее менее высокого порога владения MODX
а если у меня весь сайт построен на тегах {mobile}{/mobile} и {desktop}{/desktop}, которые плагином добавляются, не обновляться теперь что ли? весь сайт покрашится?
по-моему проблема с источниками файлов такого не стоит вообще. Если человек включает феном на весь сайт, пофиксить пути в источнике должно быть его ответственностью, как ты и говорил
upd. кстати, ниже всплыл пример использования таких тегов в самом феноме — {ignore}{/ignore}. Крайне нужная штука порой.
по-моему проблема с источниками файлов такого не стоит вообще. Если человек включает феном на весь сайт, пофиксить пути в источнике должно быть его ответственностью, как ты и говорил
upd. кстати, ниже всплыл пример использования таких тегов в самом феноме — {ignore}{/ignore}. Крайне нужная штука порой.
2 варианта
1. Указать свою регулярку в системной настройке pdotools_fenom_syntax.
2. Добавить пробел после тега.
1. Указать свою регулярку в системной настройке pdotools_fenom_syntax.
2. Добавить пробел после тега.
по-моему это неправильно — это нативная работа феном вообще-то, почему ее нужно накостыливать? получается, Бруно ( который Мигас написал) как обычно без оглядки на всех делает по-своему, а мы из-за него убираем каноническую опцию из феном? Уж что-что, а ignore точно должен быть из коробки
по-моему это неправильно — это нативная работа феном вообще-то, почему ее нужно накостыливать?Потому что выше люди писали, что нативная работа, это когда можно указывать такие конструкции без боязни ошибки
<input pattern="\+7\s\(\d{3}\)\s\d{3}-\d{2}-\d{2}"/>
Так что с какой стороны посмотреть.Уж что-что, а ignore точно должен быть из коробкиВ фреймворках он работает без проблем. И если бы ты прочитал мою статью про тег ignore, ссылку на которую давали ниже, то ты бы понял, что Fenom не может работать нативно в MODX. Василий его более менее натянул, но специфика MODX ломает идеальную логику работы Fenom. И поэтому иногда возникают проблемы с выводом конструкции {тег}.
Если не понятно почему в фреймворках работает, а в MODX нет, могу объяснить поподробнее.
В версии 2.10.1-pl3 всё работает как надо и ничего не ломается.
Уж что-что, а ignore точно должен быть из коробкиДобавил PR, который учитывает специфику парсинга MODX. Он решает проблему с ignore — где он бы не был указан (в шаблоне, ресурсе или чанке), он будет работать как от него и ожидается.
ты вот кстати пишешь, что игнор не работает, я замечал это в ранних версиях pdotools с fenom, не уже несколько месяцев как он прекрасно отрабатывал везде где нужно)
больше желчи :) я тут никого не подлавливаю, я про случаи когда надо заэкранить какой-нибудь js или css. В первых версиях игнор не справлялся с этим, потом стал работать. Что касается паттернов — тут я не спорю, но так как ими не пользуюсь никогда в связи с избирательной поддержкой браузерами этой фичи, то и не сталкивался с таким — ни подтвердить, ни опровергнуть не мог бы всё равно. Никакого подстёба в моих словах нет, только наблюдение на тему.
Не хотел отвечать — думал ты стебаешься. А сейчас думаю, ты скорее всего до конца не вник. Не имеет значения, что ты укажешь — паттерн или стили или еще чего с фигурными скобками. ignore не работает из-за специфики парсинга MODX. Попробуй добавить в примере выше (доступ я давал) в секцию HEAD следующий код
{ignore}<style>body {color: red}</style>{/ignore}
Fenom выдаст ошибку компиляции.
Спасибо, помогло решить эту проблему!
Но иногда стала всплывать старая ошибка кеширования, правда крайне редко
Но иногда стала всплывать старая ошибка кеширования, правда крайне редко
Здравствуйте! Подскажите пожалуйста, в чем может быть проблема, не работает Fenom если:
1. На сайт добавлены в хед критические стили CSS (для оптимизации скорости)
2. Стоит добавить на сайт код гугл тег менеджер или аналитику и все ломается(
Вот что получается prntscr.com/h18wxu и prntscr.com/h18x4k, системные настройки prntscr.com/h18x9x
И так на нескольких сайтах, PDO последней версии
1. На сайт добавлены в хед критические стили CSS (для оптимизации скорости)
2. Стоит добавить на сайт код гугл тег менеджер или аналитику и все ломается(
Вот что получается prntscr.com/h18wxu и prntscr.com/h18x4k, системные настройки prntscr.com/h18x9x
И так на нескольких сайтах, PDO последней версии
попробуйте поместить стили и скрипты в тег {ignore}… {/ignore}
спасибо, попробую. А с аналитикой и тег менеджером как быть, тоже можно так поместить попробовать (это не повлияет на работу гугл аналитики)?
можно, ни на что не влияет
спасибо большое помогло. Но возник такой момент теперь, на страничках, где не использовался феном, теперь вылазит на сайте prntscr.com/h1a6ex и соответственно не работает аналитика (сервис показывает ошибку)
нет, это влияет только на то, что fenom не будет обрабатывать содержимое тега ignore.
А он ругается на фигурные скобки. Если ignore не поможет, то просто поставьте в этих местах после открывающих { пробел
А он ругается на фигурные скобки. Если ignore не поможет, то просто поставьте в этих местах после открывающих { пробел
спасибо). Пробовал ранее { пробел для критических CSS, но у меня там было скобок 100-200, я и бросил эту затею (только сейчас вспомнил что можно было автозаменой сделать))). Но возник такой момент теперь, на страничках, где не использовался феном, теперь вылазит на сайте ignore prntscr.com/h1a6ex и соответственно не работает аналитика (сервис показывает ошибку)
Спасибо)
Там написано «Самый просто вариант — указать в шаблоне кэшируемый тег [[*content]]» — у меня в шаблоне так и есть, но теги всеравно вылазят prntscr.com/h1aenk
Там написано «Самый просто вариант — указать в шаблоне кэшируемый тег [[*content]]» — у меня в шаблоне так и есть, но теги всеравно вылазят prntscr.com/h1aenk
там ключевая фраза это:
В общем идея должна быть понятна — тег {ignore} должен присутствовать в итерации, после которой больше не будет тегов Fenom.
пробел для критических CSS, но у меня там было скобок 100-200, я и бросил эту затеюДелается это просто — устанавливаешь modDevTools, в поиске этого компонента вбиваешь открывающую скобку "{" и в поле замены скобку с пробелом "{ ". Заменяешь все совпадения оптом. Всего эти действия занимают минуту от силы.
Всегда это делаю перед тем как включить Fenom на страницах.
По поводу migxResourceMediaPath
Вот такая запись у меня не заработала:
Вот такая запись у меня не заработала:
{'migxResourceMediaPath' | snippet : ['pathTpl' => 'assets/MediaGallery/{id}/', 'createFolder' => 1]}
Рабочая:{$_modx->runSnippet('migxResourceMediaPath', ['pathTpl' => '/images/gallery/{id}{alias}/', 'createFolder' => 1])}
Вдруг кому еще пригодиться.
Выше Василий, еще более изящный вариант предложил. Но и ваш и его вариант работает! Спасибо
Есть один момент не понятный:
Вот такой вызов
В чем может быть дело?
По отладки вижу лимит 10 стоит, но я его не ставил
Дописал 'limit' => 0, но не помню чтобы по умолчанию раньше был лимит в 10
Вот такой вызов
{'!pdoResources' | snippet : [
'tpl' => '@INLINE
<!-- item -->
<div class="col-md-2 col-sm-4 item">
<a href="{$uri}" class="">
{$pagetitle}
</a>
<div class="crest"></div>
<div class="crest2"></div>
</div>',
'showLog' => 1
]}
отладка0.0002561: pdoTools loaded
0.0000691: xPDO query object created
0.0006971: Added selection of modResource: SQL_CALC_FOUND_ROWS `id`, `type`, `contentType`, `pagetitle`, `longtitle`, `description`, `alias`, `link_attributes`, `published`, `pub_date`, `unpub_date`, `parent`, `isfolder`, `introtext`, `richtext`, `template`, `menuindex`, `searchable`, `cacheable`, `createdby`, `createdon`, `editedby`, `editedon`, `deleted`, `deletedon`, `deletedby`, `publishedon`, `publishedby`, `menutitle`, `donthit`, `privateweb`, `privatemgr`, `content_dispo`, `hidemenu`, `class_key`, `context_key`, `content_type`, `uri`, `uri_override`, `hide_children_in_tree`, `show_in_tree`, `properties`
0.0012379: Processed additional conditions
0.0017569: Added where condition: modResource.parent:IN(3,4,5,6,7,8,9,10,11,12,13,14,15), modResource.published=1, modResource.deleted=0
0.0001769: Sorted by modResource.publishedon, DESC
0.0000069: Limited to 10, offset 0
0.0004539: SQL prepared "SELECT SQL_CALC_FOUND_ROWS `modResource`.`id`, `modResource`.`type`, `modResource`.`contentType`, `modResource`.`pagetitle`, `modResource`.`longtitle`, `modResource`.`description`, `modResource`.`alias`, `modResource`.`link_attributes`, `modResource`.`published`, `modResource`.`pub_date`, `modResource`.`unpub_date`, `modResource`.`parent`, `modResource`.`isfolder`, `modResource`.`introtext`, `modResource`.`richtext`, `modResource`.`template`, `modResource`.`menuindex`, `modResource`.`searchable`, `modResource`.`cacheable`, `modResource`.`createdby`, `modResource`.`createdon`, `modResource`.`editedby`, `modResource`.`editedon`, `modResource`.`deleted`, `modResource`.`deletedon`, `modResource`.`deletedby`, `modResource`.`publishedon`, `modResource`.`publishedby`, `modResource`.`menutitle`, `modResource`.`donthit`, `modResource`.`privateweb`, `modResource`.`privatemgr`, `modResource`.`content_dispo`, `modResource`.`hidemenu`, `modResource`.`class_key`, `modResource`.`context_key`, `modResource`.`content_type`, `modResource`.`uri`, `modResource`.`uri_override`, `modResource`.`hide_children_in_tree`, `modResource`.`show_in_tree`, `modResource`.`properties` FROM `pmodx_site_content` AS `modResource` WHERE ( `modResource`.`parent` IN (3,4,5,6,7,8,9,10,11,12,13,14,15) AND `modResource`.`published` = 1 AND `modResource`.`deleted` = 0 ) ORDER BY modResource.publishedon DESC LIMIT 10 "
0.0008991: SQL executed
0.0001900: Total rows: 12
0.0002332: Rows fetched
0.0008690: Created inline "modChunk" with name "376a2e035e8b1e047dd42b7dca5e9d30"
0.0037138: Compiled Fenom chunk with name "modchunk/376a2e035e8b1e047dd42b7dca5e9d30"
0.0051739: Returning processed chunks
0.0106580: Total time
11 796 480: Memory usage
из 12 ресурсов выводится только 10. Настройки публикации в всех в состоянии опубликовано, и показывать в меню. В чем может быть дело?
По отладки вижу лимит 10 стоит, но я его не ставил
Дописал 'limit' => 0, но не помню чтобы по умолчанию раньше был лимит в 10
но не помню чтобы по умолчанию раньше был лимит в 10А он всегда был, хоть ты и не помнишь.
К psoResources в доке так как ты говоришь написано, по умолчанию limit 10, а вот docs.modx.pro/components/pdotools/general-settings тут говорится в общих параметрах по умолчанию limit 0. Вот меня и сбило это столку. Ок понял спасибо
Василий, у меня небольшая просьба! не мог бы ты добавить поддержку файлов .fm для файловых элементов?
Чтобы в phpstorm не привязывать синтаксис fenom к файлам .tpl, а оставить их для smarty, как и было
Чтобы в phpstorm не привязывать синтаксис fenom к файлам .tpl, а оставить их для smarty, как и было
Интересно, зачем? Может Вы нашли или написали плагин для подсветки синтаксиса Fenom в PHPStorm? Тогда, очень прошу поделитесь.
Если же нет, то какой смысл? Оба шаблонизатора близки по синтаксису и со smarty хотя бы какая-то подсветка есть в IDE
Если же нет, то какой смысл? Оба шаблонизатора близки по синтаксису и со smarty хотя бы какая-то подсветка есть в IDE
Ну вот, например, в sublime text есть поддержка Fenom, было бы удобно иметь возможность привязать синтаксис Fenom к .fm
github.com/klkvsk/fenom-phpstorm-plugin вот плагин, он старенький и работает только подсветка, и немного глючный, но всё лучше чем ничего. Василий как-то предлагал подвсетку для смарти, но в этом случае всё в ошибках — всё-таки различия существенные. В этом плагине как раз синтаксис автоматически привязывается к файлам .fm
fenom — 0 ошибок
smarty — 3 ошибки.
Помимо extended он еще тильду не признает и выражения с вопросительным знаком, типа {if $a?} или {$a ?: $b}
Не спорю, сам плагин смарти гораздо лучше. Жаль что нормального под феном нет, постоянная краснота напрягает немного)
так что, смилостивишься добавить .fm? )
smarty — 3 ошибки.
Помимо extended он еще тильду не признает и выражения с вопросительным знаком, типа {if $a?} или {$a ?: $b}
Не спорю, сам плагин смарти гораздо лучше. Жаль что нормального под феном нет, постоянная краснота напрягает немного)
так что, смилостивишься добавить .fm? )
Слева Smarty, справа Fenom.
Второй, похоже, просто вообще не умеет детектить ошибки синтаксиса — вот их и нет. Что бы ты не писал — ему всё в порядке:
Я могу, конечно, добавить в pdoTools хоть какие расширения, но пусть хоть 5 человек об этом попросит. А то прям работа под заказ получается — никому не нужно, кроме тебя.
ну… справедливо, наверное
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.