Обратите внимание, я передаю в плагин через сессию идентификатор сессии, это связано с тем, что у меня на сайте авторизация происходит не через процессор, а с помощью метода addSessionContext(), который меняет id сессии, а нужен тот id, который был до авторизации. Возможно, при авторизации через процессор, такого не происходит, но я не проверял.

Процессор использует ровно тот же метод addSessionContext, добавляя еще проверку прав, запуск событий и т.п. Так что все идентично по факту. И да — addSessionContext меняет id сессии. Способа бороться с этим нет.
Я для себя делаю так

$_SESSION['prev_session_id'] = session_id();
$user->addSessionContext();

И далее запрос в базу избранного можно строить используя текущий обновленный session_id и одновременно старый из сессии.

Сессии так-то тоже не везде используются. Перезаписываются при каждой авторизации

$msAddress = $msOrder->getOne('Address');
$properties = $msAddress->get('properties');
$utm_campaign = $properties->get('utm_campaign');

спасибо, как вариант…

Куки ненадёжно, пользователь может их очистить.

Поле parent есть в таблице site_content

Что-то как-то сложно) Я просто сохраняю в куки id ресурсов и потом вывожу их через pdoResources / msProducts

Добрый день! Подскажите как ополучить данные меток заказа, к примеру для отправки в письме менеджерам или для отправки по API.
Логика подсказывает, что где-то тут
$properties = $msAddress->get('properties');
$utm_campaign = $properties->get('utm_campaign');
Но не работает

Нет, это для админки, у меня для фронта.

это дополнение разве не тоже самое уже реализует?

В mSearch2 можно добавить синонимы запросам.

Изобрел — пока статью писал.

Классный хак с повторным вызовом FormIT и пробросом туда параметров из задания через $_POST, очень элегантно!

Мне вот на подобие этого нужно было как-то вызывать хук для формита с API-вызовами к внешнему сервису но без отправки формы, так пришлось его код копировать и в сниппет выносить, а стоило сделать вот так как в заметке сделан сниппет send_email, чтобы не дублировать код и не поддерживать потом 2 версии…

К стати дополню список — в AjaxFormitLogin этот метод тоже будет работать

Так-то это не ошибка, а предупреждение.

На PHP версии 8 выдает ошибку
/home/s32719/www/core/components/translitor/model/translitor.class.php 188
PHP warning: Undefined array key «ru»

Шаблоны нужно ДОвёртывать, а сборку ДОнастраивать, за счет этого и экономия. Обязательно напишите отзыв как протестируете)

Хм, cтранно, что поиск на github не находиn bootstrap.php

Ну теперь очевидно, что даже приведенный список пакетов означает актуальность уровня «уже» а не «скоро», как в начале показалось. И со временем будет расти…

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

Беглый гуглинг показал, что не только с MODX 3 так бывает ¯\_(ツ)_/¯ например у движка Википедии похоже было подобное (ссылка ниже)

Но существуют решения (которые прямо сейчас в MODX конечно не поддерживаются):
• как встроенными средствами composer-а через специальный формат записи конфигурации ( stackoverflow )
• так и инструменты, помогающие это автоматизировать, например wikimedia/composer-merge-plugin

Наверное с эти уже пора отправляться с issue к MODX Core team, чтобы уточнить возможность прикрутить это, или нечто подобное к существующему механизму, если не для автоматизированного решения проблемы, то хотя бы для вывода предупреждений о конфликтах версий зависимостей при установке пакета… Или уже обсуждается, и я опять не осилил поиск на гитхабе?)))

В любом случае, ещё раз спасибо @Василий Наумкин и @Николай Савин за пояснения!

1. pdoTools
2. Collections
3. Tagger
4. SimpleSearch
5. FormIt
6. SeoSuite
7. Formalicious
8. GoogleAnalytics
9. ModxDashboardWidgetsPack
10. QRNFCGenerator

Это те, что на вскидку вспомнил, потому что работал с ними недавно. Если покопаться, найдутся еще.

Таких пакетов уже довольно много, хоть бы и новый pdoTools. Видишь, здесь грузится свой собственный autoload.php, который может содержать любые зависимости?

Теперь представь, что так может делать любое дополнение в MODX 3. Кто-то будет тестировать свой пакет на совместимость со всеми остальными в репозитории? Очень сомневаюсь.

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

Это есть и во 2й версии, просто там этот шанс гораздо ниже, но отнюдь не нулевой.

Так эти пакеты аффектятся описанной особенностью работы MODX 3 с композером или нет?

Если я правильно понял, самого факта того, что где-то в подпапках лежит конфиг composer.json и разработчик для обновления вендорных исходников вручную запускает composer, не достаточно, чтобы возникла возможность коллизии.

А чтобы эффект проявился, нужно чтобы пакет специально использовал в новом стиле composer:

система проходит по всем зарегистрированным namespaces и пытается подключить из них файл bootstrap.php

Такие пакеты кто-нибудь встречал? Дайте ссылку плиз, я не могу найти