Только:
— при чем здесь именно Office? (HybridAuth, Login, ...)
— зачем сохранять id, а потом при каждой загрузке страницы делать доп. запрос к таблице пользователей? И зачем для этого OnUserSave, если данные статичны.
И да, все же — что в итоге входит в мифические 90%? Триггер события OnUserSave?
UPD: не поймите меня неправильно, вашим решением тоже можно натянуть сову на глобус. Просто оно хуже.
2. Полноценная страница (точно такая же, как и любая другая страница, создаваемая через интерфейс ресурсов MODX и хранящаяся в БД. Создается при регистрации/активации пользователя и, при изменении профиля пользователя, новые данные проецируются на страницу).
(способ реализации)
1. нужные элементы и их потомки имеют процентный параметр width или max-width
2. использование media-запросов для изменения логики отображения нужных элементов при определенной ширине
Если у вас не адаптируется какой-то элемент (хотя должен, исходя из пунктов выше), вы можете проинспектировать их через консоль (f12 в хроме или пкм по проблемному объекту -> просмотреть код) и таким образом локализовать проблему. Дальше применяем пункты 1 и 2.
А то, на мой взгляд, тут эксплойт на лицо.
Только:
— при чем здесь именно Office? (HybridAuth, Login, ...)
— зачем сохранять id, а потом при каждой загрузке страницы делать доп. запрос к таблице пользователей? И зачем для этого OnUserSave, если данные статичны.
И да, все же — что в итоге входит в мифические 90%? Триггер события OnUserSave?
UPD: не поймите меня неправильно, вашим решением тоже можно натянуть сову на глобус. Просто оно хуже.
К слову, при выборе второго способа, для вашей задачи можно ограничиться одним плагином (создание тикета в нужном разделе при активации), а редактирование страницы реализовать через родной компонент TicketForm c правами «только редактировать».
Но о какой «90% работы» идет речь, если вопрос звучал: «как сделать персональную страницу при регистрации пользователя»?
1. Виртуальная страница (напрямую не существует в БД, данные собираются на лету исходя из запрошенного урл). Пример такой реализации — modx.pro.
(способ реализации)
2. Полноценная страница (точно такая же, как и любая другая страница, создаваемая через интерфейс ресурсов MODX и хранящаяся в БД. Создается при регистрации/активации пользователя и, при изменении профиля пользователя, новые данные проецируются на страницу).
(способ реализации)
А вообще, зависит от того, на каком этапе формирования цены вклиниться.
В вашем случае достаточно свитчить $cart['total_cost'] и, в зависисимости от требуемых условий, приплюсовывать к $cost нужную сумму.
У вас сейчас при переключении фильтров записывается его id (вы смотрите результат с примесью старых записей, их нужно очистить):
(смотрю по dev.nosi.ru)
А в чанке мы ищем по name. Или замените в скрипте .attr('value') на .attr('name') или в чанке ищите по айди:
Для начала, замените 'value' на 'name'.
1. Содержимое $.cookie('filters_condition') хранит json-строку с шаблоном
«name-фильтра»:«состояние фильтра».
2. Ваша задача в шаблоне фильтра получить нужную переменную куки и преобразовать её в массив:
3. Далее, вам нужно получить состояние конкретного фильтра по ключу массива (по-умолчанию, поле name):
4. И, наконец, в зависимости от полученного состояния, проставить checked для фильтра.
Сейчас вы на шаге 3 — смотрите содержимое получаемого массива и, в частности, значение $filter_condition.
Скорее всего, мы ищем не по тому ключу (сравните передаваемое значение со значением name фильтра).
Вы модифицировали шаблоны фильтров в вызове mFilter2?
Код из шага 3 внутри чанков теперь должен проставлять checked-статус для нужных фильтров.
— замените методы $.cookie в скрипте выше и будет вам счастье.
UPD: или можете попробовать подключить библиотеку, для которой был написан код выше:
oil-rf.ru/assets/global/js/lib/cookie.js
— вы не подключили скрипт, работающий с куками.
github.com/js-cookie/js-cookie/blob/master/src/js.cookie.js