Алексей Шумаев

У меня есть класс-заготовка, настраиваю под требования конкретного проекта. Как-то нет потребности в полностью автоматизированном решении — оно будет громоздким и всё равно требовать подстройки.
Конечно, у товаров должно быть унифицированное поле — артикул или id какой-то внешней БД-источника. Какой id будет у ресурса в системе при этом значения не имеет.

Попробуйте сделать так: загрузите на новый сайт товары из сторонней БД и артикулом укажите id товара в сторонней БД. Или расширьте таблицу msProduct (или modResource — по желанию) и пишите этот id в новое поле (например extID). Синхронизация будет идти по выбранному полю.

У меня есть подобный случай — одна база на несколько сайтов. Все сайты синхронизируют свои БД с общей базой товаров, но при этом независимы.
Если БД с таблицей товаров доступна извне, то обращаетесь к ней напрямую, если нет — выгружайте на ftp например в csv и забирайте данные оттуда — это тоже без проблем работает.

В этом случае, я бы просто настроил синхронизацию товаров в вашем магазине с этой БД и всё.
Ничего сложного тут нет, и весь функционал MS2 также будет в вашим услугам.

Отлично.
Нашёл маленькую опечатку: prntscr.com/kxu486

Простой рецепт:
1. Выносите в ClientConfig поля для внешних скриптов (метрика, ets). например: ExtJSHead, ExtJSBody, ExtJSFooter
2. Выводите эти поля, где надо через сниппет:

{'extScripts' | snippet : ['input'=>'head']}

Сниппет:

if(!isset($input)) return;
$ext = array(
    'head' => $modx->getOption('ExtJSHead')
    ,'body' => $modx->getOption('ExtJSBody')
    ,'footer' => $modx->getOption('ExtJSFooter')
);

$search  = array('{', '}');
$replace = array('{ ', ' }');
$out = str_replace($search,$replace,$ext[$input]);

return $out;

Официально, значит, не будет… Ждём пиратку на торрентах )

Если я верно понял вопрос…
Переменные передаются.
Например определяем переменную {var $docid = $_modx->resource.id} в шаблоне, и эта переменная $docid доступна в расширении.
Если в расширении будет вставка файлового элемента, например:
{include 'file:templates/page.tpl'}, то $docid будет доступна и там.
Удобно, однако.

Спасибо! Весьма полезно.

Что было-то? Может кому ещё пригодиться )

Если сайт чужой — проверьте:
1. настройку ms2_services (если есть, от версии зависит. в старых не помню как было организовано) — указаны ли там посторонние классы для корзины
2. директорию core/components/minishop2/custom/cart — тут может быть кастомный класс, где переопределен метод добавления в корзину. Хотя он может быть где угодно )

Ну я бы посмотрел плагины сначала.
Проще всего зайти в phpMyAdmin, найти таблицу префикс_site_plugin_events и поискать в ней по полю event значения: msOnBeforeAddToCart, msOnAddToCart (на всякий случай). Если что найдётся — смотреть плагин с id, который будет в поле pluginid.
Если нет — тогда не знаю — надо в сайте копаться…
Смотрите где округление начинается: в карточке или только в корзине или после оформления заказа.

Нет там округления по умолчанию, даже из интереса глянул на чистом тесте )
Если сайт не на базовом функционале — смотрите ваши данные — единицы измерения, плагины, кастомизации штатных методов — где-то что-то округляет, наверное.

Добре! В теме компонента мы уже знатно намусорили, хватит )
Если есть интерес этому вопросу, нужно отдельную тему создать.

Про не безопасность мне известно. Но я не уделял должного внимания этой теме и это очень плохо.
Для меня странно, что никому эта тема особо не интересна. Либо все уже умеют защищаться, либо (что вероятнее) большинство народа не знает или не заморачивается. Почему это плохо, я написал выше.

Да и потом если вы занимаетесь разработкой сайтов и поддержкой ну попробуйте по лучше изучить безопасность MODX.

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

Доверие есть, нужно понимать границы.
Насчёт остального — не согласен, и особенно если вы не прекращаете сотрудничество после сдачи проекта — большинству клиентов нужна поддержка/обновления и т.д.
Впрочем, это сугубо моё дело, ваша точка зрения понятна и оправданна.

Вот тут Евгений всё написал:

Данная тема практически нигде не затрагивается и зачастую, люди ограничивающие доступ в админку политиками безопасности даже не подозревают, что в этом особого смысла нет (кроме защиты от дурака, чтобы лишнего не грохнули).

Защититься на 100% нельзя, никто не спорит.
Тут важно именно следующее: многие (и я в т.ч.) полагали, что у нас CMS и ограниченная учётка может отдаваться контент-менеджеру без особых опасений.
Евгений продемонстрировал, что это не так. Для меня это важно и я буду думать над изменением политики работы с modx.

Ещё раз извиняюсь за старт обсуждения в вашей теме.

Всё так, присоединяюсь.
Извинился выше, минуса почикал как смог…

Андрей, я извиняюсь, что обсуждение пошло в вашем топике.
Тема же не про ваше дополнение! Оно отличное и никак во взломе не виновато!

Сейчас, кстати, майнеры в моде. Последняя волна взломов показала нам это наглядно.
Майнер можно не найти годами, а у вас на примете сайт на модх с 10000 уников.
Последствия понятны, я думаю.

Андрей, дело не в этом. Ваша точка зрения — со стороны разработчика, есть и другой взгляд на проблему.
У меня есть печальный опыт борьбы с последствиями инсайда. Тут тоже самое — добыл ограниченный доступ к панели (это просто!) — сохранил в ресурсе сниппет и готово — авторизовался под админом (например). Редиске даже думать не надо будет — «эксплоит» он сможет купить где надо.
Для любого серьёзного сайта — это крайне опасно. Выход тут действительно один — не давать доступ вообще. Никакие базовые авторизации глобально не помогут, корпоративные сети никто не отменял. Про резервные копии — когда вы обнаружите проблему, чистых уже может у вас и не быть (проходили).