Looked modx не работает

looked

addData

Добавление дополнительных данных к ресурсу, товару и т.п.

msMiniCartDynamic

Динамическое обновление мини-корзины miniShop2

msChart

Добавляет графики для miniShop2

Регистрация просмотренных страниц сниппет addLooked

Регистрация просмотренных страниц.

• Все просмотры сохраняются в сессию.
• Возможность указать шаблоны

Параметры:

• &limit — Ограничение записи в сессию, по умолчанию 5
• &templates — ID шаблонов через запятую, где нужно учитывать просмотры. Если пусто — учитывать везде, при условии что сниппет [[addLooked]] вызывается в каждом шаблоне. Или разместите сниппет только в тех шаблонах, где нужен учёт. По умолчанию: пусто

Пример:

Вывод результатов, сниппет looked

Добавляет блок с просмотренными ресурсами. Looked является обёрткой для указанного сниппета в параметрах. Проверялось на msProducts и pdoResources.

• Исключение текущей страницы из выдачи
• По желанию может вернуть ID ресурсов

Параметры:

• &snippet — Какой сниппет использовать для вывода результатов. По умолчанию: msProducts
• &parents — По умолчанию: 0
• &limit — Ограничение вывода просмотров на странице. По умолчанию: 5
• &ids — Если «Да», сниппет вернёт ID просмотренных ресурсов. По умолчанию: Нет
• &tplOuter — Чанк-обёртка всего блока. По умолчанию: lookedOuterTpl
• &tpl — Чанк оформления каждого пункта. По умолчанию: lookedTpl
• &sortby — Любое поле ресурса для сортировки. По умолчанию: пусто
• &sortdir — Направление сортировки. По умолчанию: пусто

Так как сниппет не производит выборку, а просто выводит просмотренные товары, то &parents служит для переопределения этого параметра у используемого сниппета, где это — текущий ресурс, по умолчанию. Поэтому менять его значение не стоит.

Источник

[looked] Компонент «Вы смотрели»

Компонент looked для MODX revolution даёт возможность добавить на сайт блок с последними просмотренными страницами (товарами) пользователем.

Looked имеет два сниппета:

• addLooked — регистрация просмотров
• looked — вывод на экран результатов, если есть

Регистрация просмотренных страниц сниппет addLooked

Вывод результатов, сниппет looked

Добавляет блок с просмотренными ресурсами. Looked является обёрткой для указанного сниппета в параметрах. Проверялось на msProducts и pdoResources.

• Исключение текущей страницы из выдачи
• По желанию может вернуть ID ресурсов

Параметры:

• &snippet — Какой сниппет использовать для вывода результатов. По умолчанию: msProducts
• &parents — По умолчанию: 0
• &limit — Ограничение вывода просмотров на странице. По умолчанию: 5
• &ids — Если «Да», сниппет вернёт ID просмотренных ресурсов. По умолчанию: Нет
• &tplOuter — Чанк-обёртка всего блока. По умолчанию: lookedOuterTpl
• &tpl — Чанк оформления каждого пункта. По умолчанию: lookedTpl
• &sortby — Любое поле ресурса для сортировки. По умолчанию: пусто
• &sortdir — Направление сортировки. По умолчанию: пусто

Так как сниппет не производит выборку, а просто выводит просмотренные товары, то &parents служит для переопределения этого параметра у используемого сниппета, где это — текущий ресурс, по умолчанию. Поэтому менять его значение не стоит.

Примеры:
Заказывал клиент — делюсь с сообществом.

Компонент в modstore.
Посмотреть в работе можно здесь.

Источник

Решение проблемы «пустой админки» MODX Revo

При установке MODX Revolution у многих возникает проблема с тем, что при заходе в админку не загружается основное содержимое (правый блок).

Такое поведение — следствие работы работы модуля Suhosin и/или eAccelerator.

Под катом решения.

Проблема состоит в том, что по-умолчанию в админке MODX Revo используется кеширование JS и CSS файлов с помощью Minify. Одно из решений «в лоб», которое много где рекомендуют «если остальное не сработало», отключение кеширования. На всякий случай, расскажу как это делается:

Открываем файл /core/cache/system_settings/config.cache.php
строку ‘compress_js’ => ’1′, меняем на ’compress_js’ => ’0′,
строку ‘compress_css’ => ’1′, меняем на ’compress_css’ => ’0′,

затем, когда админка загрузиться, идём в Система->Настройки и в поиск вводим compress, будет выведено несколько пунктов, нам нужно у compress_js и compress_css установить значения Нет.

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

Рассмотрим более лучшие правильные решения.

Решение проблемы с Suhosin.

Чаще всего, решить проблему с Suhosin удается путём указания в php-конфиге suhosin.ini значение переменной suhosin.get.max_value_length равной 4096:
suhosin.get.max_value_length = 4096

Или, если настройки сервера позволяют, то прописать в /manager/.htaccess такую строчку:
php_value suhosin.get.max_value_length 4096

Хотя эта настройка и прописана в скрипте minify, но может и не сработать, если у вас запрещено менять такую настройку из PHP скрипта.

Если всё хорошо и кеширование заработало, то дальше можно не читать.

Решение проблемы с eAccelerator.

У меня на сервере работает связка apache+nginx+php с eAccelerator’ом. По неизвестной причине, кеширование скриптов срабатывало через раз. Опытным путём было выяснено, что проблема из-за eAccelerator’а. Гугление толковых советов не дало, отключать eAccelerator совсем не вариант, отключать кеширование скриптов тоже не вариант.

Решение простое.
Открываем файл /manager/min/index.php и в самый верх (после @ini_set(‘eaccelerator.enable’, 0);
тем самым отключив eAccelerator для этого скрипта.
Разумеется, чтобы это сработало, у вас должна работать возможность изменения настроек из PHP-скриптов.

Как вариант, если настройки сервера позволяют, можно прописать в файл /manager/min/.htaccess такую строчку:
php_value eaccelerator.enable 0

После проделанных манипуляций кеширование скриптов и стилей работает, админка работает шустрее!

Источник

Почему не работают дружественные URL в MODX?

Почему не работают дружественные URL в MODX?
Читал, пробовал не помогает Почему не работают дружественные url в ModX?
Пробовал на локалке и на хостинге с транслитерацией и без.
Путь по локалке /var/www/html/modx

Алерт не пропадает после переименовывания hta

• Вопрос задан более трёх лет назад
• 956 просмотров

Сам спросил, сам ответил. Сколько времени убил, но все-таки сделал! По уму не вышло, только методом тыка.
1) в .htaccess эти строки удалил
RewriteEngine On
RewriteBase /

2) в apache2 conf изменил на AllowOverride All для /var/www/

3) в виртуалхост добавил RewriteEngine On

Структура такая:

Источник

MODx Revo workflow. Организация рабочего процесса, контроль версий и деплой

Все основные элементы системы MODX, такие как чанки, шаблоны, сниппеты и т.д, хранятся в БД, из этого появляется проблема осуществления контроля версий за этими элементами, а также сложности с разделением на development и production версии сайта.

Приведу основные требования, чего я хочу от своего рабочего процесса на MODX Revo:

• контроль версий везде, где пишу какой-либо код (html, css, js, php),
• иметь отдельную dev-версию сайта, на которой ведётся текущая разработка, а после — деплоить все изменения в продакшн, причём, желательно, автоматизировать этот процесс,
• минимум копипаста при разработке и деплое.

Содержание

Введение

На момент написания этой статьи я имел опыт веб-разработки чуть более года. Мне повезло, я начал свой путь в этой сфере именно с MODX Revo, но несмотря на все плюсы этого фреймворка, со временем я начал сталкиваться и с минусами. Пока что я не работал в команде над большими сложными проектами и не знаю как обычно люди справляются с указанными выше сложностями. В интернетах я не нашёл какого-либо конкретного решения, и это поспособствовало созданию своего workflow, который я хочу представить в этой статье. Сразу оговорюсь, я не придумал ничего принципиально нового, а просто собрал разбросанные по интернету куски информации в одно руководство как устроить свой рабочий процесс при работе с MODX Revolution.

Что нам понадобится.
— Git
— npm + Gulp
Для работы я использую IDE PHPStorm.

Development и Production версии сайта

Первое что приходит на ум, когда думаешь как организовать рабочую (тестовую, dev) и релизную (боевой, prod) версии сайта, это просто иметь две его копии. Сначала ведём разработку на тестовом сайте, а после одобрения менеджером или клиентом, переносим всё на боевой. Просто и ясно, только вот этот процесс может превратиться в кошмар, т.к. всё делается вручную и существует немалая вероятность ошибки при переносе, потом придётся проверять, что ты не так сделал, а потом ещё окажется, что боевой сайт не вполне соответствует тестовому и нужно что-то ещё дополнительно править и т.д. и т.п. Нет, такого нам не надо.

Не буду долго рассуждать и скажу сразу, я предлагаю использовать один экземпляр сайта, в котором мы воспользуемся механизмом контекстов MODX Revo. Стандартный контекст web будет содержать релизную версию сайта. Плюс мы создадим ещё один контекст dev, работу с которым вынесем в поддомен. Таким образом, нам нужно:
— домен example.com, работающий в контексте web
— поддомен dev.example.com, работающий в контексте dev
При деплое мне нужно, чтобы изменения сделанные в контексте dev, каким бы то ни было образом сливались в web.

Создаём контекст dev

Эта часть работы начинается с того момента, когда у вас уже установлен движок и необходимые компоненты и настроены доменные имена, т.е. при обращении по обоим адресам example.com и dev.example.com открывается одна и та же стартовая страница MODX (корневая директория обоих доменов общая).

Теперь заходите в админ-панель → системные настройки → контексты и создайте новый контекст. Ключ укажите dev, имя — как угодно, я назвал Development. В контекстном меню слева у вас появится новый контекст. Первым делом создайте для него ресурс, а потом зайдите в настройки контекста (правой кнопкой по контексту → редактировать → настройки контекста) и задайте настройки
— site_start
— error_page
— unauthorized_page,
указав в них ID созданного ресурса. Это нужно, чтобы система не падала с ошибкой, если при работе в контексте dev не будет найдена какая-либо страница.

прим. Я создал контекст dev (Development) и переименовал стандартный контекст Website на Production, ключ стандартного контекста остался прежним — web.

Теперь в папке core/elements/common/plugins/ (создайте необходимые папки) создайте файл switchContext.php со следующим содержимым

Поясню, что делает плагин. При работе с сайтом через админку, т.е. в контексте mgr, ничего не делает. При работе с фронтальной частью сайта на домене dev.example.com переключает контекст на dev. При работе на фронт-енде на основном домене тоже ничего не делает. Но в случае, если исполнение скрипта каким-то образом попадает в default, то выводит ошибку в лог. Такое может случиться, например, при переносе сайта на новое доменное имя, и это сообщение призвано облегчить жизнь тому разработчику, который будет разбираться, почему после переноса ничего не работает. Когда я проверял описанную здесь схему работы на удалённом сервере, я как раз забыл исправить доменные имена в этом плагине и по ошибке в логе сразу понял что не так. В очередной раз сам себе сказал «Спасибо».

Обратите внимание, в самом конце файла плагина необходимо поставить оператор return, если плагин не должен ничего возвращать, это необходимо для того, чтобы переписать возвращающее значение оператора include, который мы используем при подключении файла плагина.

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

повесьте запуск плагина на событие OnHandleRequest.

Теперь у нас есть два контекста, как их использовать в дальнейшей разработке будет показано ниже.

Контроль версий

Создаём репозиторий проекта, например на GitHub, при этом в рабочем каталоге будут только файлы и папки, не относящиеся к движку. Примерно так

При этом, мы будем также контролировать файлы, получаемые в результате сборки (assets/web/ и core/elements/web/), чтобы иметь возможность откатиться после неудачного деплоя. Такая структура папок будет объяснена ниже.

Разработчики, как обычно, работают в своих локальных репозиториях и пушат коммиты в удалённый репозиторий. Кроме того, должен существовать репозиторий в корне сайта.
Пример файла .gitignore

Схема работы

Когда я выше говорил о Develpoment и Production версиях, я предложил использовать один экземпляр сайта. Это также предполагает отсутствие его локальной копии (не путать с локальным git-репозиторием проекта). Мы будем править файлы на локальной машине, но при этом в нашем локальном рабочем каталоге будут только файлы и папки, не относящиеся к движку. Мы будем вносить правки в имеющиеся файлы, затем делать upload этих файлов на сайт. После выполнения какой-либо задачи делаем коммит в локальном репозитории, после чего, если нужно, пушим изменения на GitHub, или где вы там собираетесь держать проект.

Теперь я расскажу, как я предлагаю устроить версионирование основных элементов системы — шаблонов, чанков, сниппетов и плагинов, и описать рабочий процесс через IDE PHPStorm в связке с панелью администрирования MODX. В этом нам поможет легендарный pdoTools и используемый им шаблонизатор Fenom.

Как известно, парсер pdoTools позволяет подключать внешние файлы прямо в теле чанка, и именно эта фича лежит в основе всего устройства контроля версий.

Необходимо выставить настройке pdotools_fenom_parser (Использовать Fenom на страницах) значение Да

Компонент pdoTools имеет системную настройку pdotools_elements_path со значением по умолчанию elements/. Что ж, соответственно, создаём папку elements/ (если ещё не создана) в папке core/ движка и внутри создаём следующую структуру папок:

Собственно разработка ведётся в папке dev/ при этом действует важное правило для всей команды: «Никто и никогда не должен проводить никакие правки в папке web/». При деплое всё содержимое папки dev/ копируется в web/ с помощью Gulp. Папка common/ содержит общие для обоих контекстов файлы, например, плагин переключающий текущий контекст, описанный выше.

Такая структура папок позволяет при подключении внешних файлов при помощи шаблонизатора Fenom использовать значение плейсхолдера [[*context_key]] примерно так

В первой строке мы складываем в переменную $ctx ключ текущего контекста (dev или web), а во второй строке используем это значение в пути к файлу. Это и позволяет иметь две версии сайта на одном движке.

прим. Подключения чанков в файле шаблона

Помимо файлов, содержащих основные элементы системы, нам также нужно вести контроль версий файлов вёрстки и js. Как правило, эти файлы расположены в папке assets/ следующим образом.

По старой схеме предлагаю создать следующую структуру

Работая с файлами вёрстки и скриптов следует учесть следующий момент. Например, в папке dev/js/ может лежать несколько файлов .js (к примеру, calendar.module.js и search-form.module.js), но при деплое в продакшн эти файлы следует объединить в один и минифицировать (например, main.bundle.min.js), так что в чанках нельзя просто взять и вписать в путь файла необходимое звено [[*context_key]], следует поступить примерно следующим образом и развернуть такую конструкцию

Связываем ресурсы с шаблонами

Шаблоны создаём в папке core/elements/dev/templates/, в которых подключаем чанки из папки core/elements/dev/chunks, используя синтаксис шаблонизатора Fenom. При этом, создавая файл шаблона, мы также должны создать соответствующий ему шаблон в админ-панели. Только мы не будем создавать статический шаблон, так как не можем указать конкретный путь к файлу, потому что он зависит от контекста, в котором шаблон используется. Вместо этого в теле шаблона мы пропишем одну единственную строку

Таким образом, этот шаблон послужит своеобразным переключателем файла шаблона для ресурсов в различных контекстах.

прим. Подключение файла шаблона

Создаём плагины

При таком подходе разработки следует отдельно оговорить внедрение в систему новых плагинов.
Аналогично ситуации с шаблонами, плагины создаём в папке core/elements/dev/plugins/, в которых пишем логику работы плагина. Далее, заходим в админ-панель и создаём соответствующий ему плагин (НЕ статический!), в котором подключаем файл плагина через include следующим образом

Не забываем, конечно, в админ-панели задать события, на которые вешается плагин. Если нам нужен плагин, общий для обоих контекстов, в переменную context складываем значение «common», как это было сделано в плагине switchContext.

Деплой

Вот мы и подошли к самому ответственному моменту. Выкатываем тестовую версию сайта на продакшн. Предварительно необходимо выполнить кое-какие действия с репозиторием на сервере, а именно создать SSH ключ, зарегистрировать его и прописать в настройках репозитория на GitHub. Описывать здесь этот процесс я не буду. Ссылка на иснтуркцию по генерации и регистрации ключа я оставлю внизу.
Итак, город засыпает, разработчики прекращают свою работу, все файлы закоммичены и запушены в удалённый репозиторий. Просыпается тимлид, его задача — максимально быстро выкатить всю произведённую работу в релиз. Предлагаю такой порядок действий.

1. На своей локальной машине нужно сделать синхронизацию файлов с удалённым репозиторием, чтобы убедиться, что в локальном репозитории все файлы в актуальном состоянии.
2. Создаём метку, например «v1.0.666-pre», обозначая таким образом коммит, предшествующий сборке версии v1.0.666, для быстрого и удобного отката в случае неудачного деплоя.

С помощью Gulp собираем новую версию проекта.

Приводу пример gulp файла. Здесь я описал лишь одну задачу для копирования файлов из core/elements/dev в core/elements/web/, остальные таски, наверняка, сможете написать и сами.

В результате сборки будут добавлены новые или изменены старые файлы в папках /assets/web/ и /core/elements/web/. Делаем коммит, назначем ему метку и делаем push с флагом —tags, чтобы отправить в удалённый репозиторий созданные метки.

Через SSH подключаемся к серверу и переходим в корневую директорию сайта, подтягиваем данные из удалённого репозитория и делаем hard reset, чтобы привести все файлы сайта к тому виду, в котором они хранятся в репозитории.

Смотрим результат в продакшене. Если я правильно представляю как устроен мир разработки и программирования, то примерно в 10 из десяти случаев что-то пойдёт не так. Поэтому переходим обратно в консоль, выполняем команду

т.е. переводим продакшн-файлы в состояние до сборки и начинаем разбираться что не так.

прим. Пример дерева коммитов.

Выше описанное относится к деплою шаблонов, чанков и сниппетов, а также файлов вёрстки, но что же у нас с ресурсами?

А что с ресурсами?

Рассмотрим такую задачу. На сайте есть раздел Новости, со временем количество публикаций стало очень большим и было принято решение создать новый раздел сайта Архив новостей.

В dev контексте вы создаёте соответствующий контейнер, добавляете пару экземпляров архивных новостей, создаёте чанки, если нужно шаблон и т.п. В результате на домене dev.example.com появляется новый раздел. После одобрения заказчиком, вы производите деплой, описанный выше, но нового раздела на продакшене, конечено, не появится, хотя все файлы будут приведены к необходимому виду. Конечно, это произойдёт, потому что созданный раздел (имеется в виду совокупность созданных ресурсов) будет находиться в контексте dev и не будет доступна в контексте web.
— И что делать?
— Копипаст, товарищи, увы.
А точнее перенос. Мы просто переносим созданный раздел в контекст web, а после повторно создаём его копию в dev, чтобы структура dev-версии сайта соответствовала продакшену.
Да, полностью избавиться от копипаста у меня не получилось.

Заключение

Таким образом, мне удалось организовать рабочий процесс, который бы устроил, в первую очередь, меня. В реальной работе эта схема ещё не применялась, поэтому подводных камней пока не обнаружено. Может быть более профессиональный взгляд читателей увидит существенные недостатки, поэтому прошу написать об этом в комментариях. И кстати, это моя первая статья, и я бы хотел узнать насколько доступно и ясно мне удалось изложить свои мысли, буду благодарен за конструктивную критику.

Источник