Василий Наумкин

Так а что мешает добавить ar = x в настройки источника файлов?

У Office не какие-то там свои отдельные юзеры, а обычные, системные.

Следовательно, и проверять на авторизацию нужно методом modUser::isAuthenticated.

Очевидно да, ты не знаешь, что в этот блок можно засунуть новые поля.

Вот здесь прочитай первую половину и не приставай больше к стандартным полям товара =)

Как я это укажу, если я примерно с тех же пор (с 2011) не работаю с MODX Evolution?

А в версии для Revolution всё почти само работает.

Зачем так извращаться?

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

Кроме базы нужно еще и модель компонента менять, и тип поля ввода — но это неправильный путь.

Зачем вообще вес тебе нужен с ведущими нулями? Вес — это же число, а не текст.

modstore.pro/hybridauth

habrahabr.ru/post/259197/

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

Отстаньте уже от людей, дайте им спокойно пообщаться.

Прописывать те параметры, в которых есть теги MODX явно, а не в наборы. Иначе парсер не может их обработать.

Как-то так:

[[!pdoMenu@{$vendormenuclasskey == "msCategory" ? "vendor-list-subcat" : "vendor-list-cat"}? 
	&parents=`{$vendormenuclasskey == "msCategory" ? "[[*id]]" : "[[*parent]]"}`
]]

Даже лучше так:

{if $vendormenuclasskey == 'msCategory'}
[[!pdoMenu@vendor-list-cat? 
	&parents=`[[*id]]`
]]
{else}
[[!pdoMenu@vendor-list-subcat? 
	&parents=`[[*parent]]`
]]
{/if}

После обработки Fenom останется всё равно только один вызов.

В параметрах указан 'parents' ([[*id]] либо [[*parent]])

Вполне возможно, что оно вот так и попадает в сниппет, необработанным.

Сделай там в начале сниппета

echo '<pre>';print_r($scriptProperties);die;

и посмотри, что приходит.

Кто-бы написал?

У нас и репозиторий с документацией имеется, если у этого кого-то возникнет желание.

Пишите на здоровье, буду только рад!

Ну вы даёте, это же встроенный функционал опций, который сильно расширили в новой версии (сам тоже не смотрел еще).

В старой версии:
1. Добавляем нужные поля в товар по инструкции, или используем для примера встроенные цвета и размеры

2. В стандартном чанке оформления страницы товара msProduct.content эти поля и так выводятся, но если что — выводим их через сниппет msOptions

3. При добавлении в корзину эти поля присоединяются к товару автоматом

4. В созданном заказе эти поля тоже сохранены


Еще раз повторяю, это встроенный функционал, работает из коробки первых версий. Вывел прям щас на демо сайте — minishop2.com/catalog/category-2/article-1

Более того, все эти переданные опции попадут и в запись о заказанном товаре и даже будут выводиться в админке JSON массивом.

А если немного изменить системные настройки, то появятся и отдельные столбики с ними в ExtJS гриде.

Это у нас так в магазине хранятся отдельные параметры: скидка и ключ.

Без понятия.

Я первый miniShop написал после краткого знакомства с Shopkeeper. Решил, что написать свой магазин будет проще, чем разбираться с его логикой.

О каком-то лавочнике первый раз услышал

Да Shopkeeper же.

Вот развели мистику.

Не думаю, что тут кто-то сможет помочь. Версия для Evolution была выпущена в 2011 году и никто, с тех пор, её не дорабатывал.

Так что, это или мега-глюк, который заметили только вы, или вы что-то не так делаете.

См. Работа с pdoUsers

Ты здесь, на этом сайте создал документ — который мы сейчас обсуждаем. Задал ему pagetitle «Функция „управление над сайтом“», и написал свой вопрос в поле content. Как parent выбрал раздел «Вопросы».

Ты всё это сделал не заходя в админку modx.pro — верно? Так что, если статьи пишутся через компонент Tickets, то редактировать их можно без админки.

Но отдельного, какого-то готового, решения для редактирования всего подряд на сайте без админки я не встречал.

Сложный вопрос.

С одной стороны — нет, а с другой — ты же можешь редактировать этот свой тикет не заходя в админку modx.pro?