Про код. Про «научиться писать код понятный и логичный». Не в тему поста выше, ситуация вчера/сегодня и смех и грех.
Вчера пришел запрос от Заказчика на сайте на Wordpress — сайт криптообменника. Там в настройках надо было добавить новый статус заказа. Добавили в админке, а на сайте у клиентов не отображается. Ну я типа ща минуту, легкотня.
В итоге провозился 2 дня. Пока разбирался в чужом коде. Вчера даже тестовый сайт лег после пробных правок кода, пришлось восстанавливать.
В итоге сегодня разобрался. Выставляю счет Заказчику за 7 часов работы анализа и правок и отладки кода (3 часа восстановления сайта не в счет, оказалось что сайт лог ошибок не пишет, а восстановить бэкап просто так нельзя и «вообще некогда нам» — кое как сам добавил логирование ошибок и восстановил сайт).
Заказчик в итоге спрашивает у меня — с какого так много запаришваешь? Типа поменять там всего то текст. А оказалось что в админке есть настройка, а в коде названия статусов выводит через дефолтные настройки в самом коде (рука лицо!). И вообще в админке указываемое название статуса нигде не используется. И 7 полей из 10 из таблицы статусов в БД не используется почти. И куча артефактов. И фильтров и функций непонятно каких. И вообще id статуса в таблице заказа не используется, а используется текстовое название статуса (аааа!). И вот сидишь разбираешься в этом г… не и не понятно кто будет платить за разбор. А казалось бы просто вывести название статуса в заказе клиента…
А до этого тоже делал подобное. И пока доделал — оказалось что задачка стала неактуальной. И код правки (по итогу 2 строчки кода) стал никому не нужен. Опять же 2 дня из-за непонятного чужого кода. Ладно хоть заплатили…

Теперь Заказчику приходится искать специалиста и по MODX и по VUE.

Мы такого не нашли :-). Я искал месяц, а потом перестал искать. Даже Василий Наумкин попробовал нам помочь с MODX и VUE, но у меня сейчас замороченный код и Василий сказал что не силен разбираться в тайнах чужого кода :-). Как бы научиться писать код понятный и логичный?? А то как обычно есть идея понятная логичная — пишешь код и начинается. То здесь фишку надо прикрутить, то там костыль прописал и в итоге хаос. Как пишешь первоничальный вариант, то делаешь одно, а как используешь в работе то вносишь уже совершенно другие правки. Пара лет правок и энтропия догоняет. Все становиться запутанным и малопонятным.

Уроки по синхронизации с Битрикс24 имеют весьма опосредованное отношение к Modx. Да и основная сложность при работе с Битрикс24 это структура хранения данных в самой CRM. Например банковские реквизиты компании это отдельная сущность, т.е. сначала нужно создать компанию, потом создать реквизит. А перед этим ещё найти контакт по лиду или создать его.

Спасибо за статью.
Я столкнулся с проектом где часть админки начали делать на VUE.js потому что так захотел/обосновал предыдущий программист. А после его ухода заказчик остался с недоделанным личным кабинетом. А по факту там надо было реализовать подгрузку документов пользователя. Ну может еще что реактивного, но я задался вопросом почему нельзя было стандартными средствами MODX реализовать и с Ajax-запросами.
Теперь Заказчику приходится искать специалиста и по MODX и по VUE.

Было бы классно если бы еще были уроки по синхронизации с Битрикс24.
Т.к. в коде выше я так понял нет примеров самой синхронизации.
На modstore есть 2 плагина платных, но по ним есть вопросы — в комментариях видно что не все позволяет синхронизировать (последние комментарии от 2024 года висят без ответов).
Т.к. Битрикс24 одна из самых популярных и функциональных CRM сегодня.

Абсолютные пути будут поправлены со следующей версией, готовлю обновление в плане управления темой, не только переключалка тем будет…

Читай мой коммент выше как исправить

Прочитав про комментарий выше о том что тема создает папку manager я вспомнил что уже писал об этом и сталкивался с проблемой в прошлом. https://modx.pro/components/25063#comment-144547
Повторю сюда решение проблемы при установке — т.к. после установки на сайт, у которого папка manager (папка админки) была переименована, — тема встает неправильно:

У меня админка размещена по другому адресу (не manager).
Страница входа выглядит не так как на картинке в теме выше. Посмотрел и увидел что в корне создалась папка manager/templates/eclipseui
При этом в папке админки в папке templates тоже появилась папка eclipseui. Но в ней папки частично пустые.
Просто перенес содержимое созданной папки manager в правильную папку админки и все нормально заработало.
Т.е. установщик ставит шаблон неправильно — где-то в коде указывает папку установки с прямым путем manager/templates/eclipseui, а надо брать путь к папке из конфигов.
Благо разобрался и все заработало.

После этого получил красоту.
Правда не понял в чем разница в настройке manager_theme с gihub на eclipseui — вроде одинаковые.
Еще было бы круто вынести в настройки выбор цветов.

Сначала сохрани ресурс потом устанавливай значение ТВ.

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

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

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

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

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

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

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

Успехов!

да

Типа каждый раз запрашивать код/звонк при авторизации?

Можно авторизироваться без пароля, просто по смс коду/звонку?

Теперь всё понятно.
Спасибо за разъяснение.

Получается, что бы записать в заказы надо указать в input

name="region"

?

<div class="input-group mb-3 input-parent">
                    <select class="form-select input-custom bg-transparent border-bottom" id="region" name="region">
                        <option selected>Область:</option>
                        <option value="Пензенская">Пензенская</option>
                        <option value="Саратовская">Саратовская</option>
                        <!-- Здесь можно добавить другие регионы, если необходимо -->
                    </select>
                </div>

Мне надо отправить region в заказ

Смотри. Исторически так сложилось, что в форме есть поля и ошибки связаны с этими полями. Чтобы связать текст ошибки с полем нужно добавить блок с атрибутом data-si-error=«fieldName» где fieldName имя проверяемого поля. При авторизации проверяются сразу два поля Логин и Пароль, так вот параметр 'errorFieldName' нужен чтобы связать ошибку авторизации с полем. Можно с логином, можно с паролем, а я рекомендую делать скрытое поле.

P.S. описание параметра в доке не очень понятное надо исправить.

Ну мы надеемся, что автор сменит абсолютные пути на относительные в своём дополнении, тогда заживём.

Сегодня обновился, и всё сработало.
Теперь очень удобно.

Спасибо большое за ваш труд.

Если можно, можете уточнить еще момент.
Наткнулся в документации при авторизации на такой параметр.

'errorFieldName' => 'errorLogin'

написано — в этом параметре необходимо указать имя скрытого поля, в которое будет записан текст ошибки авторизации, если оставить пустым ошибка будет показана во вплывающем сообщении.
Я правильно понимаю, что если в форме будет input поле как в вашем примере, то сообщение об удачной или не удачной авторизации должно появится в этом поле?
Если так, то почему то сообщение не работает оно всё так же во всплывающем окне отображается. Или я опять не так всё понял.