Fi1osof

Роман, ткните носом (дайте ссылку), где именно в правилах магазина описан порядок возврата средств.

Опубликовать может кто угодно.

От Шона не стоит уже ждать, он давно от дел с MODX отошел. Но может кто-то обновит.

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

ПЕРЕЧЕНЬ
непродовольственных товаров надлежащего качества, не подлежащих возврату или обмену на аналогичный товар других размера, формы, габарита, фасона, расцветки или комплектации
(в ред. Постановлений Правительства РФ от 20.10.1998 N 1222, от 06.02.2002 N 81)
…
11. Технически сложные товары бытового назначения, на которые установлены гарантийные сроки (станки металлорежущие и деревообрабатывающие бытовые; электробытовые машины и приборы; бытовая радиоэлектронная аппаратура; бытовая вычислительная и множительная техника; фото- и киноаппаратура; телефонные аппараты и факсимильная аппаратура; электромузыкальные инструменты; игрушки электронные, бытовое газовое оборудование и устройства).
…
14. Непериодические издания (книги, брошюры, альбомы, картографические и нотные издания, листовые изоиздания, календари, буклеты, издания, воспроизведенные на технических носителях информации).

Программное обеспечение (оно суть «воспроизведенные на технических носителях информации») не подлежат возврату. Он сейчас купил, скопировал, через 3 минуты попросил возврата денег, и что? Собственно, у меня в модсторе один пользователь попросил возврата средств (хотя ему была оказана помощь в настройке). На это он получил отказ. С его стороны последовали обвинения в мошенничестве, угрозы в уголовном преследовании и т.п. (в общем, всячески насмешил). Только через Леонида ему удалось вернуть часть суммы.
Пользуясь случаем еще раз отмечу, что у нас возврата денег за программное обеспечение нет на основании Закона о защите прав потребителей.

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

Не за что!

записей с parent = NULL — нет, только фактические ID

А с parent =0 есть записи? Есть хотя бы процентов 10 от общего количества?

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

Наверняка объяснение логическое есть. Но что интересно, компонент работает так, что с базой данных работает только когда скрипт полностью отработал, то есть сохранение объекта запроса (и вместе с ним всего остального), выполняется уже когда MODX отправил все данные во фронт и выполняет exit; (навешана функция через register_shutdown_function()).
Ради интереса, установите опять новую версию и в файле core/components/modmonitor/model/modmonitor.class.php в методе saveRequest() пропишите сразу return; чтобы тело функции не выполнялось. И если все равно тормозить будет, значит действительно где-то на уровне сбора информации о плагинах (что крайне удивительно будет). А если не будет тормозов, значит рекурсия на уровне получения дочерних элементов запроса, буду запросы изучать дополнительно.

Странно, поле не нулевое. Тогда без детального осмотра на стороне проекта ничего точно не получится сказать, пока на других проектах не было прецедентов.
Вечером выложу обновленный пакет с настройкой включения-отключения логирования плагинов, но вообще отладка плагинов — очень полезная штука, так что хорошо бы разобраться с ней. Можете обезличенный дамп сайта сделать? (контент и заголовки затереть, а так же емейлы, юзернеймы, комменты и т.п.).

P.S. Ок, просьбу учту.

Мне только структуру таблиц надо. Можно в phpMyAdmin сделать экспорт этих таблиц, но только структуру, данные не надо выгружать. Да, туда же закиньте.

Из-за самого сбора данных — нет, там механизм простой. Но если поля нулевые, то с этим бага возникает. С этим столкнулся, когда делал вложенность. Я сразу объекты не сохраняю, все набивается через связи в основной объект текущего запроса.

$childs = array();
$childs[] = $item;
$childs[] = $item;
// ...
$request->Children = $childs;

Это позволяет в процессе набивать статистику, но не сохранять ничего, если не сохраняется основной объект запроса. А если уже мы его сохраняем, тогда и все дочерние элементы сохраняются.

Но когда сделал вложенность, структура данных получилась такая:

$childs = array();
$childs[] = $item;

$childs_2 = array();
$childs_2 [] = $item;
$childs_2 [] = $item;

$item->Children = $childs_2;

$childs[] = $item;
// ...
$request->Children = $childs;

На уровне втором и ниже связь получается не Запрос-Элемент, а Элемент-Элемент, и при сохранении таких элементов id запроса не задается им (так как у них нет прямого родителя Запрос).

В итоге я на сохранение элементов прописал типа foreach($this->Children). И вот тут бага и проявилась: null-поля надо проверять именно как is null, а здесь xPDO видимо формирует запрос типа = null или = 0, и в таком случае он получал вообще все элементы, у которых поле parent = null. В таком случае да, если в базе элементов уже дофига, тут просто не хватает ресурсов. Если поле задавать не нулевое и значение по умолчанию задавать 0, тогда такой фигни не происходит.

Владимир, проверьте структуру таблиц монитора (modmonitor_request и modmonitor_request_items). Там поля parent случайно не nullable? И нет ли записей с parent = NULL?

ОК, скинете, вечером посмотрю.

Вообще он практически никак не должен влиять на скорость выполнения. Отладка плагинов пишется напрямую в кеш плагинов, то есть сами объекты плагинов никак не модифицируются. А там просто фиксируется время выполнения. Надо будет детальней изучать.
почта n.lanets@modxclub.ru

Сколько времени он стал и на какое событие отжирать время?

P.S. настройку сделаю.