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

Этот процессор был в MODX Revolution с 21 мая 2009 года. А первый коммит в Login был 25 июня 2009 года.

Довольно странно не пользоваться системными решениями, особенно, если ты один из архитекторов системы. Я всегда думал, что процессоры для того и нужны — стандартизировать рутинные операции.

У юзера не прописано свойство Services, поэтому любая IDE будет выводить что-то такое:


xPDOObject::getMany() привычнее и нагляднее.

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

1. Юзер может зайти сразу через HybridAuth, в первый раз — это создаст нового юзера MODX с привязанной соцсетью и случайным паролем.
Если потом админ поставит Login, то юзер сможет сбросить через него пароль и входить и по нему, и через соцсеть.

2. Login уже стоит, юзер входит\регистрируется через него, а потом привязывает соцсети в редактировании профиля.

Механизм везде един — создание юзера через процессор security/user/create. Конечно, немного расширенным для HybridAuth, но юзер полностью валидный.

Login не использует родной процессор для регистрации пользователей, и следовательно не выполняются родные плагин-ивенты

Ну я могу только поздравить авторов Login с таким решением. Еще один повод его не использовать.

не знаю, поправил ты или нет, но на modxcloud.com твой пакет барахлил из-за известных их проблем с сессиями, он у меня тупо не работал там.

Да, поправил, это из-за php-apc.

И, в чем вопрос? Что у юзера 2 учетки на сайте и он не знает, что делает?

Если на сайте есть Login или Office, то можно авторизоваться во вторую учетку через них, и привязать соцсеть обратно.
Если нет — пусть в таком случае пишет админу и тот перепривязывает его вручную, для этого нужно просто сменить internalKey в соответствующей записи таблицы HybridAuth.

По моему, с прозрачными PNG он будет нормально работать только при использовании ImageMagick.

К сожалению, сейчас времени нет.

Тут несколько вариантов:
1. Вызов pdoResources по категориям, а в чанке вызов msProducts для категории.
2. Вызов pdoMenu с leftJoin свойств товара msProductData.
3. Свой сниппет

Все javascript примочки находятся в одном файле default.js.

Это ошибка, обновись на последнюю версию, там исправлено.

В принципе, идея не такая уж и плохая, просто мне не нравится, что это всё предлагается делать Василию.

А как же сообщество? А как же другие разработчики? Мне вот, честно, просто не интересно что-то дальше улучшать.

В e-commerce есть не писанное правило, чтобы все изображения товаров смотрели в одну сторону.
Чтобы избежать редактирования товара, предлагаю сделать в minishop возможность отразить товар.

Блин, да это просто прикидка, сколько посещений выдержит тариф, в теории.

Мне кажется, что вряд ли на твой сайт ходит миллион посетителей в сутки, так что можно не беспокоиться о процессах php.

Процессы php — это количество одновременно обрабатываемых запросов. Если все процессы заняты, то юзер ждет, пока один из них освободится.

modx.pro крутится на тарифе «Рабочий» за 200 рублей. У нас в среднем одна страница генерируется за 0.4 сек, это значит, что при 6 рабочих процессах php он сможет обслужить 12 человек в секунду — а это примерно миллион посещений в сутки.

Количество страниц, юзеров и комментариев можно глянуть здесь.

Напиши плагин на событие OnDocFormRender. Там будет объект $resource, которому можно сделать

$resource->set('description', $resource->getTVValue('mytv'));

Вот пример работы с этим событием.

У Linode минимальный тариф — 1 гигабайт ОЗУ. Увеличивайте memory_limit в 2 раза смело, до 256 Мб.

Что-то странное на 255 строке. Не должно кушать столько памяти при простой склейке массивов с конфигами. Наверное, там еще массив с ресурсами или что-то такое.

А что там в этом файле на 225 строке? Наверное, какая-нибудь работа с ресурсами, которых на сайте очень много?

В настройках стоит уже максимально возможное значение.

Хостинг не позволяет выделить больше памяти?

msGallery выводит готовую галерею картинок, а не как ты хочешь.

Поэтому, нужно работать напрямую с базой данных сниппетом pdoResources. Параметр &class указывает, что мы запрашиваем не modResource (документы), а msProductFile (картинки).

И здесь не параметр &parent (родитель документа), а условие в &where (фильтрация по колонке таблицы msProductFile).

Если тебе все это непонятно, но хочется понять — рекомендую мой платный курс по созданию сайта в MODX, в частности уроки про pdoTools.

Судя по картинкам, это просто гениально!

У меня была идея сделать как в PhpStorm — переход на редактирования чанка по Ctrl+B на его имени в шаблоне, но так и не придумал, как это удобно сделать.

А тут всё просто, понятно, и никаких лишних переходов. Отлично!

[[!pdoResources?
	&class=`msProductFile`
	&where=`{"product_id":10, "parent":0}`
	&sortby=`id`
	&sortdir=`asc`
]]

parent = 0 — это выборка именно большой картинки, потому что у превьюшек parent всегда не 0, а id существующей картинки. Ну а product_id понятно что — id нужного товара.

Друзья, осваивайте уже pdoTools.

все что я видел, реализовано для 1с-Битрикс или других CMS, для CMS ModX даже ничего такого нет

store.simpledream.ru/msklad