4 часа назад
Дак все на 2-й версии сидят, а эту только посмотреть порадоваться =)
mmxTwig - еще одна интеграция шаблонизатора 8
Вчера в 20:02
Походу твое решение спустя 4 года все такие стало актуальным
github.com/modxcms/revolution/pull/16571#pullrequestreview-2061133420
Facade Laravel в Modx 2/3 21
Вчера в 08:23
Всё норм работает, надо только заменить в файле core/components/msdsector/controllers/msdsectordeliveryhandler.class.php
if (!class_exists("ms...
[msdSector] - расчет стоимости доставки с учетом секторов. 10
15 мая 2024, 11:50
Немного дополню, для mSearch2 (может кому пригодится)
<script>
var lazyLoadInstance = new LazyLoad({
elements_selecto...
pdopage и vanilla-lazyload 7
15 мая 2024, 05:58
Добрый день,
Подскажите, написано, что «Добавлена автоматическая поддержка пользовательских множественных свойств»
Но при этом нигде не сказано...
[mSync] Новая версия синхронизации с 1С 87
14 мая 2024, 14:50
Спасибо!
Пробовал передать свой плейсхолдер — не работает такой подход.
Сейчас решение сделал в виде сниппета получающего id по pagetitle
cityFields внутри pdoResources и плейсхолдер id 2
14 мая 2024, 10:27
Решил, зашёл в контексты, web, и там создал новый контекст site_url, и там внутри добавил значение своего сайта на https.
Имя и ключ: site_url
Зна...
При добавлении <base href="[[++site_url]]"/>, не работают стили. 6
13 мая 2024, 23:47
Искал ответ примерно на тот же вопрос. Мне нужно было сделать file.php который будет выводить определенный ресурс из modx. Вот, может, кому то пригоди...
Как получить HTML код всей страницы в сниппете? 10
13 мая 2024, 16:14
Путем ковыряния несколько часов поля, что взял заказ, с кучей костылей. Много старых пакетов написаных еще в 14 году, которые не работаю php 5.6 стоял...
Не добавляется запись в MIGX 1
13 мая 2024, 12:48
Установил компонент. PHP 7.4, Modx 2.8.4. Созданные кастомные поля юзера не отображаются, в логе ошибка:
No foreign key definition for parentClass: e...
ExtraFields. Дополнительные поля для ресурса (modResource) и пользователя (modUserProfile). 33
В общем, у меня компонент был добавлен через addExtensionPackage() и из-за этого все мета-данные брались из кэша, только совершенно не понятно из какого — папка core/cache чистилась полностью.
В общем, сделал removeExtensionPackage() и теперь таблицы генерируются нормально
При выполнении
на выходе в методе parseSchema генерируются правильные map-файлы.
Затем, при выполнении
в этом методе есть вызов $xpdo->getFieldMeta(), а вот уже в нём набиваются мета-данные для создания таблицы. И вот там-то в массиве $this->map лежат старые мета-данные. Как они туда попадают — для меня ещё загадка.
В removeObjectContainer() ничего сверхъестественного нет, чтобы повлиять на такой исход событий. Сейчас порою addPackage(). Может там какая веселуха происходит.
В сгенерированных map-файлах всё прописано согласно схемы, все поля, типы, индексы. А вот сами таблицы генерируются по старому.
Пути верные, сервер — простой шаред, в котором монтировать ничего нельзя, так что — нет, это тоже отпадает (к тому же до этого проблем не было).
Вот сейчас полностью снёс папку с кэшем, очистил папку модели компонента, убрал из xml-схемы всё — оставил описание одной таблицы и 2х полей и перегенерировал.
В итоге — сгенерировались xpdo-файлы этого класса, в map-ах только нужные 2 поля, в таблице — все старые 10 полей, плять. Со всеми индексами и типами.
Да откуда он вообще берёт эти старые данные? Мистики и волшебства в таких вопросах не бывает. Но вот в каком направлении копать?
Вась, помоги, пожалуйста. Чёт совсем у меня вариантов нету.
По событиям issue создал.
Там, кстати, в пуллреквесте странность. К нему почему-то прибилось 3 коммита, которые я отправлял в свой репозиторий уже после создания этого самого пуллреквеста. Не знаю почему так. По логике такого быть не должно, но в git'е я понимаю мало (пользуюсь гитхабовским гуёвым клиентом), возможно так и должно быть, хз.
В общем, последние три коммита Discount cards foundation, Discount types ready, DiscountCard grid там не нужны.
По второму — слишком неоднозначная задача, которую можно решить многими разными способами (как и всё в modx'е). Здесь легко подойдёт migxdb, но не знаю — разберётесь ли вы с ним. В xpdo что-нибудь понимаете? Сниппеты свои писали?
Вспомнил про крайнюю статью про плагины и новый метод miniShop2::invokeEvent(). Тогда вопрос про собственный класс и настройки снимается :-)
Но тогда как валидировать свои поля при выводе через сниппет, когда (и если) эта возможность появится. Ведь в методе msOrderHandler::validate() не вызывается никаких событий, а значит свои поля отвалидировать таким образом не получится…
Самый верняк — это на msOnChangeOrderStatus проверять, если только что оплаченный заказанный товар кончился, отменять другие заказы с этим товаром. Отлично, спасибо!
Но тогда надо уведомить как-то об этом покупателя. Можно заюзать поле «Комментарий», но, по логике, оно ведь предназначено для менеджеров, в письмах и чанках не отображается, да и комментарий этот никак со статусом не связан — он всегда останется таким, каким его написали, даже при смене статуса.
Но так-то пофиг, можно использовать и его.
Переделал запрос на такой:
И собрал его на xPDO вот так:
Воу, аж на месяц счёт идёт… Ну хотя бы так, куда деваться)
А ты примешь этот коммит, если что? :-) Задумка-то клёвая! Да и возможности гибкие будут)
p.s. как там, кстати, дела с no-js?)
Смысл какой — во настройках добавляется новая вкладка — «Типы скидок». Вот описание этой вкладки:
И так же можно будет создавать дисконтные карты из админки. Можно назвать это промо-кодом, как угодно, суть не меняется. Эти карты могут быть общими для всех, именными, иметь совладельцев, иметь ограничение на количество использования.
Пара скринов того, что готово:
Вот в первом скрине — осталось только в окошко создания/редактирования добавить superbox с возможностью выбора нескольких юзеров сразу.
И всё, что в описаниях выше — всё сделаю, но вот с ExtJS никак не совладаю :-( Он меня убивает просто. И ведь осталось-то с ним совсем немного — остальное дело техники — сниппет для упраления картами для фронта и обработки.
Дак а как мне из jQuery юзать Ext-овские виджеты? А именно superbox.
А в скриптах всегда подставляется контекст.
Всё, что было в action.php — всё перенесено в плагин (ну за исключением подключения index.php). С такими вещами я больше всего боялся накосячить и поэтому отнесся к ним с бОльшим вниманием =)
Но, технически, будет даже быстрее (пусть и не заметно для глаза) или разницы просто не будет. Ведь запросы обрабатываются не в сниппете, а в плагине на onHandleRequest.
Когда запросы шли через action.php, запускался index.php, в котором инициализируется modX, контекст и запускается $modx->handleRequest(). Код miniShop'а начинал свою работу после полной отработки modX::handleRequest(),
А когда всё работает через плагин, то код miniShop'а вступает в действие уже вот здесь, когда modX::handleRequest() запускает событие onHandleRequest, т.е. miniShop2 начинает обработку запроса раньше, чем это было через action.php :-)