Дима Касаткин

Да всё верно! Читать доку да, но её не обломно читать когда подготовкой данных занимаешься, а когда верстка разъезжается или js-компоненты шаманишь, оформляя чанки — читать бекендовую доку уже может головы не хватить :)

Очень рад, что смог донести идею! Спасибо за внимание! Желаю успехов, тебе и компоненту!

Ну да, лучше, причем намного, если искать по первым буквам глазами. С группировкой будет ещё лучше, но это уже. Я в 90% случаев использую поиск через Crtl+F, но это когда знаешь название, а когда не знаешь — только вычитывать, и ровные колонки тут выигрывают у любых мясных кнопок))

… возможно к каким-то JS-библиотекам и т.п.)

Короче говоря последнее, что я хочу (и могу) делать на этом этапе, это снова заниматься программированием — разбирать данные из массивов, сверяться с документацией по бекенд-технологиями (таким как PageBlocks, искать там кастомные модификаторы) — мне хватает того, что для простых преобразования в стиле (:lowercase или :ellipsis) у меня открыта документация по фильтрам вывода (в плюс к тому набору выше).

Поэтому использование в вызове чанка специализированный модификатор (:pbJson) — это прекрасно, что такая возможность в принципе есть, но пока не освоишь инструмент очень глубоко (и не забудешь через год, когда на поддержке вернешься к проекту и надо будет добавить присоединение какой-то таблицы) про это в нужный момент не вспомнишь и встрянешь — это совсем не то же самое, что в сниппет pbResources передать нужные параметры для полноценной подготовки данных для их последующей верстки и оформления. Потому что при любом раскладе, когда работаешь с данными, ты пойдешь в документацию (или код) сниппета и посмотришь возможные параметры, отвечающие за подготовку данных и раскладывание по чанкам. Так почему бы не дать возможность избавиться от программирования в чанке и как альтернативу перенести вызов этого модификатора в подхватывающиеся по шаблону (префиксу) параметры вызова сниппета — тогда вся подготовка данных будет происходить в одном месте (вызове сниппета), а всё оформление — в другом (в чанках). Аналогично тому, как например в mFilter2 можно указывать кастомные чанки row и outer для любых полей, просто добавляя их в параметры вызова прямо по именам, задаваемых в этом же вызове — это почти также красиво и понятно в коде, как твоё @Aleksandr Huz описание содержимого табов в PageBlocks))

А тот момент, что у одной задачи есть несколько вариантов решений, как раз и делает инструмент по-настоящему гибким!

Спасибо за отклик!

Ну хоть что-то, хоть это и немного не то ;)
Попробую пояснить: Когда я занимаюсь интеграцией макетов с админкой, я включаю «режим разработчика» — открываю документацию (или справку/код других проектов), хожу по шаблонам и расставляю вызовы сниппетов, где в этот момент я полностью работаю с данными — их выводом, преобразованием, разбором массивов и прочим, и раскладываю данные по чанкам. Может даже где-то пишу свои модификаторы вывода для сложных случаев. В этот момент я почти не смотрю на фронтенд, меня мало интересует верстка и стили, главное вытащить нужные данные из админки (из БД, конечно).

Далее, я иду в чанки, и там уже добавляю к данным оформление. В этот момент я «включаю режим фронтендера верстальщика»: меня в большей тепени беспокоит как выглядят данные, какие отступы, сходится ли с макетами, у меня открыта совсем другая документация (MDN, возможно SASS, дока к моему фронтенд-фреймворку, возможно к каким-то

На этом скриншоте ещё визуально хочется выровнять по левому краю надписи внутри кнопок.

Когда кнопок мало (одна, две) надписи в центре смотрятся гармонично, а когда много, ищешь глазами название, а они все начинаются на разной вертикальной оси — когнитивная нагрузка возрастает, поиск усложняется и замедляется.

@Aleksandr Huz рассмотри плиз возможность сделать выравнивание надписей!

P.S. Я такое уже встречал, когда занимался пакетом Formalicious — видимо в дизайне админки MODX никто не планировал много кнопок)) На скриншоте в той заметке тоже некрасиво, я позже исправлял…

Вау, какой красивый и короткий код! Там где описане содержимого вкладки — просто магия какая-то! Давненько такого не видел))) Спасибо!

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

Думаю это выглядело бы примерно так:

{'!pbResources'|snippet: [
    ...
    'tables' => 'seo_list as list' // Присоединяем таблицу seo_list и заменяем имя на list
    'tpl_list' => 'list-data-item' // С префиксом tpl_ используется alias присоединенной выше таблицы. Если параметр не указан, list будет доступен как массив.
    'tpl' => 'pb-seo-card', // Чанк вывода
]}

Зачем это нужно?

Кроме избавления от циклов в коде для лаконичности и сохранения удобного MODX-стиля раздельного оформления повторяющихся элементов, который и так изрядно потреплен частым злоупотреблением гибкостью fenom-а) — ну, как минимум, дополнительно можно получить более глубокое кэширование и переиспользовать чанки где-то ещё в проекте.

А ещё там внутри чанка можно сделать доступным {$idx} и {$total} (его, возможно, и снаружи, с префиксом типа list_total или как-то так) чтобы не городить их опять же в коде чанка, который для разметк (aka верстки) предназначен, а не для логики.

Это конечно не правка бизнес-логики компонента, а больше к Developer Expierence, но вроде всё так красиво реализовано для разработчиков (уже), что такая вишенка на торт возможно придется кому-то (вроде меня :) ) очень кстати!

Не успел поставить лайк заметке, напишу тут: Спасибо! За отличное обновление!

Я думаю телега-чатики не навсегда заменили основной канал общения сообщества, поэтому портал надо поддерживать и развивать! Даже телеграм уже делал несколько попыток интегрироваться с веб-средой и думаю у нас ещё будут интересные механики, которые можно будет использовать для слияния чатовой и форумной аудитории. Извините за слегка маркетингово-булшитовое изложение, это уже проф. деформация))

Реквестирую все-таки test stage для себя, чтобы была возможность поддержки проекта кодом!

Пока что по теме кажется что только обфускация будет 100% рабочим решением, если не повышать требования к хостингу. А если повышать, то мне кажется проще клиент-серверную архитектуру реализовать и всю бизнес-логику положить в сервер а на MODX сделать клиент, и распространять (продавать) сервер как docker-контейнер, в котором вообще весь код логики хоть в ioncube хоть в zend, зашифровать, хоть в бинарник вместе с веб-сервером скомпилить.

Это похоже на более-менее future-proof решение, а докер есть сейчас ну почти на любой микроволновке :) ну и его при таком подходе заменить можно на чисто по API работающее нечто своё. Короче, открывается масса прекрасных возможностей. Хотелось бы твоё мнение на этот счет. Особенно после запуска FacetSearch я думаю некоторый опыт уже сложился у нас, надо его использовать!

Привет! Тоже интересуюсь этой темой, заинтересовал твой коммент:

Вообще рекомендуют выпускасть минимально рабочий вариант ПО и меня терзают сомнения, до какой части реализации дойти и какую часть реализации выпустить

А кто-где рекомендует? Я бы изучил мат. часть, потому что тоже планирую несколько релизов, но слабо разбираюсь в выпуске ПО на продажу, делая уже много лет типа «заказного ПО». Дай каких-нибудь ссылок на то, где ты это вычитал, плиз.

Нам нужен профсоюз! :))

P.S. Я не могу сменить свою оценку в твоем посте про ИИ когда она скрыта. Являясь местным активистом, всё-таки я не админ здешнего форума и к скрытым заметкам доступа у меня нет.

Крутые обновления! Просто класс! Спасибо!

Хотел уточнить:

Scheduler… Для MiniShop3, я (что логично) планирую и дальше использовать эту систему, дополнив ее новым заданиями. Но как оказалось компонент не поддерживает MODX3 — а значит мне придется выпустить аналог.

Есть предложение поддерживать Fork, а не плодить компоненты!
У меня даже есть концепт, как отличать компоненты, у нас есть постфикс версии, как правило это -beta или -pl (и даже -pl2 и т.п.). Я анализировал код установщика и не нашел никаких опасных привязок к этим постфиксам.

А значит, мы можем использовать постфикс в стиле:
Scheduler 1.4.1-pl → Scheduler 1.4.1-modx-pro, где modx-pro — github-логин автора форка. Довольно системно получается, и ничего не сломает. Можно использовать и в других компонентах аналогично!

После этого спокойно выпускать новые версии, не оглядываясь на оригинальный пакет. Раз уж там не понятно почему, не принимают PR-ы (вроде этого), из-за чего, полагаю @Николай Савин и не рассматриваешь изначально затащить туда поддержку MODX3 (хоть она и заявлена у оригинального автора).

Что скажете, коллеги?

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

Есть есть желание работать в таком режиме, посмотри на FrankenPHP worker mode → вроде то, что то описал по поводу переиспользования настроек без похода в базу и т.п… Но по-моему это перебор. Потому что приличные SSD/NVME диски уже давно кладут в память часто используемые данные (это будут файлы кэша), а файловое кэширование в MODX есть по умолчанию — просто используй кэш, когда тебе нужна эта магия :) Какое еще ещё нафиг NodeJS?! Я не говорю, что он плохой, просто говорю что незачем лезть в другую вселенную, чтобы получить хорошие показатели скорости!

P.S. А вот сервер на windows (подсмотрел твоё соседнее собщение) очень даже может быть причиной проблем со скоростью. Там нужен особый тюнинг, для которого не так уж много рецептов. Я встречался с таким, победить не получалось, переезжали.

Полностью согласен с недостатками реактивных фреймворков, описанных в заметке, думаю 100мс на инициализацию бекенда это очень много — что-то не так с хостингом, или что-то очень тяжелое прикручено в плагинах на события onmodxinit или где-то ещё по пути до рендеринга. Про то, что фронтенд-часть весит какие-то огромные мегабайты, я писал также в комментах под mmxForms — но в принципе, для какого-то функционала админа, или зарегистрированного пользователя.

У меня на проектах по 20-30мс на полный ответ сервера, без какого-то рокет-турбо-тюнинга (а с ним — быстрее, но сейчас не об этом).

Мне пока удаётся в большинстве проектов убегать от этих адских фроентенд-фреймворков. Надеюсь удастся полностью пережить их рассвет, встретить закат, и классно-здорово работать на набирающем популярность (снова) серверном рендеринге технологии HTMX, которая отлично ложится в концепцию того, как работает MODX, с чанками, крутыми шаблонизаторами и т.п.

P.S. Тоже интересно, для чего реально используешь @Александр Туниеков gtsAPI. Задумка интересная. Не переписываешь ли потихоньку всю админку на формы VUE? ))

Спасибо что делишься!

Вообще чем-то похоже на работу пакета BannerY получилось кстати. Только опять же, со срабатыванием каждый год. На самом деле для ежегодных праздников твой вариант подходит конечно идеально!

Пользуюсь похожей конструкцией, чтобы редактировать TV-шки с фронта. Отличный пример допиливания полезного функционала под проект, спасибо!

P.S. Поправь плиз отступы в форматировании кода во 3 и 4 блоках, а то я shift+tab чуть не нажал машинально, когда читал :)

Ух ты! Осенний код подъехал, спасибо! Всегда жара с заявками в праздники, может и пригодится!

Тоже решаю такие квесты регулярно, поэтому позволю себе задать вопрос)

Просто интересно, а ты не пробовал стандартные для Revo планируемые даты публикации прикрутить для этих целей как-то?

Имею в виду перед тем, как решение выработал. Сниппет конечно круче, т.к. он универсальный, один раз поставил, и будет срабатывать каждый год))

Тоже горожу сниппеты, но сейчас подумал, что по-простому кажется можно было типа такого

[[#8.published:is=`1`:then=`[[#8.content]]`]]

выводить в шаблоне страницы, а в стандартных полях ресурса (с id=8 из моего примера) ставить планируемую дату публикации, и снятия с публикации, вот эти:


Как думаешь, @Денис Усманов, рабочая это схема для одноразовых событий?

Привет! Спасибо за решение, сорри не могу плюсануть уже, время прошло, вовремя не заметил!

Я же правильно понимаю, что можно не делать одноразовый сниппет, а просто запустить его код через компонент Console или подобный?

И ещё есть вопрос по SEOSuite, пользуясь случаем. Они там решили вопрос с тем, что компонент создаёт большую секцию своих настроек в админке для каждого ресурса? Там эта секция была выше, чем секция с основным контентом (и соответственно с секцией TV-шек, если их системной настройкой `tvs_below_content` перенести тоже на первую вкладку в админке где страницы редактируешь) и из-за этого осложнялось редактирование контента на мой взгляд (SEO-настройки маячили и лишний раз мешались). Помню из-за этого даже кто-то ставил старые версии, SEOtab вроде… и ждали фикса, сообщив разрабам на github. Это пофикшено в свежих SEOsuite?

В примерах выше просили вывод ShowLog. В твоём случае нужно сделать то же самое. Естественно, нужен полный вывод. А то твой обрывается на тайминге 0.0152969 (это в секундах, довольно быстро).

Возможно у тебя тормозит что-то другое, попробуй поставить debugParser и открыть страницу с параметром &debug=1 из-под админа и кидай сюда таблицу.

P.S. Нормальный такой некропост спустя 10 лет, но в целом почему бы и нет))

UPD: Так на сайте и страницы каталога переключаются по 20секунд. Это надо дебажить уже сам mSearch2 (mFilter2 вернее). Как правило, где-то там в чанке лежит нечто очень медленное…

Степан, спасибо что поделился!
Проверь плиз заголовок, что-то с ним не так)
Предлагаю допилить вот так: «[ruAgo] Дорабатываем output filter ":ago" на склонения по-русски»

Привет! Автопубликация это круто! Спасибо за компонент!

Есть ряд вопросов перед стартом:

Планировщик встроенный, или интеграция с компонентом scheduler? Нужен cron или на хитах? Если второе (без cron-а), то настройки увеличения количества хитов в промежутках между запусками для сайтов с большой посещаемостью есть?))

А картинки-видео из TV нестандартных типов (image+ например) поддерживаются? А галереи на MIGX?

Можно привести текст из этого файла readme.txt здесь хотя бы?
Не всегда под рукой есть тестовый сайт ведь!

Привет! Если это было связано с багом/фичей компонента, а не с особенностью вашего конкретного сайта и кастомных доработок — было бы здорово получить наводку, куда копать в случае проблем, спасибо!