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

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

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

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

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

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 получилось кстати. Только опять же, со срабатыванием каждый год. На самом деле для ежегодных праздников твой вариант подходит конечно идеально!