
Дима Касаткин
С нами с 09 июля 2022; Место в рейтинге пользователей: #414 часа назад
renderif — только вчера думал, что было бы здорово как то это реализовать, а оно само появляется в обновлении. Класс!
Новые возможности PageBlocks: улучшенная работа с блоками, таблицами, полями и мультиязычностью 3
25 марта 2025, 14:22
Добрый день!
В последнем обновлении есть «Уведомления о скором сгорании бонусов», вопрос, а не планируется еще функционал уведомления клиента о начис...
[msBonus2] 1.3.0 Бонус-коды, уведомления о сгорании и совместимость с msMultiCurrency 5
24 марта 2025, 18:43
Насколько я помню msMCD не перерисовывает корзину, а точечно обновляет данные, вероятно для этого на html-блоках с этими данными должны быть атрибуты ...
В миникорзине msMCD обновляется цена и счетчик на лету, а pagetitle и изображение только при обновле... 3
24 марта 2025, 13:04
Наверное стоит проверить пути в модуле оплаты, особенно если мишишоп версии 4.*.*
Проблема с оплатой 1
23 марта 2025, 18:52
Спасибо, поискал инфу и тоже понял, что дело в login. Написал posthooks
<?php
// Получаем данные из запроса
$aboutMe = $modx->getOption('about_...
Проблемы с CKeditor? сбрасывает html теги 2
22 марта 2025, 22:21
Зачем проверять допустимое количество файлов в цикле оно же не меняется?Ты прав, эту проверку можно вынести из цикла)
Простая drag-n-drop зона для отправки файлов с помощью FormIt 7
21 марта 2025, 15:36
Круто. А я слона не заметил :-) разбираться с шаблонами политик полез :-)
Хотя в курсе же был что доступ только на процессорах проверяется. Но засомн...
Какие права доступа нужно давать пользователям для удаление своих записей 3
20 марта 2025, 22:37
Они свой сервер защищать хотят видимо
Необходимо доработать API сделанное на modx, добавить блокировку по IP при частых запросах. 3
Пара моментов:
• Для impex3 в документации проверь префиксы таблиц, точно они ms2_?
• А почему выбрал CronManager вместо «нативного» в экосистеме с MiniShop компонента Scheduler и планируется ли поддержка последнего в будущем?
На другом сайте клиники пытался сделать через taxonomy, но там что-то пошло не так (вроде с кодировкой русской были проблемы, но уже не помню, было несколько лет назад), и в итоге через TV с подстановкой возможных значений через синтаксис То есть к врачу галочки ставишь, какие специальности, потому что специальностей список конечный, а врачей как будто нет. Услуги и цены создавал ресурсами, через настройку форм убирал лишние поля. Там где надо было схлопнуть дерево в админке, использовал компонент Collections.
Тут главное не забывать концепцию MODX, что ресурс — это не обязательно страница. Есть побочный эффект при таком подходе: на одинаковых услугах у тебя будет одинаковый alias, но это легко пофиксить пакетом customURLs, где настраиваются маски alias-ов по разным правилам.
Кастомные цены на одни и те же услуги, чтобы без дублирования самих услуг, наверное удобнее всего через MIGX — услугу подвязываешь через выбор из списка (типа справочника), а цену указываешь руками нужную. Это будет легко вывести в карточке врача. Но если нужно в общем прайсе потом указывать наоборот стоимость услуги разную у разных врачей, то будут сложности с выборкой, то придется либо написать небольшой сниппет, который ходит по врачам и дергает цену на услугу (закэшируй чтобы не тормозило, если много врачей), либо плагинчик, который при сохранении врача пропишет его персональную цену на услугу в MIGX-поле привязанное уже к самой услуге. Плагин получше будет, позволит показывать цену от и до на услугу, что, вероятно, улучшит UX сайта и порадует дизайнера и заказчика))
Там все операции сводятся к перекладыванию JSON для MIGX и простейшим выборкам ресурсов, так что бояться такой кастомизации не стоит.
Успехов!
Перенести товары в категорию (переместить) → возможно встроенными средствами, добавить дополнительную категорию (чтобы товар в двух одновременно лежал) → тоже возможно. И всё это — используя встроенные функции.
Также можно, используя встроенные возможности выборки товаров, без какого-либо программирования, организовать подгрузку на нужную страницу товаров по определенным параметрам.
Кроме того, существуют готовые вспомогательные средства (в т.ч. платные, как недорогие, так и сравнительно более затратные) для ещё более гибкого и быстрого управления этими функциями.
В этой задаче применять создание дополнительной таблицы и потом ещё добираться до данных в ней я считаю сильно избыточным решением, но никто естественно не мешает так сделать.
Можете уточнить, какого элемента управления вам не хватило? И используемые версии Minishop + MODX, на всякий случай
Может кому пригодится для ориентира по возможным размерам этой папки…
Решил отключить там настройку pdotools_fenom_cache, но cache_resource оставить включенной. На тестовых страницах замедления не заметил. Такой вот кейс.
pdoTools 2.13.2-pl под MODX 2.8.3
Если футболки размечены параметрами или опциями, и в них указаны, какие Черные, а какие Белые по признаку «цвет», и например С принтом или Без принта по признаку «тип», то удобнее создать отдельный шаблон «подборки товаров» и использовать его для страниц данного вида в паре с настроенными выборками через msProductsComposerSelection либо без него, если передать в вызов msProducts или mFilter через параметр &where или &tvFilters нужные данные для выборки иным способом (к примеру через ещё одну TV или опцию ms2)
MODX очень гибкий, всегда есть несколько решений. Даже если разметки характеристик у товаров нет, и прокликивать и размечать 1000 товаров не хочется то, хоть и не так точно и красиво, но всё-таки можно выбрать товары по названию через &where по маске «черн*» и «с принт*», а в случае недостаточной скорости — закэшировать всё это. И возможно, даже обновлять кэш в фоне через, например, scheduler
Очень рад, что смог донести идею! Спасибо за внимание! Желаю успехов, тебе и компоненту!
Короче говоря последнее, что я хочу (и могу) делать на этом этапе, это снова заниматься программированием — разбирать данные из массивов, сверяться с документацией по бекенд-технологиями (таким как PageBlocks, искать там кастомные модификаторы) — мне хватает того, что для простых преобразования в стиле (:lowercase или :ellipsis) у меня открыта документация по фильтрам вывода (в плюс к тому набору выше).
Поэтому использование в вызове чанка специализированный модификатор (:pbJson) — это прекрасно, что такая возможность в принципе есть, но пока не освоишь инструмент очень глубоко (и не забудешь через год, когда на поддержке вернешься к проекту и надо будет добавить присоединение какой-то таблицы) про это в нужный момент не вспомнишь и встрянешь — это совсем не то же самое, что в сниппет pbResources передать нужные параметры для полноценной подготовки данных для их последующей верстки и оформления. Потому что при любом раскладе, когда работаешь с данными, ты пойдешь в документацию (или код) сниппета и посмотришь возможные параметры, отвечающие за подготовку данных и раскладывание по чанкам. Так почему бы не дать возможность избавиться от программирования в чанке и как альтернативу перенести вызов этого модификатора в подхватывающиеся по шаблону (префиксу) параметры вызова сниппета — тогда вся подготовка данных будет происходить в одном месте (вызове сниппета), а всё оформление — в другом (в чанках). Аналогично тому, как например в mFilter2 можно указывать кастомные чанки row и outer для любых полей, просто добавляя их в параметры вызова прямо по именам, задаваемых в этом же вызове — это почти также красиво и понятно в коде, как твоё @Aleksandr Huz описание содержимого табов в PageBlocks))
А тот момент, что у одной задачи есть несколько вариантов решений, как раз и делает инструмент по-настоящему гибким!
Ну хоть что-то, хоть это и немного не то ;)
Попробую пояснить: Когда я занимаюсь интеграцией макетов с админкой, я включаю «режим разработчика» — открываю документацию (или справку/код других проектов), хожу по шаблонам и расставляю вызовы сниппетов, где в этот момент я полностью работаю с данными — их выводом, преобразованием, разбором массивов и прочим, и раскладываю данные по чанкам. Может даже где-то пишу свои модификаторы вывода для сложных случаев. В этот момент я почти не смотрю на фронтенд, меня мало интересует верстка и стили, главное вытащить нужные данные
из админки(из БД, конечно).Далее, я иду в чанки, и там уже добавляю к данным оформление. В этот момент я «включаю режим
фронтендераверстальщика»: меня в большей тепени беспокоит как выглядят данные, какие отступы, сходится ли с макетами, у меня открыта совсем другая документация (MDN, возможно SASS, дока к моему фронтенд-фреймворку, возможно к каким-тоКогда кнопок мало (одна, две) надписи в центре смотрятся гармонично, а когда много, ищешь глазами название, а они все начинаются на разной вертикальной оси — когнитивная нагрузка возрастает, поиск усложняется и замедляется.
@Aleksandr Huz рассмотри плиз возможность сделать выравнивание надписей!
P.S. Я такое уже встречал, когда занимался пакетом Formalicious — видимо в дизайне админки MODX никто не планировал много кнопок)) На скриншоте в той заметке тоже некрасиво, я позже исправлял…
Из пожеланий, всё-таки не терять MODX-style и дать возможность использовать систему чанков полноценно, не прибегая в foreach циклам в коде шаблонизатора.
Думаю это выглядело бы примерно так:
Зачем это нужно?
Кроме избавления от циклов в коде для лаконичности и сохранения удобного MODX-стиля раздельного оформления повторяющихся элементов, который и так изрядно потреплен частым злоупотреблением гибкостью fenom-а) — ну, как минимум, дополнительно можно получить более глубокое кэширование и переиспользовать чанки где-то ещё в проекте.
А ещё там внутри чанка можно сделать доступным {$idx} и {$total} (его, возможно, и снаружи, с префиксом типа list_total или как-то так) чтобы не городить их опять же в коде чанка, который для разметк (aka верстки) предназначен, а не для логики.
Это конечно не правка бизнес-логики компонента, а больше к Developer Expierence, но вроде всё так красиво реализовано для разработчиков (уже), что такая вишенка на торт возможно придется кому-то (вроде меня :) ) очень кстати!
Я думаю телега-чатики не навсегда заменили основной канал общения сообщества, поэтому портал надо поддерживать и развивать! Даже телеграм уже делал несколько попыток интегрироваться с веб-средой и думаю у нас ещё будут интересные механики, которые можно будет использовать для слияния чатовой и форумной аудитории. Извините за слегка маркетингово-булшитовое изложение, это уже проф. деформация))
Реквестирую все-таки test stage для себя, чтобы была возможность поддержки проекта кодом!
Это похоже на более-менее future-proof решение, а докер есть сейчас ну почти на любой микроволновке :) ну и его при таком подходе заменить можно на чисто по API работающее нечто своё. Короче, открывается масса прекрасных возможностей. Хотелось бы твоё мнение на этот счет. Особенно после запуска FacetSearch я думаю некоторый опыт уже сложился у нас, надо его использовать!
А кто-где рекомендует? Я бы изучил мат. часть, потому что тоже планирую несколько релизов, но слабо разбираюсь в выпуске ПО на продажу, делая уже много лет типа «заказного ПО». Дай каких-нибудь ссылок на то, где ты это вычитал, плиз.
Нам нужен профсоюз! :))
P.S. Я не могу сменить свою оценку в твоем посте про ИИ когда она скрыта. Являясь местным активистом, всё-таки я не админ здешнего форума и к скрытым заметкам доступа у меня нет.
Хотел уточнить:
Есть предложение поддерживать 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 (подсмотрел твоё соседнее собщение) очень даже может быть причиной проблем со скоростью. Там нужен особый тюнинг, для которого не так уж много рецептов. Я встречался с таким, победить не получалось, переезжали.
У меня на проектах по 20-30мс на полный ответ сервера, без какого-то рокет-турбо-тюнинга (а с ним — быстрее, но сейчас не об этом).
Мне пока удаётся в большинстве проектов убегать от этих адских фроентенд-фреймворков. Надеюсь удастся полностью пережить их рассвет, встретить закат, и классно-здорово работать на набирающем популярность (снова) серверном рендеринге технологии HTMX, которая отлично ложится в концепцию того, как работает MODX, с чанками, крутыми шаблонизаторами и т.п.
P.S. Тоже интересно, для чего реально используешь @Александр Туниеков gtsAPI. Задумка интересная. Не переписываешь ли потихоньку всю админку на формы VUE? ))
Спасибо что делишься!
P.S. Поправь плиз отступы в форматировании кода во 3 и 4 блоках, а то я shift+tab чуть не нажал машинально, когда читал :)