Ну я писал про свой PR. И именно в нём Джейсон и высказался наконец-то. Ибо в Слаке он тогда ответил «нафиг», а на просьбу объяснить просто забил.

Спасибо.

Было бы здорово создать системные настройки с указанием списков доступных полей ресурса и чанков для вывода фильтров, чтобы не выводилось лишнее. Вряд ли кому-то захочется фильтровать ресурсы по alias_visible или link_attributes)

Современные тенденции требуют использования модных JS фреймворков. И тут я полностью выключаюсь из процесса ибо я не дизайнер, не верстальщик и у меня нет большого опыта работы с Vue/React/Angular и т.п. фреймворками.

Тебе и не надо работать с фронтендом, в первую очередь нужно написать API — а это бэкенд на PHP.

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

спасибо, а то

поставил жирную точку

пугает

А идея с админкой — это альтернатива, которая полностью исключает необходимость обращения к этому товарищу.

— да будет так! Очень интересно.

Этот PR завязан на того же Джейсона. Требуется его благоволение, чтобы добавил. Да ещё и вопрос куда. В третью версию — значит выбросить в пропасть. А во вторую вряд ли добавил бы.
А идея с админкой — это альтернатива, которая полностью исключает необходимость обращения к этому товарищу. Это просто обычный компонент, но не совсем обычный. ))

Современные тенденции требуют использования модных JS фреймворков. И тут я полностью выключаюсь из процесса ибо я не дизайнер, не верстальщик и у меня нет большого опыта работы с Vue/React/Angular и т.п. фреймворками. Могу чисто языком поработать ))

и поставил жирную точку

… а без этого PR идея описанная в топике нежизнеспособна?

То, что они всё-равно подгружаются, а потом скрываются. Они всё-равно есть. Это всё-равно костыль. Но суть не в этом. Суть в том, что практически всё хранится в modx_site_content + куски распиханные по таблицам ТВ. А я хочу разделять разные типы данных. Есть у меня список магазинов, которому не нужны ни longtitle, ни introtext, но нужны координаты — сделал отдельную таблицу в базе с нужными полями. Когда база в удобоваримом виде, многое становится проще и работает быстрее.

По моему опыту скажу, что было бы отличным решением разработать, что сейчас делает Дмитрий Лукьяненко: Evo с Laravel.

Таких как Дмитрий в лагере Revolution не нашлось. Именно поэтому и был предложен более простой вариант. Но я не уверен, что даже этот вариант сообщество потянет. Это раз.
А в третьих, что там напилит Дмитрий покажет время. И если напилит. И то что получиться, думаю, будет интересно ему и ещё троим-четверым (не в обиду Дмитрию). И пока Revo не скатилась до уровня Evo нужно принимать срочные меры. Иначе через несколько лет его постигнет судьба младшего брата.

и что мешает вывод данных полей отключить и не видеть их, если они так тебе мешают?

После публикации этого поста Марк обратил внимание на мой PR (@Иван Бочкарев приложил руку) с возможностью расширения класса modX, дающий разработчикам больше контроля над ядром, ибо можно создать свой класс приложения и не ждать милости от core-разработчиков. Марк высоко оценил данную возможность.
Но вот пришел главный и поставил жирную точку. Цитата:

I am not necessarily in favor of making the modX class itself more extensible, at least not in the current architecture. We already have too much flexibility at times.

Т.е. MODX и так слишком гибкий. Харэ.

I'm concerned that encouraging extensions to the modX class would open up a whole new set of problems and make upgrade paths even more difficult.

Каким боком разработчика ядра должно касаться то, что делает пользователь MODX, самостоятельно расширяющий систему. Твоя задача дать эту возможность, а дальше не твоя забота. Но нет, ни в какую он (Джейсон) не хочет давать контроль над ядром, даже на уровне пользователя.

I'm also not a fan of using static instance methods to retrieve MODX as a dependency. Dependencies should be explicit, in my opinion.

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

Ну что я могу сказать. Этот человек делает всё, чтобы MODX остался там, где он есть.

Я сам должен определять набор полей. Надо longtitle и introtext для какого-то типа даннх — сделал. Не нужно это — не делаешь. Из коробки должен быть только минимальный набор. Наличие дополнительных полей когда-то было для меня главной фишкой MODx, но сейчас их реализация не радует.

Два раза пишут одно и тоже в поле pagetitle / longtitile

Зачем? можно написать чтото типо такого:

{$_modx->resource.longtitle ?: $_modx->resource.pagetitle~' | '~$_modx->config.site_name}

title нужен в первую очередь для SEO и он может отличаться от заголовка страницы

Если данные поля именно ты не используешь, это не значит, что их нужно выпелить за ненадобность, мне недавно написал один человек который каждую страницу на сайте хранит в отдельном шаблоне))) понятное дело, что так тоже както «работает», но это не есть верная и правильная практика 😉

Хм, у меня pagetitle — title, а longtitle — h1, а Вы как делаете?

Скажите, а как при таком подходе заполняют контент-менеджеры?
Два раза пишут одно и тоже в поле pagetitle / longtitile, ведь далеко не все страницы имеют тайтл отличный от h1? Ну и плюс MODX генерирует url по полю pagetitile, а в нем находиться title, который по определению обычно более длинный чем h1 и будут получаться очень длинные URL.
Я делаю так h1 — это pagetitle, а в head проверка — если longtitle пуст то берем в title значение тоже что и для h1, если заполнен — то ставим в тайтл значение из longtitle.

Проблема решена, благодаря вот этому посту — forums.modx.com/thread/92071/pdoresources-and-tvfilters#dis-post-513666
Получается, что мой TV на этапе вывода все-таки не был в unix формате, хотя уже на выходе был в нем.

А мне достаточно pagetitle. Более того мне иногда и Content не нужен, я уж не говорю про introtext и description.

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

Хм, у меня pagetitle — title, а longtitle — h1, а Вы как делаете?

switch($modx->event->name) {
      case 'OnDocFormPrerender':
                $classes = ['msProduct', 'msCategory'];
                if (in_array($resource->get('class_key'), $classes)) {
                    $template = $resource->get('template');
                    $templates = [1,2]; // Список шаблонов в которых нужно скрыть поле Содержимое

                    if (in_array($template, $templates)) {
                        $modx->regClientStartupHTMLBlock('
                        <script type="text/javascript">
                            Ext.onReady(function() {
                                var content = Ext.getCmp("ta");
                                content.hide();
                            });
                        </script>');
                    }
                }
                break;
}

tvPrefix, как я понимаю, тут не при чем. Он в параметре where не используется.

А про "документы\мероприятия" — это я так про ресурсы написал. Сайт с анонсами мероприятий.

добавить
tvPrefix=>''
не забыли?
Кстати расскажите, а что это в MODX за документы/ мероприятия такие?