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

Еще раз — Collections работает с ресурсами. Соответственно, все сниппеты MODX работают с ним.

Если ты перетаскиваешь весь контент в другие таблицы, то какой-нибудь GoogleSiteMap для них карту сайта не построит, а mSearch2 их для поиска не проиндексирует.

Сегодня есть pdoTools, и с его помощью можно выводить данные из любых таблиц, для которых есть схема, но опять же, все его родные сниппеты заточены именно под ресурсы. Например, в pdoResources прописана сортировка именно по publishedon, которого может не быть в другой таблице. А pdoMenu использует карту ресурсов в modX::getParentIds для построения меню.

У меня и данные в своих таблицах

У меня тоже.
Но это у меня и тебя, в наших непубличных проектах.

А теперь представь себе условный miniShop3, который хранит миллионы товаров в своих собственных таблицах. К нему нужно будет поставить и полный набор всех сниппетов для вывода этих товаров, генерации меню, хлебных крошек и т.д.

Как оно, сильно больше Collections будет? Одну документацию писать замучаешься, а потом баги отлавливать и править.

Говорю же, я много об этом думал и пришёл к выводу, что делать подобное не стоит. Ну а если и делать, то как отдельную независимую либу, которую потом интегрировать с MODX.
Собственно, как Андрей Чирко уже сделал с Shopkeeper 4 — и что-то большого успеха на рынке MODX у такого решения не видать.

Где-то во фреймворках есть заранее созданные таблицы под контент? С контекстами, прикрученными картами ресурсов кэша, менеджерами с кастомизацией форм для их редактирования?

Нет, никто так не делает во фреймворках, там ты всё пишешь под себя.

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

Использование modResource в MODX — это единственно верный путь для хранения пользовательского контента в 99% использования системы. А если кому-то это не подходит, нужно поискать другую систему, таков мой вывод.

Выше отписал про это.

Слишком большой объём работы и непонятный выхлоп. Экономически не выгодно.

Как и Tickets, как и miniShop2.

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

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

Я вот до сих пор этого не сделал, хотя одно время всерьёз над этим подумывал, как вектор для развития miniShop.

Ну я в их модели никаких новых типов для документаов не вижу, только CollectionContainer, который расширяет modResource.

Стало быть, храниться в нём будут обычные ресурсы. Вот и подтверждение в процессоре publish на строке 32

$this->resource = $this->modx->getObject('modResource', $id);

Дальше мне копать исходники лень, но вроде и так всё понятно.

Возможность расширения базового функционала никак не является руководством к использованию ресурсов как к хранилищу контента сайта.

Насколько я помню, modResource наследуется классами modDocument, modLink, modWebLink и modStaticResource.

И по умолчанию в админке создаётся именно modDocument. Это не для хранения контента? И все сниппеты заточены именно под вывод этих документов, и для построения по ним навигации. Да и поля у этих документов как-бы намекают: published, pub_date, hide_menu, link_attributes и т.д.

Что бы там Джейсон себе не фантазировал, но как только разработчик доходит до мысли, что нужные ему данные проще хранить в своих таблицах, ему резко перестают быть нужны ТВ, шаблоны, чанки и сам MODX.
Потому что он переходит работать на фреймворки, которые создают таблицы и модели гораздо проще и быстрее.

Это делает pdoPage, которому можно указать &setMeta=`0`

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

Принципиальной разницы я не вижу.

Суть в том, что все объекты зависимые от modResource можно паковать в JSON объекты и переносить их от сайта к сайту, делая обратное воспроизведение.

Всё уже давно придумано, сделано, и работает — modmore.github.io/Gitify/ru/

Очень было бы круто, что если я указываю определенный тег, то ниже код парсится как markdown текст. Я часто готовлю любые тексты в Bear для macOS и в нем архиудобно, но потом приходится переводить текст в теги сайта.

markdowntohtml.com

3 раза прочитать молитву за быстродействие, и 2 раза молитву за стабильность.

Отпускаю с миром.

В догонку на ту же тему — modx.pro/development/3168

Ну так поди нет закрывающего тега </body> или </head>, для инициализации?

Потому что, внезапно, скрипты нужно куда-то вставить, для их работы. И если на странице нет body — то вставлять их некуда.

Даёт возможность авторизации под любым юзером.

Еще раз — нет, не выводит она ничего.

Это после загрузки страницы javascript подставляет количество комментов. Открой исходник страницы и увидишь на месте переменной, что там пусто.

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

Да и дело даже не в скорости, а в том, что при добавлении нового комментария их общее количество изменится, а склонение — нет.

Поэтому лучше или оставить как есть, без склонения, или делать его на js — и тогда total вообще не нужен.

В новых версиях pdoTools общее количество результатов не считается, если не указать это специально, для скорости.
Так что сейчас у тебя нет этой переменной, он пустая, и количество комментариев выставляется через javascript.

Укажи &setTotal=`1` в вызове TicketsComments, и всё должно заработать.

Лучше так:

<img src="{$image ?: '/assets/images/no-image.png'}" class="mw-100" alt="{$pagetitle}" title="{$pagetitle}"/>

Какой же ты занудный, а.

Это по идее должно быть надо любому пользователю шаблонизатора феном на modx,

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

ибо глюки не нужны никому

Отсутствие кэширования чего-либо, это не глюк.

особенно которые на ровном месте занижают производительность.

Голословно. Fenom выигрывает в производительности за счёт других возможностей.

Если нет времени это делать, покажи файлы, части кода где это можно исправить — и кто-то из комюнити исправит

«Покажи», «кто-то исправил» — хорошо устроился. Тебя волнует — ты и исправляй, не жди никого.

дадут тебе обратно исправленный код и выложишь в репозитории

Поставь задачу сообществу

Разрешите выполнять? Бегом?

Нет проблем.

Ну так ты чего тут сидишь, раз нет проблем?

Поэтому без твоей поддержки тут будет сложновато :)

Да вот вообще никакого желания тратить своё время на тебя нет.

Тему закрываю, всё осудили.

Да всё вышло просто:
— Fenom дёргает pdoTools::runSnippet()
— Тот дёргает pdoTools::_loadElement()
— Ну а тот делает modX::getObject() для получения содержимого сниппета из БД

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

Я же написал — используй синтаксис MODX, если тебя в нём всё устраивает.

Не нужна работа с файлами, не нужно наследование шаблонов, не нужны циклы и функции, присвоение переменных — не мучай себя, работай с парсером MODX, раз он супербыстрый.

Может потом вдруг окажется, что из-за костылей с парсером, когда нужно вызвать несколько сниппетов, вместо одного цикла, у тебя просадки по скорости выйдут значительно серьёзнее.