Волков Николай

Увидел сообщение, что в schema:

<field key="usluga" dbtype="set" precision="'стирка','прачка','уборка'" phptype="string" null="false" />

Я хренею, как можно было не найти через xPDO способы для получения значений у колонки, но при этом найти этот вид колонок для БД.

Друг, для указания массива значений возможных ты выбрал самый %:% способ. А что будет, если потребуется добавить еще один вариант услуги? Ну или банально заказчик потребует сделать все с заглавной буквы?

$class — имя класса из schema для нужной таблицы.
$column — название колонки для получения.
$sortdir — Направление сортировки у значений
$query — фильтр для поиска среди значений
$limit — кол-во значений для вывода
$offset — сколько позиций пропустить для вывода

$array = array();

if(!isset($limit)) $limit = 0;
if(!isset($offset)) $offset = 0;
if(!isset($sortdir)) $sortdir = 'ASC';

$c = $modx->newQuery( $class );
$c->select($column);
$c->sortby($column);
$c->sortdir($sortdir);
$c->groupby($column);
$c->limit($limit, $offset);
if(!empty($query)){
	$values[] = $query;
	$c->where(array($column.':LIKE'=>'%'.$query.'%'));
}

if($c->prepare() && $c->stmt->execute()){
	$values = array_merge($values, $c->stmt->fetchAll(PDO::FETCH_COLUMN, 0));
}

Небольшая поправка: я тут вспомнил, что у меня есть сайты, где 1314 субдоменов (по одному на город в РФ + работа с адресом каждого субдомена из админки) :-) Там я не использовал контексты и это бы не прокатило :-) Но случай все равно частный, т.к. единичным случаям до сих пор неизвестно, что в SEO такое не прокатит, а скорее наоборот:-)

Прости меня, Господи… Но зачем значения хранить в Сессии? Мне уже плохо от одной только мысли, что в сессии будет храниться код для счетчиков, вроде Метрики… Чем не устраивает кэш? Благо, под субдомены обычно используются контексты, в их кэш и заносилось бы…

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

Все, что имеет отношение к коду — будет :-) Все что не имеет — это уже другой вопрос…
На самом деле мое мнение на счет большинства систем по недвижке очень простое — хозяевам агенств, агентам и т.д. неизвестно, что существует такая вещь, как «Геокодирование». Смысл в том, что объекты позиционируются по координатам широты и долготы (к примеру, 37.587137 55.770882), а не названий «городов», «регионов», «улиц» и т.д. Благодаря этому через тот же yandex.maps api можно получать тьму информации и инструментов для работы (хоть точное расстояние между точками в метрах, при чем не по прямой, а с учетом того, что потребуется обходить дома и т.п.)… Яркий пример: realty.yandex.ru
Без понимания этих основ составить ПРАВИЛЬНОЕ тех задание практически нереально и в большинстве случаев будет происходить позиционирование по названиям улиц, номеров домов и т.д.… У них по ходу работы накопятся тьма дубликатов/копий из-за того, что кто-то где-то написал адрес с большой буквы, а кто-то с маленькой… Или где-то сократил «площадь» до «пл.» с точкой, а кто-то до «пл» без точки… ну и т.д… Как следствие все летит к чертям, т.к. в итоге получается бардак и отсутствие структурированности, т.к. начинает через работать поиск и фильтрация ну или т.п. Да, защит от дурак можно напридумываиь миллион и более, но все равно рано или поздно они не спасут.
К чему я это… Понятное дело, что почти любой агент по недвижке на одном месте все эти координаты крутил. Но с другой стороны и большинство программистов аналогично про них не задумывались, т.к. слишком специфичная тема. И из-за ошибки в самой основе основ только и получается, что пытаться

что то подобное создать в Крыму, СПП (система партнёрских продаж).

А что за закрытая база недвижимости?

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

Зашел на сайт ваш и должен отметить, что он клевый внешне :-) Сам как раз сейчас над закрытой базой по объектам недвижимости вожусь и от тучи возни с правами доступов уже голова отказывается работать:-)

P.S. А что считается в консоли браузера?

Я удивился, т.к. мне почему-то кажется, что если имеется проблема с «байтами», «кавычками» и тп, то она должна была всплыть несколько раньше, чем через 2 года, после выпуска последней версии…

Проблем, связанных с кодировкой вообще не было? Виноват только str_replace?

ну давай я передам в console не число а массив… Или что там в pdoFetch передается, чтобы преобразовать в более сложный where?

Короче, вместо него $modx->sendErrorPage();

Нашел еще ошибку:

в getOrder.php ты вначале:

define('MODX_API_MODE', true);

Далее во-первых нет проверки на пустой id в POST
Ну а во-вторых ты sendRedirect делаешь, если не AJAX.
Что интересно: MODX_API_MODE не даст запустить handleRequest… Не понятен redirect. Нужно сразу exit хотя бы или т.п.

Ок. Через минут скину сюда код

И снова не за что :-)

Ну и последнее… Напиши правильно для кого адресована статья :-) Что за Новчики? :-)

это НАУЧИТЬ НОВЧИКОВ

github.com/bezumkin/miniShop2/blob/e8d674f0ebf80450c3bb3830dfd49413f44a84ff/core/components/minishop2/model/minishop2/mysql/msorder.map.inc.php#L277

Снова ссылка на github… Обрати внимание чей он ;-)

как должно быть по вашему, вот этого я понять не могу

Так что не только по-моему ;-)

'on' => 'msOrderAddress.id = msOrder.id'

На гите косяк у связи

В msOrder поле для связи address!

'on' => 'msOrderAddress.id = msOrder.address'

для pdoResources

"msOrderAddress":{"class":"msOrderAddress", "on":"msOrderAddress.id = msOrder.address"}

'on' => 'msOrderAddress.id = msOrder.id'

На гите косяк у связи

Более того на github у тебя снова:



github.com/pavel-one/Modx-Custom-Orders-MS2/blob/7f37b69d4bcf1515a5dde3e191dd812e8c6aeedb/assets/components/MyCustomOrders/action/getOrder.php#L32

А Еще
github.com/pavel-one/Modx-Custom-Orders-MS2/blob/7f37b69d4bcf1515a5dde3e191dd812e8c6aeedb/assets/components/MyCustomOrders/action/getOrder.php#L43
и
github.com/pavel-one/Modx-Custom-Orders-MS2/blob/7f37b69d4bcf1515a5dde3e191dd812e8c6aeedb/assets/components/MyCustomOrders/action/getOrder.php#L9

Не продуман момент для случаев, когда контекст не web

Не за что. Очень распространенная ошибка на самом деле. Раньше у document был event на готовность, а теперь Promise. Но как бы оно ни было в данном случае ВООБЩЕ по фигу, т.к. у тебя просто обработку на клик вешает, а для этого вообще дожидаться готовности не нужно да нет никаких причин ждать чего либо вообще, кроме загрузки непосредственного самого jQuery :-)
Короче, тупо убери document и просто click оставь и будет счастье

Еще раз прошу не верить в то, что имеет место быть банальная опечатка: