Что вы на денверах все MODX в папку суете?..
- Правильно все-таки отдельный хост делать.
- В .htaccess надо RewriteBase соответствующий поставить. Сайт же фактически не в корне лежит.
localhost/modx/ адрес главной C:\HOST\home\localhost\www\modx — папка
Может у вас сайт не в корне нового домена, а подпапкой того же locahost-а? Какой адрес главной страницы MODX-а?
Но весь этот механизм конечно же мне не видится еще оптимальным. Есть полно задач, когда он соответствует, но все-таки не все устраивает. Плюс тут в итоге вообще 3 запроса получается, а не два. Так что уже повод еще раз очень внимательно подумать. Еще и планирую добавить опцию, чтобы не выполнять подсчет при желании. Если мы просто получаем общие данные или типа того, когда нас не интересует общее кол-во записей, то и нет смысла в запросе на подсчет. В общем, все пока так, как есть, и долго еще так будет, но потом механизм будет доработан.
А если добавлять джоин таблицы в PrepareQueryBeforeCount(), то таблица будет и в конечном условии, а в getdata-процессоре она итак джоинится. github.com/Fi1osof/shopModx/blob/54322b2f9c095003223636b191ea058d939c50b4/core/components/shopmodx/processors/web/getdata.class.php#L35 Получится, что два раза таблица джоинится. Не комильфо будет.
Вот это очень хороший и важный вопрос! Правда ответ будет довольно объемным, но просто дело очень важное, и понимание этого будет в дальнейшем очень важным плюсом. Здесь корень тянется из самого принципа построения постраничности: для постраничности требуется знать сколько всего результатов есть, удовлетворяющих условию, и какой limit устанавливается. К примеру, всего записей 100, лимит 10 — итого у нас 10 страниц. К чему я это? К тому, что каждый раз при выполнении процессора на получение данных, выполняется два запроса. Первый считает общее кол-во записей, удовлетворяющих условию, а второй уже делает конечную выборку. Так вот, при разработке getlist-процессора для shopModx-а, этот момент учитывался, и было использовано клонирование объекта запроса. github.com/Fi1osof/shopModx/blob/02152b36f2143902a4fb2099378b54f1699b1e63/core/components/shopmodx/processors/web/getlist.class.php#L41 Для чего это было сделано? Дело в том. что при поиске могут быть использованы различные сложные условия, плюс джоины различных таблиц и прочее. При этом это может быть нужно только при первичном поиске записей. А при окончательной выборке данных (со всеми колонками), это может и не понадобиться. В итоге, если вопрос стоит именно в поиске по TV, но не надо будет специально подставлять значения этого TV в конечный вывод, то лучше всего это делать на уровне метода prepareCountQuery(). github.com/Fi1osof/shopModx/blob/02152b36f2143902a4fb2099378b54f1699b1e63/core/components/shopmodx/processors/web/getlist.class.php#L80 Переопределяем его, добавляем innerJoin() таблицы с условием и все. На выходе процессор выполнит поиск всех удовлетворяющих условию записей, и подставит их ID-шники в конечный запрос выборки. github.com/Fi1osof/shopModx/blob/02152b36f2143902a4fb2099378b54f1699b1e63/core/components/shopmodx/processors/web/getlist.class.php#L70 При этом в окончательном запросе джоина этой доптаблицы не будет, так как в ней нет необходимости, у нас уже есть ID-шники искомых записей.
В магазине требуется создать для товаров дополнительные параметры (цвет, размер). Насколько я понимаю, нужно создавать модель товара и сами товары как дочерние к ней. Как это все правильно организовать как на тех сайтах со слингами или дверями?
ht.access переименуйте в .htaccess Это дела самого MODX-а.
Скажите пож — почему неработают ЧПУ ссылки — редиректит на Денвера главную? Спасибо!