Сергей Шлоков

Почему-то не хочет работать такая конструкция

[[!pdoResources?
    &parents=`0`
    &tpl=`@INLINE <p>{$id} - {$pagetitle} {$createdon}</p>`
]]

Все переменные выводятся пустые. Версия pdoTools последняя. Все разрешения включены. Проблема только с INLINE чанком. Если указать обычный чанк с таким же содержимым, то всё работает.

Не знаю. Дайте ссылку на сайт.

Самое простое решение всего в одну строчку

echo base64_decode('0J/QvtC00LDRgNC+0Log0YMg0YLQtdCx0Y8g0LIg0YLRg9Cw0LvQtdGC0LUgKQ==');

Не, тут календарь вряд ли поможет. У событий календаря нет связи с ресурсами. В следующей версии я планировал добавить вызов пользовательского сниппета при формировании календаря, чтобы добавлять свои события в календарь. Думаю, можно было бы в сниппете прописывать эту связь. Только так.

А зачем для этого нужен календарь? Тем более вместо сетки нужен виджет. Выставь у ресурсов TV с датой и выводи своим сниппетом те ресурсы, у которых сегодняшняя дата.

Ну в данном решении я не стал бы делать акцент на файловые элементы. Это всего лишь 4 модификатора фенома, которые дополняют список твоих модификаторов объектов — user, lexicon и resource. Причем для чанков и шаблонов не пришлось писать ни строчки — используется функционал pdoTools. Добавил только для сниппетов. А загрузка элементов из файлов — это всего лишь одна из возможностей.

// Вот загрузка чанка MODX
{'myChunk' | chunk}
// Вот inline чанк
{'@INLINE <p>Динамически созданный чанк</p>' | chunk}
// Вот загрузка шаблона MODX
{'@TEMPLATE myTemplate' | chunk}
// Тоже самое
{'myTemplate' | template}

Работа только с элементами MODX.
Единственный момент — метод initPlugin(). Вот он нужен конкретно для работы с файлом плагина. Если его убрать, то добавляются всего лишь модификаторы для работы с элементами.
П.С. Вникаю потихоньку в Fenom. Очень нравятся его возможности.

Видимо ты прочёл это как «ни в коем случае ничего не присылай!»

Так точно. Ведь ты написал «Давно уже об этом думаю». И после ответа «Нет, не ускорит», я решил, что ты уже продумал эту тему и как появится время сделаешь.
Поняли друг друга называется. )

П.С. Чего-то у меня в FF комментарии добавляются только после обновления страницы.

Обычно принято присылать PR, но тебе же не терпится.

Я только за. Я тебе в той же теме и намекал по PR. Ты ответил отрицательно. А пакет сделал как раз для того, чтобы тебя не отвлекать от дел. Мне торопится некуда. Сайт у меня и так уже работает с этим функционалом. На нём я и тестировал.
PR гораздо лучшее решение, чем пакеты. Ничего своего пилить у меня желания нет. Потом допиливать и перепиливать. Тем более, что мне всего хватает в pdoTools. Ну почти всего. )
П.С. Мы уже больше 3-х лет общаемся. Не проще было сказать «Пришли PR, гляну» вместо слов о рекомендациях modstore не ободрять пакет, про отсутствие будущего и ещё много много других малоприятных слов?

А будущего нет, потому что этот функционал рано или поздно появится в оригинальном pdoTools и далеко не факт, что он будет совместим с твоим.

Я всего лишь добавил 4 модификатора. Ни один из них сейчас не используется в pdoTools. И логика у них наследуется от pdoTools, в отличие от моего первого варианта в предыдущей статье.

Функционал загрузки чанков из файлов там был давным-давно, распространение его на остальные элементы — дело времени и спроса. Которого, кстати говоря, не так-то и много.

Был и есть, но использовать его можно только в параметрах сниппетов. Я сделал такую возможность через модификатор, который вызывает метод pdoTools::getChunk(). Только и всего.
А по спросу… всё-таки не правильно решать это за пользователей. В магазине есть пакеты, количество скачиваний у который ниже 10.

На мой взгляд неуважительно называть свой компонент pdoToolsPlus.

Теперь понятно откуда такая реакция. Приношу извинения. Готов переименовать. Просто я исходил из логики, что это расширение pdoTools. Его нельзя поставить без pdoTools. Как в своё время я делал TicketMessages. Как сейчас называют пакеты для miniShop2. Такое название, например, ptElements будет допустимо?

Выполнение произвольного PHP кода без доступа к сниппетам через @CODE — это большая дырка в безопасности.

Эта возможность отключается ключами «pdotools_fenom_modx» и «pdotools_fenom_php». Для выполнения кода создается временный сниппет MODX. Могу ошибаться, но мне кажется, что безопасности здесь не меньше, чем в обычных сниппетах.

Комментирование тегов в Fenom делается через звёздочки.

Не знал. Не нашёл в документации. У себя комментировал через HTML комментирование.

Я рекомендовал modstore.pro не ободрять этот пакет, потому что будущего у него всё равно нет

Вот это странный приговор. Звучит, мягко говоря, очень неуважительно.

В первом случае ругается феном. Найди место, где используется {«class» и поставь пробел после скобки. Ну или отключай феном.

Чтобы феном работал в шаблонах, нужно включить pdotools_fenom_parser (Использовать Fenom на страницах). А вот pdotools_fenom_modx включать не обязательно.

Значит их надо закрывать в robots.txt.

Интересно каким образом это попадает в индекс. Робот же бегает по ссылкам, а не по папкам.

Честно говоря не совсем понял о чем идёт речь.

Может пулреквест ускорит процесс? )

Василий, а как ты смотришь, чтобы добавить этот функционал в pdoTools?

Тест.
Если бы вы были на месте Миколы Питерского, как бы вы закончили фразу:
— Деточка, а вам не кажется, что ваше место…

а) возле мамаши		б) справа от Путина
в) на белом коне	г) занято

Кстати, изначально хотел сделать вызов сниппета с модификаторами как в pdoTools для чанков

// Вызов из файла
$pdoTools->runSnippet('@FILE snippet', $properties);
// Динамически создаваемый сниппет для маленьких сниппетов
$pdoTools->runSnippet('@INLINE return date('Y-m-d', $scriptProperties['createdon']);', $properties);

А если модификаторов нет, то pdoTools запускает $modx->runSnippet(). Но потом решил, что includeSnippet() понятнее, а динамические сниппеты — не нужные излишества.
А вы как считаете?

Я не знаком с modxSmarty. Если он всё это уже умеет, то какой смысл его повторять. Кроме того, вот-вот должен выйти MODX 3. По-моему, там в базе только контент, остальное в файлах.
Мое решение можно использовать и для шаблонов. Создать один единственный шаблон и в нем вызывать сниппет, в котором определять всю логику для страниц. Например, так

{set $rid = $_modx->resource.id}
{'getTemplate' | snippet : ['resource'=>$rid}

А с этим сниппетом работать в редакторе. Или чанки прописать и работать с ними. Смотри мой пример шаблона.

TV вообще нет смысла выносить в файлы. Они являются расширением таблиц.

А вот с плагинами всё сложнее. Но придумать что-то можно. Вопрос, насколько это получится юзабительно.