только не пойму как если &level ограничен (&level=`3`) и последний уровень=категория то как у неё class=«dropdown-submenu» отнять чтоб стрелочка не появлялась.
а то такая проблемка верхнее меню Navbar: Каталог >> Радиостанции >> ...
Как связаны обновление и перенос? Понимаете ли вы, что обновление с версии 1.3.3 до 1.9.4 — это много промежуточных версий, и не факт, что все нормально будет работать?
Если не страшно, просто поищите в менеджере пакетов по слову miniShop. Именно поищите в репозитории, а не кликайте «проверить обновления» — так не работает.
Опишу задачу. Сайт совместных покупок, соответственно товары парсятся с сайта донора по ссылка которые предлагает пользователь:
1. Пользователь вставляет ссылку в форму
2. Парсер получает товар (точнее переменные):
name price weight img
3. Из полученных переменных нужно создать товар
4. Получить ID товара и соответственно поместить товар в корзину
Есть процессор создания товара, загляните в него и посмотрите какие параметры он принимает. Если вы хотите сразу создать товар с галереей, тв параметрами и категориями то вам нужно сделать копию процессора и немного дополнить.
то есть получить товар можно, получить корзину, работать с корзиной можно.
А вот про создание товара ничего не нашел ни в документации ни в классе.
А хотя подобная необходимость имеется. Есть ли подобное? как стоит реализовывать?
Весь прикол в hideSubMenus.
Если его уберете — меню появится в корзине, правда полностью раскрытое.
В общем когда вы в каталоге, меню надо строить так:
[[!Wayfinder? &startId=`5`&textOfLinks=`pagetitle` &innerClass=`inner` &hideSubMenus=`true`]]
а когда вы ВНЕ каталога, то так:
[[!Wayfinder? &startId=`5`&textOfLinks=`pagetitle` &innerClass=`inner` &hideSubMenus=`false` &level=`1`]]
По поводу бага #9069, ответ opengeek был, что это не баг: ведь в бэкенде MODXа, все могут делать то, что хотят. Это вопрос доверия, он говорил. Ответ показывает, что есть разногласия насчет менеджера.
После небольшого знакомства с MODX, у меня есть впечатление, что создатели колеблются между двумя идеями по поводу бэкенда:
1. Бэкенд — это место только для админов, у них есть свой контекст, закрыт для всех остальных. Это не место для редакторов или менеджеров. Для последних надо построить собственные закрытые структуры с авторизацией (например через новый контекст). Поэтому существуют такие плагины как Login и другие. Может поэтому у создателей нет проблем с тем, что менеджер очень сложно написан, его очень сложно изменять графически.
2. Бэкенд — это для всех редакторов. Любые публикации на сайте делаются через бэкенд. Любой редактор заходит с определенными правами.
И тут некий конфликт. Например: любой менеджер, который может создать новый юзер, может его назначить sudo user. Он может изменить свои собственные права и права людей по-выше. Это понятно только, если бэкенд понимается как очень узкое место только для узкого круга админов. Ответ opengeek идет в это направление.
А другие создатели говорят: нет! нужные развернутые права в менеджере! Нужны form customization для менеджера! Чтобы можно было многогранно определить полномочия и видимость каждого юзера в менеджере!
Всего 125 661 комментарий
оказывается к level можно обращаться как к свойству
В моём случае tpl.Wayfinder.submenu сработал так:
а то такая проблемка
верхнее меню Navbar: Каталог >> Радиостанции >> ...
Если не страшно, просто поищите в менеджере пакетов по слову miniShop. Именно поищите в репозитории, а не кликайте «проверить обновления» — так не работает.
1. Пользователь вставляет ссылку в форму
2. Парсер получает товар (точнее переменные):
name price weight img
3. Из полученных переменных нужно создать товар
4. Получить ID товара и соответственно поместить товар в корзину
думаю как проще реализовать пункт 3
На будущее — если отвечаете на комментарий, то тому, кому ответили приходит уведомление.
Иначе — нет.
то есть получить товар можно, получить корзину, работать с корзиной можно.
А вот про создание товара ничего не нашел ни в документации ни в классе.
А хотя подобная необходимость имеется. Есть ли подобное? как стоит реализовывать?
Трудно задать вопрос так, чтобы было сразу понятно, о чем речь?
Хостинг sprinthost.ru
Перенес на beget.ru работает нормально.
Если его уберете — меню появится в корзине, правда полностью раскрытое.
В общем когда вы в каталоге, меню надо строить так:
[[!Wayfinder? &startId=`5`&textOfLinks=`pagetitle` &innerClass=`inner` &hideSubMenus=`true`]]
а когда вы ВНЕ каталога, то так:
[[!Wayfinder? &startId=`5`&textOfLinks=`pagetitle` &innerClass=`inner` &hideSubMenus=`false` &level=`1`]]
(какой то class добавился:) в ответе, вообщем должно быть вместо [[+id]] -> [[*id]])
А на странице товара должно выглядеть так
У меня же стояло и там и там одинаково, после замены, всё заработало
Пришлите логин\пароль мне на bezumkin@ya.ru, погляжу.
Что за хостер?
Разработчики проигнорировали.
После небольшого знакомства с MODX, у меня есть впечатление, что создатели колеблются между двумя идеями по поводу бэкенда:
1. Бэкенд — это место только для админов, у них есть свой контекст, закрыт для всех остальных. Это не место для редакторов или менеджеров. Для последних надо построить собственные закрытые структуры с авторизацией (например через новый контекст). Поэтому существуют такие плагины как Login и другие. Может поэтому у создателей нет проблем с тем, что менеджер очень сложно написан, его очень сложно изменять графически.
2. Бэкенд — это для всех редакторов. Любые публикации на сайте делаются через бэкенд. Любой редактор заходит с определенными правами.
И тут некий конфликт. Например: любой менеджер, который может создать новый юзер, может его назначить sudo user. Он может изменить свои собственные права и права людей по-выше. Это понятно только, если бэкенд понимается как очень узкое место только для узкого круга админов. Ответ opengeek идет в это направление.
А другие создатели говорят: нет! нужные развернутые права в менеджере! Нужны form customization для менеджера! Чтобы можно было многогранно определить полномочия и видимость каждого юзера в менеджере!
Поэтому такая неразбериха, как мне кажется.