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

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

Был в сети Вчера в 09:45
Заказы принимаю
Простой рецепт:
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 уников.
Последствия понятны, я думаю.
Андрей, дело не в этом. Ваша точка зрения — со стороны разработчика, есть и другой взгляд на проблему.
У меня есть печальный опыт борьбы с последствиями инсайда. Тут тоже самое — добыл ограниченный доступ к панели (это просто!) — сохранил в ресурсе сниппет и готово — авторизовался под админом (например). Редиске даже думать не надо будет — «эксплоит» он сможет купить где надо.
Для любого серьёзного сайта — это крайне опасно. Выход тут действительно один — не давать доступ вообще. Никакие базовые авторизации глобально не помогут, корпоративные сети никто не отменял. Про резервные копии — когда вы обнаружите проблему, чистых уже может у вас и не быть (проходили).
Это понятно.
Однако нам всем нужно понимать: если вы отвечаете за сайт (поддерживаете), но даёте доступ представителю клиента для управления контентом (у нас же ещё и CMS) — то… ну вы понимаете. Можно даже не настраивать права — как бы и не зачем.

Василий, это не сарказм, если что — я с большим уважением отношусь ко всем участникам сообщества и не желаю менять систему — она мне нравится.

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

Сейчас идёт активное развитие системы, это отлично. При этом развивается и коммерческая часть — великолепно, но вот тут-то наличие таких фичей на мой взгляд недопустимо. Такие факторы будут тормозом для дальнейшего развития системы. Дыры в компонентах, массовые взломы — это одно, а наличие перманентной «багофичи» — уже совсем другое.
Есть сомнения в этом )
Ограниченные доступы легко расходятся по рукам.
Как показывает время, любая бага/фича рано или поздно используется, когда информация о ней попадает в соответствующие «справочники».
Для популярных сайтов — там вообще охота идёт за любой информацией и получение любым способом доступа к админке от «доверенных юзеров» — не проблема для соответствующих «товарищей».
Оффтоп, но не могу не спросить.
С интересом наблюдаю за комментариями после сообщения Евгения.
Мне одному интересны следующие моменты: знают ли про «дырень» разработчики, учитывается для modx3?

Компонент классный, спасибо!