Как сделать каталог на modx
Структура каталогов MODX
В данной статье рассмотрена основная структура каталогов MODX Revo. Каталог MODX Revo разбит на подкаталоги, каждый из которых имеет свой набор обязанностей и задач. Часть этих каталогов можно переименовать и переместить, и их расположение может быть сконфигурировано во время установки.
После установки MODX, если вы зайдете в дерево каталогов, то увидите следующую структуру:
connectors/
Здесь содержаться точки входа для AJAX-запросов, которые в свою очередь не делают никаких манипуляций с базой данных; они просто загружают главный класс MODX, затем проверяют данные запроса, и обрабатывают запрос, указав на соответствующий файл процессора.
Дополнительные файлы
Является основой для всех библиотек MODX Revo. Практически все, что нужно, за исключением файлов менеджера и файлов установки, находятся в этом каталоге.
core/cache/ — содержит все кэш-файлы MODX. Лексикон, элементы, ресурсы, RSS каналы, и данные Smarty генерируются по требованию MODX, а это значит, они кэшируются только после первого доступа.
core/cache/logs/ — здесь Вы найдете файл error.log, который содержит дату, время, ошибки, которые были зарегистрированы в MODX. Чтобы произвести запись в данный файл, вы можете использовать метод $modx->log().
core/cache/mgr/ — этот каталог содержит данные кэша контекста. Он кэширует любые настройки контекста, которые были определены по умолчанию в параметрах системы.
core/cache/rss/ — кэш-память каждого RSS Feed в MODX.
core/cache/web/ — кэш MODX Revolution разделен на несколько частей. В каждом контексте есть файл context.cache.php. Этот файл, как файл config.cache.php, за исключением того, что он только кэширует настройки, которые были переопределены в настройках системы по умолчанию. Любой контекст можно переопределить в настройках системы. Кроме того, кэш веб контекста будет содержать отдельные каталоги для ресурсов и элементов. Ресурс с идентификатором 5 будет находиться на cache/web/resources/5.cache.php. Этот новый механизм кэширования означает, что время загрузки будет уменьшаться, а предел на число кэшируемых ресурсов исчезнет.
core/config/ — данный каталог содержит файл конфигурации для MODX Revo. Он устанавливает учетные данные базы данных и ряд MODX_ констант для правильной работы вашего сайта.
core/docs/ — данный каталог содержит файл changelog.txt, лицензию GPL, а также любые обучающие программы, которые были созданы для революции.
core/export/ — в MODX Revo после запуска функции экспорта, там будут располагаться экспортируемые HTML файлы Вашего сайта.
core/import/ — для выполнения функции импорта в MODX Revo, необходимо переместить HTML файлы в этот каталог.
Чтобы загрузить лексикон, можно использовать такой формат:
core/model/ — этот каталог включает модели ядра. В парадигме MVC (модель-представление-контроллер), которая гласит, что должно быть по крайней мере три части приложения. Model (модель), которая содержит структуру базы данных и хуки; View (вид), который является частью GUI приложения, которая не содержит никакой логики — только представления; и Connector (контроллеры), которые соединяют модели. Модель содержит все PHP классы, в том числе процессоры, которые обрабатывают определенные функции — такие, как сохранение фрагментов, удаление чанка и т.д.
core/model/modx/mysql/ — этот каталог содержит файлы классов и карты для каждого объекта xPDO. Карты это PHP массивы, содержащие структуру таблицы базы данных. Другие платформы баз данных, такие как PGSQL, MSSQL, и другие будут появляться здесь.
core/model/modx/processors/ — этот каталог содержит отдельные файлы процессоров, используемых в манипуляции данными. Они никогда не обращались напрямую, а вместо этого доступны через коннекторы. Это позволяет заблокировать их для предотвращения несанкционированного доступа.
core/packages/ — здесь вы найдете любые транспортные пакеты, загруженные через Управление пакетами, такие как Ace, TinyMCE и т.д. Основной пакет также находится здесь. Это способствует легкой установке и удалению, а также удаленного обновления установленных пакетов. При создании пакета (например, после проверки из SVN), транспорт пакет будет храниться здесь.
core/xpdo/ — MODX Revolution был разработан для использования OpenExpedio (xPDO), расширение к PDO. Он обеспечивает единый интерфейс для работы с базами данных, а также позволяет MODX поддерживать различные платформы баз данных, кроме MySQL. Этот каталог содержит все файлы классов, необходимых xPDO, что позволяет сделать все от кэширования запросов, до построения транспортных пакетов и вывода данных в качестве удобного объекта JSON.
Дополнительные файлы
• core/cache/config.cache.php — Это файл кэша для всех настроек системы в MODX. Их эквиваленты базы данных находятся в таблице _system_settings, и их эквиваленты xPDO modSystemSetting объекты.
• core/cache/sitePublishing.idx.php — этот файл отслеживает интервалы обновления кэша.
• core/cache/mgr/actions.cache.php — отображает все объекты modAction.
manager/
Менеджер бэкенд или админка MODX для создания ресурсов, управления пользователями, а также выполнение общих задач по обслуживанию сайта.
manager/assets/ — этот каталог содержит библиотеки ExtJS, а также реализацию пользовательских ModExt. ModExt расширяет оригинальную библиотеку ExtJS, чтобы сделать процесс разработки более удобным для пользователей.
manager/controllers/ — контроллеры это PHP файлы, привязанные к modActions. Они просто извлекают данные и возвращают их, также служат для визуализации и отображения в браузере. Всякий раз, когда вы загрузите страницу в менеджере, вы в сущности говорите MODX, чтобы он загрузил конкретный контроллер, который просто загружает Smarty шаблон и выводил в браузере любые необходимые JavaScript.
manager/templates/ — этот каталог содержит файлы-шаблоны для каждой страницы менеджера. Они не содержат PHP код, а используются для организации HTML.
Дополнительные файлы
setup/
_build/
Этот каталог присутствует только в версии MODx Revolution скачанной с GitHub. Он содержит упакованные MODX файлы, необходимые для установки MODX в базу данных.
Дополнительные файлы
• _build/transport.core.php — Этот файл должен быть выполнен после загрузки MODX Revo, и перед запуском программы установки. После завершения, вы должны заметить «ядро» внутри каталога core/packages/, который будет содержать все необходимые файлы для установки MODX Revolution.
assets/
Этот каталог не присутствует в MODX Revolution по умолчанию, но он является общим для размещения изображений, CSS, JavaScript и других файлов.
Добавление страниц и разделов
Сегодня мы начнем наполнять контентом наш сайт, а конкретно изучим документы modx revo. Заодно научимся редактировать сайт на MODX. Как уже ранее упоминалось в статье основные определения modx, документ в МОДХ — это конкретный тип ресурса, который может быть контейнером для четырех видов ресурсов: документов, web-ссылок, статических ресурсов и символических ссылок (в большинстве случаев это обычная веб-страница). Рассмотрим процесс создания и редактирования документов и разделов сайта.
Создание страниц и разделов сайта на MODx Revolution.
Для того чтобы создать страницу или раздел, необходимо дереве элементов на вкладке Ресурсы нажать на значек «Новый документ»:
Откроется страница для редактирования ресурса, которая имеет 3 вкладки: Документ, Настройки, Группы ресурсов. Рассмотрим каждую из вкладок.
Вкладка документ.
Здесь необходимо заполнить следующие поля:
Заголовок – данное поле обязательно для заполнения. Текст с этого поля обычно вставляют в тег title исходного кода страницы —
[[*pagetitle]]
Расширенный заголовок – необязательное поле, в котором можно прописать более длинный и информативный заголовок, который в последующем можно будет выводить при помощи тега на страницах сайта — [[*longtitle]].
Описание — необязательное поле, но очень рекомендую его заполнять, т.к. текст с этого поля вставляется в тег description (полезно для SEO) — [[*description]].
Аннотация — необязательное поле. Для страниц его заполнять не нужно, но если вы создаете новость, статью или товар, то заполнить просто необходимо — [[*introtext]].
Шаблон – здесь вам необходимо указать шаблон, который будет использован при формировании данной страницы.
Псевдоним — Это часть URLадреса страницы, при условии, что вы используете ЧПУ (Человеко-Понятные- URLадреса) и включили функцию Friendly URL смотрите статью настройка ЧПУ modx. Например созданный вами ресурс, допустим страница о компании с псевдонимом ‘about‘ и расширением ‘html‘ будет доступен по ссылке ‘http://my-site/about.html‘, в случае данный ресурс не является контейнером — [[*alias]].
Пункт меню — краткий заголовок ресурса в меню — [[*menutitle]].
Атрибуты ссылки – здесь вы можете добавлять атрибуты к ссылкам в меню, к примеру если добавить target=»_blank» то ссылка будет открываться в новом окне, rel=»nofollow» – то яндекс не будет учитывать данную страницу и т.п. думаю суть вы поняли — [[*link_attributes]].
Не показывать в меню – Если чек бокс на против данной опции, то данный ресурс не будет показываться в большинстве сниппетов меню и навигации — [[*hidemenu]].
Опубликован – Данный параметр определяет, будет ли показан данный ресурс посетителям сайта (если чек бокс не установлен, то данный ресурс сохраняется как черновик и не выводится на сайте) — [[*published]].
Содержимое ресурса – Здесь добавляется контент данного ресурса — [[*content]].
По сути если вы создаете обычную страницу сайта, то в остальные вкладки вам заходить не обязательно, просто пропишите заголовок, заполните содержимое ресурса, выберете используемый шаблон, поставьте галочку на против опубликован и сохраните документ, после чего можете посмотреть на сайте что у вас получилось.
После заполнения данной вкладки у вас должно получиться примерно так:
Вкладка Настройки.
Родительский ресурс – Здесь при необходимости вы можете указать ID родителя
Вкладки Тип ресурса и Местонахождение содержимого – в 99% случаях оставляете значение по умолчанию.
Позиция в меню – проставляется автоматом
Опубликован – после сохранения ресурса, здесь отображается дата публикации ресурса.
Дата публикации – при помощи данного пункта вы можете запланировать публикацию, к примеру, чтобы данная страница опубликовалась не сразу же, а к примеру через неделю.
Дата отмены публикации — при помощи данного пункта вы можете запланировать отмену публикации ресурса.
Контейнер – если вы поставите галочку на против данного пункта, то документ превратится в рубрику (категорию).
Доступен для поиска – разрешает или запрещает поиск в содержимом ресурса, так же может использоваться в сниппетах.
Использовать HTML-редактор – включает или отключает HTML-редактор
Заморозить URI – если отметите данный пункт, то появится дополнительное поле, к котором вы сможете прописать какой либо URL и он при любом редактировании будет оставаться неизменным.
Кэшируемый – если данный пункт отмечен, то ресурса будет сохранен к кэш после первого обращения к нему.
Очистить кэш – очищает кеш при сохранении ресурса.
Удалён – отменяет публикацию ресурса.
Вкладка Группы ресурсов.
Здесь вы можете выбрать, к каким группам принадлежит ресурс. К примеру вы не хотите чтобы данную страницу могли просматривать только зарегистрированные пользователи, тогда вам нужно будет создать 2 группы, для авторизованных и не авторизованных пользователей и указать на против данных групп параметр доступа.
Вот как то так) Идем далее.
Редактирование страниц сайта.
Для того, чтобы отредактировать ранее созданные страницы, нужно в дереве ресурсов найти необходимую страницу и кликнуть по ней левой клавишей мышки на либо вы можете кликнуть правой по данной странице правой кнопкой мыши и затем в контекстное меню выбрать «редактировать».
Удаление страниц сайта.
Удалить страницу можно также при помощи вышеупомянутого контекстного меню выбрав, пункт «Удалить», либо же при редактировании страницы вы можете нажать одноименную кнопку.
После этого в дереве ресурсов модх заголовок данного документа окрасится в другой цвет и станет перечеркнут. Но это, еще не окончательное удаление, а по большому счету просто отмена публикации.
Чтобы полностью удалить ненужный ресурс, то вам потребуется кликнуть по кнопке «Очистить корзину».
На сегодня все, создайте все основные страницы и категории, далее мы сделаем статическое меню динамическим при помощи PdoMenu.
Создание мультисайта на MODX REVO
Лучше поздно, чем никогда. Как и обещал https://modx.pro/help/5194/ пишу про создание мультисайта на MODX REVO. Выкладываю в блог Готовые решения, т.к. в статье есть чуть-чуть кода.
Смысл всей затеи — упростить поддержку сайтов.
Под поддержкой понимаются любые действия связанные с работой сайта:
— размещение контента
— технические доработки сайта (программирование, верстка)
— консультирование модераторов, сеошников и т.д.
— бэкапы и восстановление информации
Кроме того, для упрощения работы необходимо внедрить стандарты, чтобы упростить рутину. Звучит громко, но на самом деле все просто — по «узким» моментам единожды принимаем какое-то решение и дальше просто поступаем по образцу, чтобы не тратить время на изобретение велосипедов. По принятому решению пишем короткую заметку в Евернот, чтобы потом когда понадобится можно было быстро найти, на чем основывалось решение.
В таких «стандартах» у меня:
— ресайз картинок с примерами кода
— настройки галереи fancybox с примерами кода
— создание файловых архивов
— названия чанков, например почти везде у меня есть чанки HEADER.site1, FOOTER.site1, ASIDE.site1 (в названии используем название контекста).
— и т.д. и т.п.
Т.е. единожды продумываем тонкости и решаем, что будем делать именно так и никак иначе. В дальнейшем это позволит избежать бардака и существенно ускорит процесс переноса существующих сайтов в мультисайт или разработку новых сайтов.
Важный момент, на который нужно обратить внимание по каждому сайту:
Не навредить SEO! Поскольку «вылететь» из поисковой выдачи Яндекса и Гугла — это плохо. Один из сайтов «вылетел», пришлось в срочном порядке восстанавливать все адреса + дополнительно настраивать контекстную рекламу, поскольку у владельца сайта это был основной канал коммуникации с клиентами.
Про мультисайты на modx не так много статей, когда я все это задумал, мне казалось, что или все слишком очевидно или просто особо этим никто не занимается.
При поиске через гугль нашел это:
_http://www.wiseguydigital.com/blog/2010/how-to-build-multi-site-modx-installations
_http://modx.ws/blog/uroki-modx-revolution/multisajt-na-modx-revolution.html
_http://www.belafontecode.com/modx-revolution-hosting-multiple-domains/
— в статьях описано примерно одно и тоже.
1. Сайты на виртуальном сервере, все домены ссылаются в одну папку, таким образом прекрасно работает плагин от Василия Наумкина bezumkin.ru/sections/tips_and_tricks/2439/, который переадресует каждый домен на свой контекст.
upd. Переадресация идет, если имя домена совпадает с настройкой контекста http_host.
2. Соответственно для каждого домена сделан отдельный контекст. В настройках контекста прописаны обязательные настройки:
site_start – ID главной страницы сайта (этот параметр написан ввиде цифры в скобках в конце каждого документа в меню Resources)
base_url – установите этот параметр “/” (без кавычек)
http_host – укажите в этом параметре домен вашего дополнительного сайта “имя.ru” (если речь идет о домейне третьего уровня, то в этом параметре необходимо указать имя.имя.ru)
site_url – укажите в этом параметре полный адрес вашего дополнительного сайта “http://имя.ru/” (можете указать с www)
— без них работать не будет.
Плюс все нужные индивидуальные настройки для каждого домена, напрмер «страница 404», «статус сайта», «использовать вложенные url». И настройки почты. Я чаще всего использую ЯндексПочту для домена, все прекрасно работает. Для каждого домена задаем отдельные почтовые ящики.
3. По настройке htaccess с «www» и «без www» создал топик в разделе Работа modx.pro/work/5786-configure-htaccess-to-multisite/. Помог Василий Наумкин.
Те записи, которые есть в примере файла htaccess дистрибутива modx для доменов и с «www» и «без www» не работают, сайт пишет про циклическую ошибку (комент Ильи Уткина в вышеуказанном топике про работу).
Для сайтов «с www» нужно прописать отдельное правило для этого сайта. А там, где ниже идёт правило для редиректа всех www на без-www нужно добавить условие не редиректить тот сайт.
4. Сделал отдельный каталог со спецдиректориями по названию доменов для их индивидуальных файлов, изображений, шаблонов и т.д.
Путь от корня мультисайта индивидуально папки получился «s/site1/», «s/site2/» и т.д. для каждого сайта. В эти папки положил важные для SEO подпапки от каждого сайта, например:
«s/site1/assets/image»
«s/site1/assets/gallery»
«s/site1/assets/files»
«s/site1/assets/cashe»
Папки image, gallery, files и т.д. — из Modx Evo, там хранится проиндексированный поисковиками контент, но для того, чтобы этот контент открывался по прежнему адресу нужно из url убрать адрес спецдиректории для каждого домена, например «s/site1/».
5. Для того, чтобы вырезать из URL пути «s/site1/», «s/site2/» Василий Наумкин написал плагин и привел пример записи в htacess.
Он работает для всех контекстов и берёт список вырезаемых url из настройки контекст urlCut. Т.е. если надо вырезать кусок из url «s/site1/», то в настройках контекста добавляем запись «urlCut».
Затем нужно научить Apache2 загружать такие файлы из спецдиректории, прописываем в htaccess:
Соответственно для каждого домена нужно прописать похожее правило.
Мы сохранили прежние пути к проиндексированным в поисковых системах файлам, хотя физически она находятся в отдельных спецдиректориях. Таким образом не вредим SEO.
Для примера, картинка у нас физически находится по адресу:
site1.ru/s/site1/assets/image/image.jpg
Но открывается она по URL
site1.ru/assets/image/image.jpg
Т.е. после добавления сайта в мультисайт адреса изображений остались прежними.
По специфичным моментам настройки каждого отдельного домена в мультисайте вроде все.
Я создал один контекст для образца, со всеми индивидуальными настройками которые мне нужны для каждого домена и потом просто копировал его, чтобы каждый раз не прописывать отдельные настройки для каждого контекста. Кроме того в этом образцовом контексте созданы ресурсы 404, sitemap и т.д., они тоже копируются при копировании контекста — это удобно.
Для переноса, в мультисайте настраивается тестовый домен, контент существующего сайта переносился «вручную». После того, как все перенесли и убедились, что все ок, в настройках контекста меняли имя домена на нужное и только потом переадресовывали домен на папку мультисайта.
Настройка прав и админки для юзеров с урезанными правами — стандартная, никаких особенностей, связанных с мультисайтом там нет. Просто настраиваем нужный доступ к контексту и юзер открывает админку по адресу его сайта «site1/manager/» и в дереве ресурсов отображается только его контекст.
Для каждого отдельного контекста создана отдельная категория, соответственно все чанки, шаблоны, доп.поля, плагины складываем туда, чтобы «не в одну кучу». При необходимости, для удобства разработки, можно настроить отдельного юзера с доступом в эту категорию, чтобы другие категории не мешались. Я так не делал, поскольку во многих случаях просто копировал код с «соседнего» сайта, например чанк вывода новости со всеми прописанными полями (заголовок и длинный заголовок, ресайз картинок, альты и тайтлы к картинке, вывод дат и т.д.). Это и упрощает разработку и позволяет не забыть важные моменты, т.е. не надо каждый раз вспоминать «что же нужно прописать».
Для удобства, в названиях чанков, шаблонов, доп.полей и т.д. используем названия контекста, чтобы было понятно, к чему он относится. Выше я писал про HEADER.site1.
Настроил ежедневный бэкап сайта по крону. Но своим клиентам раз в две недели автоматически рассылаю письма, что «создан полный бэкап сайта».
Неочевидный для меня момент — настройка шаблона тикетов по умолчанию, сначала пробовал вставлять этот шаблон в настройках контекста, ничего не получилось. В итоге настройка нашлась непосредственно в разделе с тикетами.
Стандартные компоненты, сниппеты и плагины прекрасно работают в мультисайте.
Для настройки меню сайта от корня достаточно указать необходимый контекст [[pdoMenu? &context=`site1`]]
Выводы:
Вставлять в мультисайт какие-то сложные сайты (интернет-магазины и т.д.) наверно не стоит.
Но что-то проще:
— лендинги;
— сайты без какого-либо сложного функционала, например сайт организации с лентой новостей, каталогом товаров и услуг — можно и по временным затратам встроить в мультисайт проще чем создать отдельный новый сайт + сильно экономим время на обслуживании.
Новые сайты я однозначно буду запускать в мультисайте. Если вдруг их нужно быть вынести в отдельный сайт — это очень просто, копируем полностью сайт, удаляем оттуда ненужные контексты и папки категорий.
Разработка сильно упростилась, поскольку все лежит в одном месте и можно копировать код кусками с работающих сайтов.
Наверняка я что-то упустил, если есть какие-то вопросы, спрашивайте.