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

Привет, Henk. Спасибо за ответ! В посте по ссылке меня больше всего заинтересовала фраза «мы интегрировали AI в медиа-менеджер, чтобы значительно упростить управление изображениями» (c тегированием и пр.), но я не нашел ссылок на обновленные версии. Это обновления для ваших внутренних-продуктов, или MODX media manager получит обновление для категоризации с помощью AI?

В последней версии MODX 3.1.2 я не вижу даже тегов в mediamanager, не говоря уже о том, что они каким-то образом обновляются с помощью искусственного интеллекта.

Как и где можно потрогать руками хотя бы какие-то результаты хакатона?

— Hi @Henk Everts, thx for answer! In linked post most intesr for me «we integrated AI into the media manager to make managing existing images a whole lot easier» (with tags, etc.) — but i not found links for updated versions. This updates for you intranet products, or MODX media manager will get AI categorize update?

In latest MODX 3.1.2 version i cant see even tags in mediamanager, not to mention that they are somehow updated with the help of AI.

Where or how we can test any hakathon results?

P.S. Еranslated manually for train my english :) sorry for mistakes, may be

Тсс :) Давай потише, а то сбегутся сейчас фанаты MIGX и запинают нас за то, что пытаемся отправить в прошлое эпоху foreach-ей и fromJSON-ов в шаблонах и чанках.

Так-то программирование в чанках с начала времён (появления php-шаблонизаторов) считалось плохой идеей, но MIGX так располагает, что про это многие забыли. Просто fenom даёт слишком много свободы, а MOGX как бы располагал к тому, чтобы этой свободой злоупотреблять…

Так что ты, @Aleksandr Huz тот самый наш герой, который показывает, что мир может быть другим, и код — красивым!
Вы вообще видели этот синтаксис в примерах «Режим разработки» из поста? Анбиливабл эвесамнесс какой-то! Слов нет как круто...

Вау! Это уже в некотором смысле закрывает часть функционала MIGX, который порядком поднадоел, и к тому же не располагает к написанию красивого и качественного кода (к сожалению). С этим обновленным PageBlock будет ещё один повод вместо MIGX выбрать для создания CMP (custom manager page) в админке именно его.

Автору — спасибо! Будем пробовать при случае!

Как прошло мероприятие? Получилось ли прикрыть какие-то issue или подготовить PR в рамках прошедшего хакатона?
@Henk Everts поделитесь, пожалуйста!

Большое спасибо за качественное и подробное описание!

Вообще считаю, что в нынешние времена, веб-аналитика в минишопе должна быть если не из коробки, то хотя бы модулем каким-то готовым. На самом деле конверсии полезно отправлять не только в Метрику, но и в другие счетчики (GA, VK, TMR и даже в тикток пиксель иногда, и другие)

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

Привет! Очень круто, что продолжение идей CatalogFill воплощается в обновленном виде, с поддержкой нового минишопа и другими расширенными возможностями, вроде поддержки MIGX полей и др. Обязательно воспользуюcь при случае!

Пара моментов:
• Для impex3 в документации проверь префиксы таблиц, точно они ms2_?
• А почему выбрал CronManager вместо «нативного» в экосистеме с MiniShop компонента Scheduler и планируется ли поддержка последнего в будущем?

Я делал ровно такое через тегирование, компонентом tvSuperSelect.

На другом сайте клиники пытался сделать через taxonomy, но там что-то пошло не так (вроде с кодировкой русской были проблемы, но уже не помню, было несколько лет назад), и в итоге через TV с подстановкой возможных значений через синтаксис

@SELECT [[!pdoResources? //и тут выбор значений для чекбоксов ]]

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

Тут главное не забывать концепцию MODX, что ресурс — это не обязательно страница. Есть побочный эффект при таком подходе: на одинаковых услугах у тебя будет одинаковый alias, но это легко пофиксить пакетом customURLs, где настраиваются маски alias-ов по разным правилам.

Кастомные цены на одни и те же услуги, чтобы без дублирования самих услуг, наверное удобнее всего через MIGX — услугу подвязываешь через выбор из списка (типа справочника), а цену указываешь руками нужную. Это будет легко вывести в карточке врача. Но если нужно в общем прайсе потом указывать наоборот стоимость услуги разную у разных врачей, то будут сложности с выборкой, то придется либо написать небольшой сниппет, который ходит по врачам и дергает цену на услугу (закэшируй чтобы не тормозило, если много врачей), либо плагинчик, который при сохранении врача пропишет его персональную цену на услугу в MIGX-поле привязанное уже к самой услуге. Плагин получше будет, позволит показывать цену от и до на услугу, что, вероятно, улучшит UX сайта и порадует дизайнера и заказчика))

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

Успехов!

Не понимаю в чём тут «увы».
Перенести товары в категорию (переместить) → возможно встроенными средствами, добавить дополнительную категорию (чтобы товар в двух одновременно лежал) → тоже возможно. И всё это — используя встроенные функции.

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

Кроме того, существуют готовые вспомогательные средства (в т.ч. платные, как недорогие, так и сравнительно более затратные) для ещё более гибкого и быстрого управления этими функциями.

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

Можете уточнить, какого элемента управления вам не хватило? И используемые версии Minishop + MODX, на всякий случай

На всякий случай, по теме: сегодня встретил размер папки кэша pdotools в 106gb. На сайте 3800 записей в таблице БД site_content и всего 125 товаров minishop2. Но есть фильтры и сложные чанки, хотя кода fenom в контенте нигде нет.

Может кому пригодится для ориентира по возможным размерам этой папки…

Решил отключить там настройку pdotools_fenom_cache, но cache_resource оставить включенной. На тестовых страницах замедления не заметил. Такой вот кейс.

pdoTools 2.13.2-pl под MODX 2.8.3

вручную прощёлкать 300 товаров

Не обязательно :)

Если футболки размечены параметрами или опциями, и в них указаны, какие Черные, а какие Белые по признаку «цвет», и например С принтом или Без принта по признаку «тип», то удобнее создать отдельный шаблон «подборки товаров» и использовать его для страниц данного вида в паре с настроенными выборками через msProductsComposerSelection либо без него, если передать в вызов msProducts или mFilter через параметр &where или &tvFilters нужные данные для выборки иным способом (к примеру через ещё одну TV или опцию ms2)

MODX очень гибкий, всегда есть несколько решений. Даже если разметки характеристик у товаров нет, и прокликивать и размечать 1000 товаров не хочется то, хоть и не так точно и красиво, но всё-таки можно выбрать товары по названию через &where по маске «черн*» и «с принт*», а в случае недостаточной скорости — закэшировать всё это. И возможно, даже обновлять кэш в фоне через, например, scheduler

Привет! Спасибо за полезный апдейт. Так глядишь и совсем забудем когда-то популярный компонент Login и даже возможно Office — потому что таких удобных фишечек там нет, а костыли уж надоели :)

Да всё верно! Читать доку да, но её не обломно читать когда подготовкой данных занимаешься, а когда верстка разъезжается или 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. Я не могу сменить свою оценку в твоем посте про ИИ когда она скрыта. Являясь местным активистом, всё-таки я не админ здешнего форума и к скрытым заметкам доступа у меня нет.