В админке все само подключается, а на фронтенде надо подключать перед.
Или можно запустить getService('rehab', 'Rehab', бла-бла-бла), как в сниппете — это тоже подключит модель + даст возможность пользоваться методами вашего класса.
$Rehab = $modx->getService('rehab','Rehab',MODX_CORE_PATH.'components/rehab/model/rehab/',$scriptProperties);
if (!($Rehab instanceof Rehab)) return '';
Лично я пишу для себя в классе свой runProcessor:
public function runProcessor($action = '', $data = array()) {
if (empty($action)) {return false;}
$response = $this->modx->runProcessor($action,$data,array('processors_path' => $this->config['processorsPath']));
if ($response->isError()) {
return $response->getAllErrors();
}
else {
return $response->response;
}
}
mFilter явно требует оптимизации, но пока на него нет времени. Хотя, выводом товаров заведует getResources и getPage.
Попробуйте упростить чанки с товарами, если есть условия — сократите их, насколько возможно.
Авторы MODX мне не рассказывали, почему они решили именно так, но копаясь во внутренностях их системы — я не представляю, как можно иначе.
Упертым баранам давайте ссылку на эту заметку — тут показано, как быстро работать с БД, без ненавистного ОРМ.
Кому кажется долгим сама инициализация ядра MODX — дорога в чистый php или еще куда подальше.
Того парня, как нашкодившего котенка, я носом тыкаю в эту заметку — он все равно делает вид, что ничего не видел.
А объяснение простое, и очевидное — без xPDO не было бы Revolution вообще. Был бы Evolution с обвесами, но не более.
Чем глубже разбираюсь в Revo — тем больше, простите, охуеваю от возможностей.
К примеру, сейчас мы пишем каменты к ресурсу класса не modResource, а Ticket. Среди прочего, отличается он еще и тем, что в любом случае при получении контента превращает теги MODX в html-сущности.
А при выводе контента у себя на странице — прогоняет его через Jevix, не только фильтруя, но и типографируя.
То есть, нефильтрованным контент этого ресурса можно получить только через прямой запрос в БД. Есть еще гора отличий в создании\изменении такого ресурса, и в админке.
Однако, я про них не думаю, ибо создал один раз этот новый класс ресурса — и дальше он работает по моим правилам, наследуя остальное от родителя modResource, а тот от xPDOSimpleObject, а потом xPDOObject… Ну вы поняли.
Как, ну как это сделать без ОРМ?! Короче, такой вопрос могут задавать только те люди, которые в Рево не ушли дальше использования стандартных сниппетов в Рево.
Как связаны обновление и перенос? Понимаете ли вы, что обновление с версии 1.3.3 до 1.9.4 — это много промежуточных версий, и не факт, что все нормально будет работать?
Если не страшно, просто поищите в менеджере пакетов по слову miniShop. Именно поищите в репозитории, а не кликайте «проверить обновления» — так не работает.
Потом будет в админке, но не знаю когда.
Или можно запустить getService('rehab', 'Rehab', бла-бла-бла), как в сниппете — это тоже подключит модель + даст возможность пользоваться методами вашего класса.
Лично я пишу для себя в классе свой runProcessor:
И потом вызываю именно его:
2. Смотрите в консоль браузера, наверняка там есть сообщения об ошибках.
mFilter явно требует оптимизации, но пока на него нет времени. Хотя, выводом товаров заведует getResources и getPage.
Попробуйте упростить чанки с товарами, если есть условия — сократите их, насколько возможно.
Создаете любой параметр и вызываете его потом через [[++paramname]] в чанках и шаблонах. А в сниппетах вот так:
Но мне проще удалить вопрос.
На windows image.JPG и image.jpg — одно и то же. А на GNU/linux — нет. Проверьте пути к «не найденным картинкам», чтобы регистр буковок совпадал.
2. Пока не понятно
3. Это вроде как баг новой версии, гляньте тут.
Позволил, только вместо редактирования вы мне начали объяснять — почему так получилось. А со второго раза у вас отлично вышло!
Ошибки когда появились, случайно не после переноса с какого-нибудь Денвера?
Упертым баранам давайте ссылку на эту заметку — тут показано, как быстро работать с БД, без ненавистного ОРМ.
Кому кажется долгим сама инициализация ядра MODX — дорога в чистый php или еще куда подальше.
А объяснение простое, и очевидное — без xPDO не было бы Revolution вообще. Был бы Evolution с обвесами, но не более.
Чем глубже разбираюсь в Revo — тем больше, простите, охуеваю от возможностей.
К примеру, сейчас мы пишем каменты к ресурсу класса не modResource, а Ticket. Среди прочего, отличается он еще и тем, что в любом случае при получении контента превращает теги MODX в html-сущности.
А при выводе контента у себя на странице — прогоняет его через Jevix, не только фильтруя, но и типографируя.
То есть, нефильтрованным контент этого ресурса можно получить только через прямой запрос в БД. Есть еще гора отличий в создании\изменении такого ресурса, и в админке.
Однако, я про них не думаю, ибо создал один раз этот новый класс ресурса — и дальше он работает по моим правилам, наследуя остальное от родителя modResource, а тот от xPDOSimpleObject, а потом xPDOObject… Ну вы поняли.
Как, ну как это сделать без ОРМ?! Короче, такой вопрос могут задавать только те люди, которые в Рево не ушли дальше использования стандартных сниппетов в Рево.
То есть, при поиске «Sony» найдутся все "%Sony%", а при поиске «магнитола Sony» — все "%магнитола Sony%" + все совпадения по формам слова «магнитола».
Поиск не идеален, конечно, но работает лучше других аналогов на Revolution, особенно с русским.
На другом языке будет поиск только по точному совпадению, без морфологии.
Если не страшно, просто поищите в менеджере пакетов по слову miniShop. Именно поищите в репозитории, а не кликайте «проверить обновления» — так не работает.