Вопросы специалистов

Багрепорт

Объявления о работе

Blog by Fi1osof

Smarty RSORT | register_modifier

проблема с redeclare class

Attempt to save lazy object при повторном сохранении объекта в процессоре

xPDO: все поля присоединённых таблиц типизирует как строковые

FormIt не хочет со мной дружить.(помогите наладить отношения)

Проблема с магазином на miniShop2 - срочна нужна помощь!

Minishop2. Пересчет заказа в админке

MODX Meetup в Краснодаре

Фабрика сайтов проиграла суд

Фильтраия категорий + лейзилоад

В Казань заглядывай ;)

Ну, если вдруг буду, маякну. В прошлом году был, но совсем проездом, просто мимо проезжали, заехали.

Ну, если вдруг буду, маякну. В прошлом году был, н

Конечно, обязательно заглядывай, если что на связи.

Конечно, обязательно заглядывай, если что на связи

rsort с ассоциативным массивом не работает, пробуйте arsort

rsort с ассоциативным массивом не работает, пробуй

спасибо за подсказку упустил я этот момент.
 

но, проблема не в работе сортировки а в том как ее прикрутить правильно

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

спасибо за подсказку упустил я этот момент. но, пр

а что в логе modx?

1) return rsort($array) — вернет TRUE;
 2) модификатор в smarty можно добавить положив в core/components/modxsmarty/smarty_plugins файлик: modifier.arsort.php
 

<?php
function smarty_modifier_arsort($array) {
        arsort($array);
        return $array;
}


{$a=["d" => "lemon", "a" => "orange", "b" => "banana", "c" => "apple"]}
{var_dump($a)}
//array(4) { ["d"]=> string(5) "lemon" ["a"]=> string(6) "orange" ["b"]=> string(6) "banana" ["c"]=> string(5) "apple" }
{var_dump($a|arsort)}
//array(4) { ["a"]=> string(6) "orange" ["d"]=> string(5) "lemon" ["b"]=> string(6) "banana" ["c"]=> string(5) "apple" }


1) return rsort($array) — вернет TRUE;
 2) модификатор в smarty можно добавить положив в core/components/modxsmarty/smarty_plugins файлик: modifier.arsort.php <?php
function smarty_modifier_arsort($array) {
        arsort($array);
        return $array;
} 3) получаем такое: {$a=["d" => "lemon", "a" => "orange", "b" => "banana", "c" => "apple"]}
{var_dump($a)}
//array(4) { ["d"]=> string(5) "lemon" ["a"]=> string(6) "orange" ["b"]=> string(6) "banana" ["c"]=> string(5) "apple" }
{var_dump($a|arsort)}
//array(4) { ["a"]=> string(6) "orange" ["d"]=> string(5) "lemon" ["b"]=> string(6) "banana" ["c"]=> string(5) "apple" } кактотак…

1) return rsort($array) — вернет TRUE;
 2) модифик

спасибо круто

Чаще всего такое происходит, когда в мап-файле не для всех колонок есть описания. Смотри ветку здесь.
 

На счет твоего сохранения двух объектов: как я понимаю, это на самом деле повторное сохранение одного и того же объекта, просто в первом случае он создается новый, а во втором он дергается из базы. В целом твой процессор логически не правильный. Исключение — это только если ты допускаешь, что созданный $secondOp может оставаться сохраненным в базе данных, даже если первичный объект не удалось сохранить. Надо же понимать, что в beforeSet() create-процессора $this->object еще не сохранен, и у него нет ID-шника. При попытке выполнения этого процессора у тебя еще в beforeSet() сохраняется вторичный объект, хотя в итоге этот метод может вернуть ошибку (а если не он, то еще есть beforeSave(), который так же может вернуть ошибку), и первичный объект не сохранится, а вторичный объект уже будет в БД. Все-таки гораздо правильней в подобных случаях через связанные объекты делать. То есть задай связи этим двум классам и в beforeSet() пропиши типа $this->object->secondOp = $this->modx->newObject('Operation'); И при сохранении первичного объекта у тебя автоматически и вторичный сохранится. Конечно и здесь есть логические ошибки в xPDO, ибо при сохранении первичного объекта сначала сохраняются вторичные объекты, и только потом первичный (а потом и опять вторичные), но здесь уже вероятность ошибок будет гораздо меньше. Плюс к этому ты на любом этапе до сохранения первичного объекта можешь устанавливать любые значения вторичному объекту, и он будет сохранен только при попытке сохранить первичный объект. Если до первичного объекта дело не дойдет, то и вторичный не будет записан в БД.

Илья, привет. Чаще всего такое происходит, когда в мап-файле не для всех колонок есть описания. Смотри ветку здесь. На счет твоего сохранения двух объектов: как я понимаю, это на самом деле повторное сохранение одного и того же объекта, просто в первом случае он создается новый, а во втором он дергается из базы. В целом твой процессор логически не правильный. Исключение — это только если ты допускаешь, что созданный $secondOp может оставаться сохраненным в базе данных, даже если первичный объект не удалось сохранить. Надо же понимать, что в beforeSet() create-процессора $this->object еще не сохранен, и у него нет ID-шника. При попытке выполнения этого процессора у тебя еще в beforeSet() сохраняется вторичный объект, хотя в итоге этот метод может вернуть ошибку (а если не он, то еще есть beforeSave(), который так же может вернуть ошибку), и первичный объект не сохранится, а вторичный объект уже будет в БД. Все-таки гораздо правильней в подобных случаях через связанные объекты делать. То есть задай связи этим двум классам и в beforeSet() пропиши типа $this->object->secondOp = $this->modx->newObject('Operation'); И при сохранении первичного объекта у тебя автоматически и вторичный сохранится. Конечно и здесь есть логические ошибки в xPDO, ибо при сохранении первичного объекта сначала сохраняются вторичные объекты, и только потом первичный (а потом и опять вторичные), но здесь уже вероятность ошибок будет гораздо меньше. Плюс к этому ты на любом этапе до сохранения первичного объекта можешь устанавливать любые значения вторичному объекту, и он будет сохранен только при попытке сохранить первичный объект. Если до первичного объекта дело не дойдет, то и вторичный не будет записан в БД.

Илья, привет. Чаще всего такое происходит, когда в

О, а точно, спасибо, переделаю через связанные объекты. Посмотрим, что будет))

О, а точно, спасибо, переделаю через связанные объ

Но это не решит твоей проблемы с лейзи. Проверяй мапу. Ссылку я дал.

Но это не решит твоей проблемы с лейзи. Проверяй м

Проблема в том, что вы все не по фэншую делает. modPHPMailer не является наследником класса modProcessor, а потому его нельзя использовать как основу для процессора. Правильней вашим процессором расширить modProcessor и в методе process() получить сервис почты. $mailer = $this->modx->getService('mail.modPhpMailer');
 

P.S. И не пишите никогда такого: dirname(dirname(dirname(dirname(dirname(dirname(dirname(__FILE__))))))).'/model/modx/mail/modphpmailer.class.php';
 Правильней MODX_CORE_PATH.'model/modx/mail/modphpmailer.class.php';
 А в предложенном мной варианте этого вообще не нужно.

Проблема в том, что вы все не по фэншую делает. modPHPMailer не является наследником класса modProcessor, а потому его нельзя использовать как основу для процессора. Правильней вашим процессором расширить modProcessor и в методе process() получить сервис почты. $mailer = $this->modx->getService('mail.modPhpMailer'); P.S. И не пишите никогда такого: dirname(dirname(dirname(dirname(dirname(dirname(dirname(__FILE__))))))).'/model/modx/mail/modphpmailer.class.php';
 Правильней MODX_CORE_PATH.'model/modx/mail/modphpmailer.class.php';
 А в предложенном мной варианте этого вообще не нужно.

Проблема в том, что вы все не по фэншую делает. mo

Пишу здесь результаты переписки.
 

У вас там логика просто в интерфейсе не верно построена. У вас на изменение способа доставки 4 запрос отправляется. joxi.ru/DrlaPn9iEYodmP А на изменение кол-ва товаров только три. Это говорит о том, что части интерфейса не связаны с собой. У нас в интерфейсе изменение любого элемента вызывает запрос на сервер на изменение, после чего выполняется запрос опять на сервер на получение всех актуальных данных корзины, после чего выполняется апдейт всех элементов, которые выводят стоимость (хоть 100500). У вас же для блока доставок одна логика, для блока товаров другая. Поэтому и проблемы.

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

Пишу здесь результаты переписки. У вас там логика просто в интерфейсе не верно построена. У вас на изменение способа доставки 4 запрос отправляется. joxi.ru/DrlaPn9iEYodmP А на изменение кол-ва товаров только три. Это говорит о том, что части интерфейса не связаны с собой. У нас в интерфейсе изменение любого элемента вызывает запрос на сервер на изменение, после чего выполняется запрос опять на сервер на получение всех актуальных данных корзины, после чего выполняется апдейт всех элементов, которые выводят стоимость (хоть 100500). У вас же для блока доставок одна логика, для блока товаров другая. Поэтому и проблемы. Проблема явно проявляется, когда на странице управления заказом начинаешь менять и способы доставки и кол-во товаров.

Пишу здесь результаты переписки. У вас там логика 

Спасибо большое.
 Замечание учтено исправлюсь

ОК. По результатам отпишитесь помогло ли.

Заставить — никак. Он не может знать является ли указанный алиас алиасом xPDO-объекта или просто алиас временной таблицы (на самом деле может, но, думаю, не будет этого делать, слишком много тонкостей и вариантов здесь). А вот сформировать правильный запрос можно.
 

$query->innerJoin('modTemplateVarTemplate', 'TVValues', "TVValues.contentid = modResource.id AND TVValues.tmplvarid = 8");

Если уж очень хочется именно в where засунуть условие, то так:
 

$query->where(array('TVValues.tmplvarid = 8'));

P.S. И вероятно предполагалось modTemplateVarResource, а не modTemplateVarTemplate.

Заставить — никак. Он не может знать является ли указанный алиас алиасом xPDO-объекта или просто алиас временной таблицы (на самом деле может, но, думаю, не будет этого делать, слишком много тонкостей и вариантов здесь). А вот сформировать правильный запрос можно. $query->innerJoin('modTemplateVarTemplate', 'TVValues', "TVValues.contentid = modResource.id AND TVValues.tmplvarid = 8"); Если уж очень хочется именно в where засунуть условие, то так: $query->where(array('TVValues.tmplvarid = 8')); P.S. И вероятно предполагалось modTemplateVarResource, а не modTemplateVarTemplate.

Заставить — никак. Он не может знать является ли у

P.S. И вероятно предполагалось modTemplateVarResource, а не modTemplateVarTemplate. 

Он не может знать является ли указанный алиас алиасом xPDO-объекта или просто алиас временной таблицы

Так ведь в методе innerJoin первым параметром передаётся имя xPDO-объекта, вторым псевдоним, третьим — условие с использованием этого псевдонима. Если название таблицы в составе условия совпадает с псевдонимом, указанным вторым параметром, то однозначно это псевдоним xPDO-объекта, указанного первым параметром. Иначе быть не может, поскольку в выборке не могут участвовать 2 таблицы с одинаковыми псевдонимами.
 

Т.е. алгоритм проверки должен быть таким:
 1) если имя таблицы в условии совпадает с псевдонимом присоединяемой таблицы => это и есть присоединяемая таблица => типизируем как положено
 2) если имя таблицы в условии не совпадает с псевдонимом присоединяемой таблицы => парсим поле как строковое (т.к. ситуация неопределённая)
 И xPDO этой элементарной проверки почему-то не выполняет…
 

А вот сформировать правильный запрос можно.

Я просто пример привёл такой со стандартной таблицей. В этом примере — да, логически правильнее внести фильтрацию по TV в ON. Но во многих других случаях (в т.ч. и с участием собственных таблиц) дополнительные условия должны содержаться в WHERE. Особенно, если запрос большой и частично он строится в одних методах, частично — в других.
 

В любом случае, проблема имеет место, не зависимо от того, где присутствует условие — в WHERE или в ON.


P.S. И вероятно предполагалось modTemplateVarResource, а не modTemplateVarTemplate. Да, верно. Он не может знать является ли указанный алиас алиасом xPDO-объекта или просто алиас временной таблицы Так ведь в методе innerJoin первым параметром передаётся имя xPDO-объекта, вторым псевдоним, третьим — условие с использованием этого псевдонима. Если название таблицы в составе условия совпадает с псевдонимом, указанным вторым параметром, то однозначно это псевдоним xPDO-объекта, указанного первым параметром. Иначе быть не может, поскольку в выборке не могут участвовать 2 таблицы с одинаковыми псевдонимами. Т.е. алгоритм проверки должен быть таким:
 1) если имя таблицы в условии совпадает с псевдонимом присоединяемой таблицы => это и есть присоединяемая таблица => типизируем как положено
 2) если имя таблицы в условии не совпадает с псевдонимом присоединяемой таблицы => парсим поле как строковое (т.к. ситуация неопределённая)
 И xPDO этой элементарной проверки почему-то не выполняет… А вот сформировать правильный запрос можно. Я просто пример привёл такой со стандартной таблицей. В этом примере — да, логически правильнее внести фильтрацию по TV в ON. Но во многих других случаях (в т.ч. и с участием собственных таблиц) дополнительные условия должны содержаться в WHERE. Особенно, если запрос большой и частично он строится в одних методах, частично — в других. В любом случае, проблема имеет место, не зависимо от того, где присутствует условие — в WHERE или в ON.

P.S. И вероятно предполагалось modTemplateVarResou

Вообще, у меня в коде много десятков подобных запросов по всему коду. Всегда полагался на типизацию xPDO. А сейчас, похоже, придётся все запросы перешерстить. Странно, что все запросы выполнялись корректно… до сегодняшнего дня…
 

Всё-таки отказ от автоматической xPDO-типизации в условиях — не совсем хороший вариант. Хотя бы, те же самые операторы IN. Напрашивается такое решение: обёртка для join'ов, в которых:
 а) вручную читаем мета-данные
 б) определяем тип
 в) корректируем тип поля в объекте xPDOQuery (query['joins'][...])
 

Здорово поможете, если навскидку состряпаете эту обёртку. Если нет — поковыряюсь сам…

Вообще, у меня в коде много десятков подобных запросов по всему коду. Всегда полагался на типизацию xPDO. А сейчас, похоже, придётся все запросы перешерстить. Странно, что все запросы выполнялись корректно… до сегодняшнего дня… Всё-таки отказ от автоматической xPDO-типизации в условиях — не совсем хороший вариант. Хотя бы, те же самые операторы IN. Напрашивается такое решение: обёртка для join'ов, в которых:
 а) вручную читаем мета-данные
 б) определяем тип
 в) корректируем тип поля в объекте xPDOQuery (query['joins'][...]) Здорово поможете, если навскидку состряпаете эту обёртку. Если нет — поковыряюсь сам…

Вообще, у меня в коде много десятков подобных запр

Если уж очень хочется именно в where засунуть условие, то так:
 $query->where(array('TVValues.tmplvarid = 8'));

И xPDO этой элементарной проверки почему-то не выполняет…

Отправляйте свой PR в xPDO, не вопрос.

Если уж очень хочется именно в where засунуть условие, то так:
 $query->where(array('TVValues.tmplvarid = 8')); И xPDO этой элементарной проверки почему-то не выполняет… Отправляйте свой PR в xPDO, не вопрос.

Если уж очень хочется именно в where засунуть усло

Вообще, у меня в коде много десятков подобных запросов по всему коду. Всегда полагался на типизацию xPDO. А сейчас, похоже, придётся все запросы перешерстить. Странно, что все запросы выполнялись корректно… до сегодняшнего дня…

У вас где-то запрос не так выполняется (имеется ввиду получаете не те результаты)? Мускул сам типизацию проведет, это вам не сортировка. Хотите более полный контроль над типами? — юзайте CAST, CONVERT и т.п.

Вообще, у меня в коде много десятков подобных запросов по всему коду. Всегда полагался на типизацию xPDO. А сейчас, похоже, придётся все запросы перешерстить. Странно, что все запросы выполнялись корректно… до сегодняшнего дня… У вас где-то запрос не так выполняется (имеется ввиду получаете не те результаты)? Мускул сам типизацию проведет, это вам не сортировка. Хотите более полный контроль над типами? — юзайте CAST, CONVERT и т.п.

Здорово поможете, если навскидку состряпаете эту обёртку. Если нет — поковыряюсь сам… 

Не вижу смысла. Не помогу с этим.

Здорово поможете, если навскидку состряпаете эту обёртку. Если нет — поковыряюсь сам… Не вижу смысла. Не помогу с этим.

Здорово поможете, если навскидку состряпаете эту о

У вас где-то запрос не так выполняется (имеется ввиду получаете не те результаты)? Мускул сам типизацию проведет, это вам не сортировка.

Именно. Сравнение числового поля со строковой константой всегда даёт false (в этом случае MySQL числовые значения поля приводит к строковому типу)

У вас где-то запрос не так выполняется (имеется ввиду получаете не те результаты)? Мускул сам типизацию проведет, это вам не сортировка. Именно. Сравнение числового поля со строковой константой всегда даёт false (в этом случае MySQL числовые значения поля приводит к строковому типу)

У вас где-то запрос не так выполняется (имеется вв

Тьфу, что-то не то пишу. Должно нормально работать сравнение. Проверю ещё раз…

Тьфу, что-то не то пишу. Должно нормально работать

Сравнение числового поля со строковой константой всегда даёт false (в этом случае MySQL числовые значения поля приводит к строковому типу) 

Да, вы явно не то пишете. Все будет ОК работать. Это в сортировках может получиться, что '87' будет меньше чем '9', но 8 == '8'.

Сравнение числового поля со строковой константой всегда даёт false (в этом случае MySQL числовые значения поля приводит к строковому типу) Да, вы явно не то пишете. Все будет ОК работать. Это в сортировках может получиться, что '87' будет меньше чем '9', но 8 == '8'.

Сравнение числового поля со строковой константой в

Поздравляю! Так им и надо))

Спасибо:)

Да не за что)) Фабрика не одна такая, многие крупные компании подобное вытворяют, либо скрытые платежи, либо только свой хостинг (без доступов к ФТП и в 1,5 — 2 раза дороже), либо мелким клиентам некачественно работу делают.

Да не за что)) Фабрика не одна такая, многие крупн

Это в сортировках может получиться, что '87' будет меньше чем '9', но 8 == '8'. 

И в условиях сравнения тоже.

Это в сортировках может получиться, что '87' будет меньше чем '9', но 8 == '8'. И в условиях сравнения тоже.

Это в сортировках может получиться, что '87' будет

Поздравляю, поделом им.

Больше/меньше — да, но равно/не равно — нет.

Спасибо

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

Всё равно некошерно. Ладно, с TV понятно — если та

Еще раз — шлите пуллреквесты, улучшайте работу MODX-а. Я вот шлю. На сегодня более 10% всех активных PR в MODX — мои. И вы можете приложить усилия, чтобы MODX стал лучше.

Еще раз — шлите пуллреквесты, улучшайте работу MOD

На английском не очень получается. Впрочем, писал уже:
 github.com/modxcms/revolution/issues/12307
 ноль внимания…
 

Хотя в версии 2.3.3 они там логику чуть изменили (так, что в описанных в этой теме условиях ошибки больше не вылезали), но «корячность» этой логики сохранилась (а может, я её не понимаю). Так или иначе в 2.3.3 эти 2 ошибки по-прежнему иногда вылезают, но гораздо реже и при других условиях (при каких — неизвестно).
 

Что касается сабжа, то лучше я обёртку напишу. Так будет надёжнее.

На английском не очень получается. Впрочем, писал уже:
 github.com/modxcms/revolution/issues/12307
 ноль внимания… Хотя в версии 2.3.3 они там логику чуть изменили (так, что в описанных в этой теме условиях ошибки больше не вылезали), но «корячность» этой логики сохранилась (а может, я её не понимаю). Так или иначе в 2.3.3 эти 2 ошибки по-прежнему иногда вылезают, но гораздо реже и при других условиях (при каких — неизвестно). Что касается сабжа, то лучше я обёртку напишу. Так будет надёжнее.

На английском не очень получается. Впрочем, писал 

Issue — это только пожелания, обсуждения. Отправить готовый код — более предметно.

Issue — это только пожелания, обсуждения. Отправит

Что касается сабжа, то лучше я обёртку напишу. Так будет надёжнее. 

Нет. С разбегу не получится. Не 5 минут…
 

Логика должна быть такой. Перед выполнением метода prepare() запускается наша супер-функция (или метод), которая в объекте xPDOQuery делает следующее:
 1) проходит по всем JOIN-таблицам и в их condition'ах корректирует ['condition']['bind']['type'], если он не соответствует модели таблицы
 2) нестроковые условия по TV полям преобразовывает в их SQL-аналоги с использованием CAST'ов в зависимости от типа TV, задаваемого в modx_site_tmplvars
 3) то же самое — для полей, участвующих в ORDER BY и HAVING
 

Тогда работа с xPDO станет сказкой…
 А пока не горит. Нестроковые сравнения (< > <= >=) и сортировки по TV-полям и JOIN-полям оформляем в виде SQL с CAST'ами, всё остальное — оставляем как есть.

Что касается сабжа, то лучше я обёртку напишу. Так будет надёжнее. Нет. С разбегу не получится. Не 5 минут… Логика должна быть такой. Перед выполнением метода prepare() запускается наша супер-функция (или метод), которая в объекте xPDOQuery делает следующее:
 1) проходит по всем JOIN-таблицам и в их condition'ах корректирует ['condition']['bind']['type'], если он не соответствует модели таблицы
 2) нестроковые условия по TV полям преобразовывает в их SQL-аналоги с использованием CAST'ов в зависимости от типа TV, задаваемого в modx_site_tmplvars
 3) то же самое — для полей, участвующих в ORDER BY и HAVING Тогда работа с xPDO станет сказкой…
 А пока не горит. Нестроковые сравнения (< > <= >=) и сортировки по TV-полям и JOIN-полям оформляем в виде SQL с CAST'ами, всё остальное — оставляем как есть.

Что касается сабжа, то лучше я обёртку напишу. Так

Искренние поздравления! Очень радует, когда такие проигрывают по собственным искам. Вселяет надежду :)

Искренние поздравления! Очень радует, когда такие 

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

Поздравляю, Николай! Только на счёт Хабаровска не 

Спасибо. Справедливости ради скажу что вообще всю дорогу ощущал поддержку со стороны Суда. Ничего такого прямого не говорилось и не показывалось, но интуитивно я чувствовал, что они сразу понимали суть дела и были на стороне справедливости.

Спасибо. Справедливости ради скажу что вообще всю 

По месту прописки ответчика. Я там прописан.

Сорри, вряд ли здесь кто-то поможет. Мы с минишопом не работаем. Имеет смысл этот вопрос на модх.про задавать, это же их продукт.

Сорри, вряд ли здесь кто-то поможет. Мы с минишопо

Следил за темой. Искрене рад. Николай мои поздравления!

Следил за темой. Искрене рад. Николай мои поздравл

Спасибо :)

Ого, мужик! Не побоялся трудностей:) с победой!

Спасибо!))

довольно тесно связан с судебной ветвью власти, хотя безусловно тяжело судить о деле не видя его материалов, но думаю что 

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

немножко глупости…
 скорее всего истец просто не смог доказать то чем аргументировал свое исковое заявление
 

Но могу подсоветовать следующее. Я так понимаю дело окончено значит это уже будет не встречный иск а в рамках нового делопроизводства, по сути можно подать на них гражданский иск о компенсации материального и морального ущерба.
 Материальная компенсация рассчитывается из реальных денежных затрат (подкрепленных фин. доками, чеками, выписками) глупостей не выдумывайте зарежут все равно.
 Моральная компенсация рассчитывается исходя из «потолочных опусов» о снижение трудоспособности, подавленном моральном состоянии в связи с иском. Отлично заиметь свидетеля аля заказчик который скажет что хотел заказать у Вас сайт но в связи с делом в суде отказался… ну и т.д.

довольно тесно связан с судебной ветвью власти, хотя безусловно тяжело судить о деле не видя его материалов, но думаю что Таким образом судом официально признано, что мои суждения в отношении качества работы студии «Фабрика сайтов» являются правдивыми и аргументированными. немножко глупости…
 скорее всего истец просто не смог доказать то чем аргументировал свое исковое заявление Но могу подсоветовать следующее. Я так понимаю дело окончено значит это уже будет не встречный иск а в рамках нового делопроизводства, по сути можно подать на них гражданский иск о компенсации материального и морального ущерба.
 Материальная компенсация рассчитывается из реальных денежных затрат (подкрепленных фин. доками, чеками, выписками) глупостей не выдумывайте зарежут все равно.
 Моральная компенсация рассчитывается исходя из «потолочных опусов» о снижение трудоспособности, подавленном моральном состоянии в связи с иском. Отлично заиметь свидетеля аля заказчик который скажет что хотел заказать у Вас сайт но в связи с делом в суде отказался… ну и т.д.

довольно тесно связан с судебной ветвью власти, хо

Статья 152. Защита чести, достоинства и деловой репутации 
 1. Гражданин вправе требовать по суду опровержения порочащих его честь, достоинство или деловую репутацию сведений, если распространивший такие сведения не докажет, что они соответствуют действительности.

Совсем не глупости. Если бы я не доказал этого, то иск был бы удовлетворен. Глупость заключается в другом: хотя у нас презумпция невиновности, доказательство своей правды как раз ложится на ответчика, а не на истца. То есть не истец доказывает, что я не прав, а ответчик доказывает, что он прав. Так что как раз ваше утверждение «скорее всего истец просто не смог доказать то чем аргументировал свое исковое заявление» менее соответствует действительности. Здесь можно было бы сказать, что истец не смог найти аргументы против моих доказательств поданных в суд, но это уже совершенно другая сторона вопроса.

немножко глупости… Статья 152. Защита чести, достоинства и деловой репутации 
 1. Гражданин вправе требовать по суду опровержения порочащих его честь, достоинство или деловую репутацию сведений, если распространивший такие сведения не докажет, что они соответствуют действительности. Совсем не глупости. Если бы я не доказал этого, то иск был бы удовлетворен. Глупость заключается в другом: хотя у нас презумпция невиновности, доказательство своей правды как раз ложится на ответчика, а не на истца. То есть не истец доказывает, что я не прав, а ответчик доказывает, что он прав. Так что как раз ваше утверждение «скорее всего истец просто не смог доказать то чем аргументировал свое исковое заявление» менее соответствует действительности. Здесь можно было бы сказать, что истец не смог найти аргументы против моих доказательств поданных в суд, но это уже совершенно другая сторона вопроса.

немножко глупости… Статья 152. Защита чести, досто

Если что, сам иск выкладывал здесь.

хотя у нас презумпция невиновности, доказательство своей правды как раз ложится на ответчика

рассмеялся даже ))) ох как Вы правы…
 

завтра почитаю иск… заинтересовало дело

хотя у нас презумпция невиновности, доказательство своей правды как раз ложится на ответчика рассмеялся даже ))) ох как Вы правы… завтра почитаю иск… заинтересовало дело

хотя у нас презумпция невиновности, доказательство

Честно сказать, как раз именно этот момент и не давал смеяться. То есть он вообще озадачивал. По моей личной логике они должны были доказывать, что я не прав, собрав и предоставив какие-то экспертизы и т.п. То есть (самое простое) какой-то специалист бы выдал заключение, что нет, качество их работы очень высокое и я зря на них бочку качу. А так нет, достаточно просто подать иск и все и пусть ответчик сам доказывает что он не жираф. Таким образом порог вхождения для подачи очень и очень низок, значительно ниже, чем для ответчика. Можно просто подать иск и надеяться, что ответчик или поленится, или не сможет найти денег на адвоката или типа того, и просто технически проиграет иск. Я уверен, что именно этот низкий порог вхождения и позволил появиться этому иску.

рассмеялся даже ))) Честно сказать, как раз именно этот момент и не давал смеяться. То есть он вообще озадачивал. По моей личной логике они должны были доказывать, что я не прав, собрав и предоставив какие-то экспертизы и т.п. То есть (самое простое) какой-то специалист бы выдал заключение, что нет, качество их работы очень высокое и я зря на них бочку качу. А так нет, достаточно просто подать иск и все и пусть ответчик сам доказывает что он не жираф. Таким образом порог вхождения для подачи очень и очень низок, значительно ниже, чем для ответчика. Можно просто подать иск и надеяться, что ответчик или поленится, или не сможет найти денег на адвоката или типа того, и просто технически проиграет иск. Я уверен, что именно этот низкий порог вхождения и позволил появиться этому иску.

рассмеялся даже ))) Честно сказать, как раз именно

У вас скорее всего проблема не в formIt, а в самой отправке почты.
 

Невозможно запустить функцию mail

Скорее всего проблемы с настройками сервера. 
 Смотрите логи, спрашивайте саппорт хостинга.
 

Установите в админке Console и попробуйте выполнить два кода:
 1. 

Оба письма дойдут вам на почту?

У вас скорее всего проблема не в formIt, а в самой отправке почты. Невозможно запустить функцию mail Скорее всего проблемы с настройками сервера. 
 Смотрите логи, спрашивайте саппорт хостинга. Установите в админке Console и попробуйте выполнить два кода:
 1. mail($to, $subject, $message); 2. $modx->user->sendEmail($message); Оба письма дойдут вам на почту?

У вас скорее всего проблема не в formIt, а в самой

Спасибо за ответ. Я разобрался просто мой хостинг не поддерживал SSL.

Спасибо за ответ. Я разобрался просто мой хостинг 

Ну вот. Разобраться в чем именно проблема — уже залог успешного решения. А то ковыряете совсем не то. Логи наше всё :)

Ну вот. Разобраться в чем именно проблема — уже за

Круто. Поздравления.

Пасиб)

Пжлста. 
 Не фиг наших трогать :)

class SiteWebPublicMailerProcessor extends modProcessor{

    public $body = '';

    public function initialize(){

        $this->setDefaultProperties(
            array(
                'from_email'    =>'no-replay@'.$_SERVER['HTTP_HOST']
                ,'from_name'    =>$this->modx->getOption('site_name')
                ,'body'         =>'hello world!'

            )
        );
/*
* в моем случае существует ресурс с настройками (Твшки)
* оттуда тянем email для отправки
*/
        if ($settings = $this->modx->getObject('modResource',2)){
            $this->setProperty('to_email', $settings->getTVValue('email'));
        }

        if (!$this->getProperty('to_email')){
            $this->addFieldError('to_email', 'Ошибка получения email адреса.');
        }

        if ($this->hasErrors()){
            return 'Возникли ошибки при отправке сообщения.';
        }

        return parent::initialize();
    }

    public function process(){
        $this->body = $this->prepareMailBody();
        if ($this->SendMail()){
            return $this->success('Сообщение успешно отправлено.');
        } else {
            return $this->failure('Сообщение не отправлено.');
        }
    }

    public function prepareMailBody(){
        return '';
    }

    public function SendMail(){
        $this->modx->getService('mail', 'mail.modPHPMailer');
        $this->modx->mail->set(modMail::MAIL_BODY,$this->body);
        $this->modx->mail->set(modMail::MAIL_FROM,$this->getProperty('from_email'));
        $this->modx->mail->set(modMail::MAIL_FROM_NAME,$this->getProperty('from_name'));
        $this->modx->mail->set(modMail::MAIL_SUBJECT,$this->getProperty('subject'));
        $this->modx->mail->address('to', $this->getProperty('to_email'));
        $this->modx->mail->setHTML(true);
        $status = $this->modx->mail->send();
        $this->modx->mail->reset();
        return $status;
    }

}
return 'SiteWebPublicMailerProcessor';


class SiteWebPublicMailerProcessor extends modProc

в версии сайта этот класс расширяется.

В топик добавил ссылку на резолюцию.

Клево. Переделал код так:
 

<?php
class OperationCreateProcessor extends modObjectCreateProcessor {
    
    /* 
     * Процессор создает "Операции" для управления финансами
     * Операция - это расход, приход или перевод со счета на счет
     */
     
    public $classKey = 'Operation';
    public $objectType = 'object';
    
    public function beforeSet() {
        $amount = $this->getProperty('amount');
        switch ($this->getProperty('type')) {
            case 'charge':
                $this->setProperty('amount', -1 * $amount);
                break;
            case 'income': 
                $this->setProperty('amount', 1 * $amount);
                break;
            case 'transfer':
                $this->object->Related = $this->modx->newObject('Operation');
                $this->object->Related->fromArray($this->getProperties());
                $this->object->Related->set('amount', 1 * $amount);
                $this->object->Related->set('account', $this->getProperty('to'));
                $this->object->Related->set('relation_type', $this->getProperty('type'));

                $this->setProperty('amount', -1 * $amount);
                $this->setProperty('account', $this->getProperty('from'));
                $this->setProperty('related', $secondOp->id);
                $this->setProperty('relation_type', $this->getProperty('type'));
                break;
            default:
                $this->modx->error->addField('type', 'Unknown type');
                return false;
        }
        return true;
    }
    
    public function afterSave() {
        if ($this->getProperty('type') == 'transfer') {
            if ($this->object->Related) {
                $this->object->Related->set('related', $this->object->id);
                $this->object->Related->save();
            }
        }
        
        return true;
    }

}

return 'OperationCreateProcessor';

И вот здесь опять вопрос. Вот есть строка, где связанные объекты сохраняются второй раз и в них передаются ключи основного объекта для сохранения связи. Однако у меня без блока afterSave у связанного объекта поле related оказывается незаполненным.
 

// ...
    'Related' => 
    array (
      'class' => 'Operation',
      'local' => 'related',
      'foreign' => 'id',
      'cardinality' => 'one',
      'owner' => 'foreign',
    ),
// ...

По идее должно работать. Но почему-то не хочет…

Клево. Переделал код так: <?php
class OperationCreateProcessor extends modObjectCreateProcessor {
    
    /* 
     * Процессор создает "Операции" для управления финансами
     * Операция - это расход, приход или перевод со счета на счет
     */
     
    public $classKey = 'Operation';
    public $objectType = 'object';
    
    public function beforeSet() {
        $amount = $this->getProperty('amount');
        switch ($this->getProperty('type')) {
            case 'charge':
                $this->setProperty('amount', -1 * $amount);
                break;
            case 'income': 
                $this->setProperty('amount', 1 * $amount);
                break;
            case 'transfer':
                $this->object->Related = $this->modx->newObject('Operation');
                $this->object->Related->fromArray($this->getProperties());
                $this->object->Related->set('amount', 1 * $amount);
                $this->object->Related->set('account', $this->getProperty('to'));
                $this->object->Related->set('relation_type', $this->getProperty('type'));

                $this->setProperty('amount', -1 * $amount);
                $this->setProperty('account', $this->getProperty('from'));
                $this->setProperty('related', $secondOp->id);
                $this->setProperty('relation_type', $this->getProperty('type'));
                break;
            default:
                $this->modx->error->addField('type', 'Unknown type');
                return false;
        }
        return true;
    }
    
    public function afterSave() {
        if ($this->getProperty('type') == 'transfer') {
            if ($this->object->Related) {
                $this->object->Related->set('related', $this->object->id);
                $this->object->Related->save();
            }
        }
        
        return true;
    }

}

return 'OperationCreateProcessor'; И вот здесь опять вопрос. Вот есть строка, где связанные объекты сохраняются второй раз и в них передаются ключи основного объекта для сохранения связи. Однако у меня без блока afterSave у связанного объекта поле related оказывается незаполненным. Вот описание связи: // ...
    'Related' => 
    array (
      'class' => 'Operation',
      'local' => 'related',
      'foreign' => 'id',
      'cardinality' => 'one',
      'owner' => 'foreign',
    ),
// ... По идее должно работать. Но почему-то не хочет…

Клево. Переделал код так: <?php
class OperationCre

Вот теперь код более чистый. Правда рудимент видимо остался — $this->setProperty('related', $secondOp->id); Объекта $secondOp нет у тебя в том методе.
 

По идее должно работать. Но почему-то не хочет… 

У тебя связь неправильно прописана (если я не ошибаюсь, что эта связь прописана для мапы $this->object). У тебя в ней сказано, что owner — foreign, то есть будет использоваться значение из внешнего объекта (из его колонки id (ключ foreign)). То есть это описание для изменения локальной колонки $this->object->related, которая примет значение от $this->object->Related->id, а не наоборот. Если ты хочешь менять колонку внешнего объекта, то мапа должна быть такой:
 

// ...
    'Related' =>
    array (
      'class' => 'Operation',
      'local' => 'id',
      'foreign' => 'related',
      'cardinality' => 'one',
      'owner' => 'local',
    ),
// ...

Вот теперь код более чистый. Правда рудимент видимо остался — $this->setProperty('related', $secondOp->id); Объекта $secondOp нет у тебя в том методе. По идее должно работать. Но почему-то не хочет… У тебя связь неправильно прописана (если я не ошибаюсь, что эта связь прописана для мапы $this->object). У тебя в ней сказано, что owner — foreign, то есть будет использоваться значение из внешнего объекта (из его колонки id (ключ foreign)). То есть это описание для изменения локальной колонки $this->object->related, которая примет значение от $this->object->Related->id, а не наоборот. Если ты хочешь менять колонку внешнего объекта, то мапа должна быть такой: // ...
    'Related' =>
    array (
      'class' => 'Operation',
      'local' => 'id',
      'foreign' => 'related',
      'cardinality' => 'one',
      'owner' => 'local',
    ),
// ...

Вот теперь код более чистый. Правда рудимент видим

$this->setProperty('related', $secondOp->id);

лишняя (related проставит сам MODX, когда будет сохранять основной объект, на основе связи).
 

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

$first = $this->object;
$second = $this->object->Related;
$second->addOne($this->object);

в итоге это не одна связь, а две. Поэтому еще одно сохранение делать придется в любом случае)

Да, строчка $this->setProperty('related', $secondOp->id); лишняя (related проставит сам MODX, когда будет сохранять основной объект, на основе связи). И понял, что без afterSave не обойтись. У меня оба объекта равнозначны и должны быть связаны между собой. То есть $first = $this->object;
$second = $this->object->Related;
$second->addOne($this->object); в итоге это не одна связь, а две. Поэтому еще одно сохранение делать придется в любом случае)

Да, строчка $this->setProperty('related', $secondO

У тебя связь один-к-одному. Зачем тебе две равнозначные связи на два объекта? Ты через один всегда сможешь понять есть у тебя второй объект или нет. 98% у тебя не оптимальная структура.