Modx что это – Разработка сайтов на MODX, система управления сайтами MODX, создание сайтов на MODX

Leave a Comment / Разное / By /

Содержание

Что мы знаем о MODX 3 на данный момент? / Habr

Несколько недель назад ведущий архитектор Джейсон Ковард (Jason Coward, «opengeek») поделился своим видением о будущем MODX на площадке Medium. Основываясь на этой информации, а также на других обсуждениях в сети, что мы знаем о MODX 3? Каков его статус, и когда мы можем увидеть что-то вживую?

Честно говоря, у нас пока нет точных ответов. Есть только некоторые части информации, которые мы можем сложить вместе. Поскольку MODX 3 еще попросту не создан, существует множество допущений и «продвинутых» предположений. MODX 3 – это долгосрочный проект, который только запускается.

Почему нам все равно нужен MODX 3?


Множество людей отлично пользуются текущей версией MODX. Система позволяет дизайнерам и фронтенд разработчикам создавать полностью уникальные сайты с минимальными усилиями и изменениями ядра в отличие от некоторых конкурентов. Даже в текущей версии разработка сайтов будет простым и полностью осуществимым делом в течение многих последующих лет. Очень мощный язык шаблонов и элементов, дополнительные поля (TV) и расширения – все это уже готово для использования в будущем.

Возможно, наибольшая причина, почему нам нужен MODX 3, – это просто число. С целью очищения унаследованного кода и предоставления разработчикам улучшенных средств, соответствующих стандартам отрасли, системе MODX будут нужны критические изменения. А поскольку MODX следует принципам семантического версионирования, это означает, что мажорная версия должна увеличиться в момент реализации критических изменений. Для MODX Revolution установлена версия №2, значит, нам будет нужна версия №3.

Так почему же нам нужны критические изменения, если текущая версия MODX все еще очень актуальна? Я бы сказал, это нужно для того, чтобы MODX следовал в потоке изменений мира PHP. Сообщество PHP становится более профессиональным и стандартизированным (в частности, благодаря The Framework Interoperability Group – группе концепции совместимости и инициативам вроде PHP: The Right Way – PHP: правильный путь) с впечатляющей скоростью в последние несколько лет. Включаясь в это движение, код ядра MODX может стать намного более классным (читай: стабильным, тестируемым и, возможно, меньше по объему). И наоборот, MODX стал бы намного более привлекательной платформой для других разработчиков на PHP.

В мире разработки критические изменения происходят постоянно. С исключительным прыжком от Evo к Revo MODX стал на самом деле стабильнее и продолжал развиваться в прошедшие года, но с определенных точек зрения критический релиз должен произойти, чтобы превзойти все то, что позволяет существующий код.

Синдром «это придумали не мы»


Во многих случаях MODX был разработан при использовании концепции «неприятия чужой разработки» (тенденция сознательно или инстинктивно игнорировать все инновации, которые происходят за пределами организации – прим. переводчика), являющейся не лучшим паттерном проектирования. В основном это означает, что если ранее каждая часть кода была разработана внутри сообщества MODX, то в будущем могут быть использованы более стандартизированные библиотеки, которые разработаны внешними сообществами. Благодаря Composer и Packagist, такое изменение произошло внутри сообщества PHP в последние годы, что позволило максимально просто использовать код внешних разработчиков, а также ускорило рост отдельных библиотек, выполняющих исключительно хорошо одну, четко определенную задачу.

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

Приведу некоторые примеры модулей, которые были разработаны внутри команды MODX ранее до использования внешних библиотек:

  • Журналирование. На данный момент существует удобный метод $modx->log(), однако при изменении данного метода в соответствии с поддержкой интерфейса PSR-3 разработчики смогут сбрасывать записи лога в различные системы журналирования, например, в такие, как Monolog. Система Monolog предоставляет огромное количество впечатляющих возможностей по управлению логами, и когда MODX начнет поддерживать PSR-3, можно будет поддерживать любые из них без изменения ядра MODX.
  • Маршрутизация. Существуют библиотеки, которые могут делать довольно крутые штуки с трансформированием запроса в правильный ответ. Смотрите раздел о фреймворке Slim ниже.
  • Система шаблонов. Честно говоря, мне действительно нравится язык шаблонов в Revolution, но, возможно, использование чего-то более «стандартного» наподобие Twig могло быть интересным улучшением. В любом случае это снизит кривую обучения для многих людей, поскольку Twig используется во многих других проектах.

Это только самые первые вещи, которые приходят на ум, когда мы говорим о повторном использовании готового внешнего кода.

Что такое Slim и зачем его использовать?


Во второй части серии своих статей «Поддерживая MODX в актуальном состоянии», Джейсон отметил фреймворк Slim (версия 3) как наиболее вероятного кандидата для использования в ядре MODX. Это не прошло незамеченным – многие люди начали рассматривать Slim, выясняя, что это такое и как он работает.

Вот что нам нужно знать о Slim:

  • Slim – это маршрутизатор. Он трансформирует Запросы (например, GET /manager/resource/update) в Ответ (например, в форму для обновления ресурса).
  • Slim поддерживает паттерн Middleware (промежуточное программное обеспечение). При использовании данного паттерна вы по существу получаете множество слоев, которые обрабатывают каждый отдельный запрос, а также ответы с возможностью менять их до того, как они достигнут следующего слоя. Техническое объяснение паттерна Middleware можно найти здесь. Паттерн Middleware – это очень эффективный путь для расширения поведения. Slim 3 фактически поддерживает стандарт PSR-7 (черновик) из PHP FIG в его реализации Middleware, что означает, что любой middleware-код с поддержкой паттерна PSR-7 может быть спокойно использован вместе с Slim 3.
  • Slim 3 пока еще находится в разработке; иными словами, он еще не готов для работы в реальном производстве, но похоже, код Slim 3 становится стабильным.

Предположительно, Slim займет место текущих обработчиков запросов и ответов в MODX. Учитывая возможность добавления middleware-кода, это привело бы к крайне гибкой и мощной системе.

Что насчет Менеджера и ExtJS?


Если вы спросите случайную группу MODX-разработчиков об их самой нелюбимой части системы, скорее всего, это будет ExtJS (или в более общей форме – «Менеджер»). На данный момент пока не существует определенного направления для Менеджера, о котором я бы знал, но привязка к ExtJS 3.4 – это явно не то, что должно произойти. ExtJS 3 очень устарел, он недостаточно быстрый и не обеспечивает должной поддержки мобильных устройств. Более того, ExtJS 3.4 больше не обновляется, поскольку ExtJS 6 уже доступен в раннем доступе.

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

Но что же мы знаем?

Учитывая выбор Джейсона в виде Slim как библиотеки ядра, его работы над неким проектом Tacit («высокопроизводительным RESTful фреймворком», основанном на Slim), а также некоторые обсуждения в различных IRC каналах и Slack, наиболее похоже, что следующий Менеджер получит RESTful API в качестве своей основы. Текущий Менеджер также обладает API, но его структура не полностью стандартизирована, а местами направлена именно на то, что от него ожидает ExtJS. Определенно, это не RESTful.

При переходе на RESTful API в качестве основной службы бекенд и интерфейс будут дополнительно разделены с точки зрения кода. Это должно позволить проще разрабатывать по-настоящему уникальные Менеджеры, причем делать эти две части платформы независимо друг от друга. Дизайнеры могли бы сфокусироваться на разработке интерфейса Менеджера третьей версии, а разработчики тем временем работали бы над надежным API.

Что дальше?


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

На данный момент основной фокус MODX – это версия 2.3 и приближающаяся версия 2.4. Выпуск MODX 3 обещает стать захватывающим и привлекательным, так что важно потратить некоторое время для выработки решений перед определением основ новой революции в MODX.

MODX CMS, система управления содержимым, CMS системы, управление сайтом

MODX (читается «мо́дэкс») — это бесплатная профессиональная система управления содержимым (CMS) и фреймворк для веб-приложений, предназначенная для обеспечения и организации совместного процесса создания, редактирования и управления контентом (то есть содержимым) сайтов.

MODX распространяется бесплатно по лицензии GPL с открытым исходным программным кодом (Open Source). Это означает, что систему MODX может использовать каждый: как для личного использования, так и для коммерческого распространения сайтов, построенных на данной системе управления.

MODX написана на программном языке PHP и использует для хранения данных СУБД MySQL или MS SQL. Система управления MODX может быть установлена на большинстве веб-серверов (например, таких как IIS, Apache, Lighttpd, nginx и Zeus), а контрольная панель системы (или админ-зона) работает практически во всех современных браузерах.

Версия MODX

MODX Revolution

скачать Modx Revolution

На текущий момент это новейшая версия системы управления сайтами MODX, которая активно развивается и поддерживается командой разработки.

Если вы не уверены, какую версию MODX использовать, рекомендуем выбрать MODX Revolution.

MODX Evolution

скачать Modx Evolution

На сегодня MODX Evolution используется параллельно с Revolution. Вероятно, для начинающих разработчиков начало работы с Evolution может показаться проще.

Некоторое время назад разработчики заявили об остановке работы над проектом Evolution, чтобы сконцентрироваться только на Revolution. Тем не менее впоследствии разработка Evolution перешла в руки сообщества и продолжила свое активное развитие. При выборе MODX Evolution для новых проектов желательно учитывать, что в целом функциональные возможности Revo выше Evo.

«Джентльменский набор»

Несмотря на то, что MODX может работать почти на какой-угодно операционной системе, возможно, будет полезно учесть следующие рекомендации при установке и работе с MODX:

  • надежный хостинг без особой перегрузки серверов
  • ОС Linux
  • Apache 2.2 с включенным mod_rewrite
  • PHP 5.3 или выше с включенным PDO
  • MySQL 5.1 или выше

Краткая история MODX

Разработчики Реймонд Ирвинг (Raymond Irving) и Райан Треш (Ryan Thrash) начали работу над проектом MODX CMS в 2004 году как модуль DocVars для системы управления сайтами Etomite и дополнением Реймонда для веб-пользователей.

В марте 2005 года все ссылки на MODX были удалены из форумов Etomite одновременно с требованием основателя Etomite прекратить поддержку MODX в них. С этого момента MODX становится форком Etomite.

К маю 2005 года форумы MODX были запущены онлайн и Джейсон Ковард (Jason Coward) присоединился к команде руководства проектом.

В 2007 году Реймонд покинул проект на дружественных условиях. В следующем году Шон МакКормик (Shaun McCormick) присоединился к команде руководства проектом.

В 2008 году пользователи MODX создали новый логотип и новый дизайн для проекта MODX CMS.

В 2010 году была выпущена первая версия MODX Revolution, которая являлась полностью переписанной версией MODX.

10 SEO нюансов для MODX (весна 2018)

Здравствуй родное сообщество. Я наконец вылезла из адового загруза работой, почти вышла из жуткой депрессии и снова решила поделиться парой своих наблюдений по части технической поисковой оптимизации сайтов. Конечно, на примере REVO.

Последние годы я активно сотрудничаю со многими SEO – фирмами и частными продвиженцами. Каждый раз, когда к ним попадает кто-то из наших «детей» — они традиционно присылают мне списки работ. Включив логику и свою собственную любовь к поисковой оптимизации, я решила поделиться с миром «тайнами», ну или просто общими требованиями к сайтам весны 2018 года.

1. Description

А знали ли вы, что относительно недавно количество символов в описании сайта выросло до 255? Так вот, для наших REVO (пардон, эвисты) в свежих версиях уже не нужно прыгать по файлам и базе, чтобы увеличить лимит. На самой свежей версии 2.6.3 можно смело писать больше текста в этом поле. У Вас версия старше? А почему не обновляетесь 😉

2. Keyword

Вот самое забавное, что есть сеошники, которые доказывают, что это поле себя отжило и не имеет место быть. Ха! Крупнейшие SEO-компании Беларуси, присылая мне ТЗ, четко пишут, что это поле им нужно. Вывод – это как лыжи, вроде пылятся на балконе, но, наверное, все таки нужны.

3. Заголовки

На странице должен быть один h2 и он должен быть в 100% случаев. Ну, это знают все (надеюсь, что все). Но. Есть еще и иные заголовки. Так вот, h3 и h4 имеет место быть только в тексте (наше поле content) и на важных фразах. Нельзя оформлять заголовками служебные фразы, используемые как элементы шаблона или навигации.

Например: у нас есть footer и в нем структура из 4 блоков. В каждом что-то есть: контакты, ссылки на разделы, логотип, соц. Сети и пр. Так вот, часто сие место подписывается

<h3>Связаться с нами</h3>
или
<h4>Оставить отзыв</h4>
И так делать нельзя. Самое забавное, что верстальщики именно так и возвращают макеты. Что делать? Заменить на
<div>Отзыв от Иннокентия</div>
или
<p>Советуем прочитать</p>
Возможно придется влезть в css. Или «промыть голову верстальщику» (иногда помогает).

Заметила я, что крайне редко встречаются в тексте и h5. А вот пятого и шестого заголовка на сайтах, которые в работе у оптимизаторов, просто нигде нет – все через стили.

4. Last Modified

Вывод информации о том, когда был изменен документ важен. Но тут проще простого, решение уже есть и дал нам его наш Илья — modx.com/extras/package/modlastmodified.

5. Rel canonical

Не забываем про канонический адрес страницы. Но, незабываем и про то, что у нас будет два канонический адреса, если мы вызовем pdoPage без ‘setMeta’ => 0. Причем второй будет, откровенно говоря, не комильфо.

6. Noindex и nofollow


Часто наш брат не заморачивается над этим метатегом и везде в чанк head пишет
<meta name="robots" content="index, follow">
Но тут мы забываем про основную суть данным фраз. Напомню, что значение no / follow – это управление запретом индексации ссылок на странице, а no / index – управление индексацией текста на странице.

Так вот, управление страницами пагинации должно быть следующее noindex и follow (не индексировать текст, но учитывать вес ссылок). У меня для этого есть миниатюрный сниппет, который я так и обозвала index _follow (вызывать в head для основных страниц сайта).

$robots = '<meta name="robots" content="index, follow">';
$norobots = '<meta name="robots" content="noindex,follow">';

$meta = $robots;
$request_uri = $_SERVER['REQUEST_URI'];
if(!empty($_GET['page'])) $meta = $norobots;
if(!empty($_GET['sort'])) $meta = $norobots;
return $meta;

Для служебных страниц свой шаблон обычно (это мы про простые сайты, без личного кабинета и прочего) и там можно уже руками прописать и этот мета тег, и иные.

7. Микроразметка и Open Graph Protocol

Да-да, очень-очень важна именно она. И для страницы товара/услуги, и для контактов, и для статей, и для хлебных крошек. Обычно нам лень лезть и смотреть ее параметры, но все таки она важна для ПС. Для ленивых вот copy / past.
{'pdoCrumbs' | snippet : [
    'limit' => 5,
    'tpl' => '@INLINE <li itemscope="" itemprop="itemListElement" itemtype="http://schema.org/ListItem">
    <a title="{$menutitle}" itemprop="item" href="{$link}">{$menutitle}</a>
    <meta itemprop="name" content="{$menutitle}"> <meta itemprop="position" content="{$idx}"></li>',
    'tplHome' => '@INLINE <li itemscope="" itemprop="itemListElement" itemtype="http://schema.org/ListItem">
    <a title="{$menutitle}" itemprop="item" href="{$link}">
    Главная</a>
    <meta itemprop="name" content="{$menutitle}"> <meta itemprop="position" content="{$idx}">
	</li>',
    'tplCurrent' => '@INLINE 
         <li itemscope="" itemprop="itemListElement" itemtype="http://schema.org/ListItem">
        <span itemprop="name">{$menutitle}</span>
        <meta itemprop="position" content="{$idx}">
        </li>',
    'tplWrapper' => '@INLINE <ul itemscope="" itemtype="http://schema.org/BreadcrumbList">
	 {$output}</ul>',
    'showHome' => 1,
    'showAtHome' => 0  
    ]}

Ну, или так, если понятнее будет:

[[pdoCrumbs?
    &limit=`5`
    &tpl= `@INLINE <li itemscope="" itemprop="itemListElement" itemtype="http://schema.org/ListItem">
    <a title="{$menutitle}" itemprop="item" href="{$link}">{$menutitle}</a>
    <meta itemprop="name" content="{$menutitle}"> <meta itemprop="position" content="{$idx}"></li>`
    &tplHome=`@INLINE <li  itemscope="" itemprop="itemListElement" itemtype="http://schema.org/ListItem">
    <a title="{$menutitle}" itemprop="item" href="{$link}">
    Главная</a>
    <meta itemprop="name" content="{$menutitle}"> <meta itemprop="position" content="{$idx}">
	</li>`
    &tplCurrent=`@INLINE 
         <li itemscope="" itemprop="itemListElement" itemtype="http://schema.org/ListItem">
        <span itemprop="name">{$menutitle}</span>
        <meta itemprop="position" content="{$idx}">
        </li>`
    &tplWrapper=`@INLINE <ul itemscope="" itemtype="http://schema.org/BreadcrumbList">
	 {$output}</ul>`
    &showHome=`1`
    &showAtHome=`0`  
    ]]

Примера Open Graph Protocol не привожу, но тут точно сами нагуглите, как его делать 🙂

8. Title у ссылок


Ну, alt тоже безумно важен у картинок, но я верю, что вы про него помните всегда. А вот у нашего любимого pdotools в пагинации есть «небольшой грешок» по этой теме и, если забыть, можно пропустить на сайт ссылки без этого важного аттрибута. Можно прописать сразу в вызове шаблоны, а можно в настройках сниппета, как удобнее. Но обратите внимание на tplPage, tplPageActive, tplPagePrev и tplPageNext.

Если используете pdoNeighbors, у него также в tplNext, tplPrev и tplUp нет описаний у ссылки. Да даже у pdoMenu, увы, tpl без него. В общем – тут будьте внимательны.

9. Цикличные ссылки

Попадая на сайт, большинство пользователей знают, что, кликнув на логотип, они смогут перейти на начальную страницу сайта. Так как кликабельный логотип уже давно стал стандартом. Но единственная ошибка – это то, что на главной странице логотип также кликабелен, то есть мы получаем цикличную ссылку, страница ссылается сама на себя. Лечение просто:
{if $_modx->resource.id != 1}
      <a href="{$_modx->makeUrl(1)}" title="Перейти на главную страницу" >
     <img src="/templates/img/logo.png" alt="{$_modx->config.site_name}, перейти на главную"></a>
     {else}
     <img src="/templates/img/logo.png" alt="{$_modx->config.site_name}, перейти на главную">
     {/if}

Или так:

[[*id:is=`1`:then=`
      <img src="/templates/img/logo.png" alt="[[++site_name]], перейти на главную">
 `:else=`
  <a href="[[~1]]" title="Перейти на главную страницу">
     <img src="/templates/img/logo.png" alt="[[++site_name]], перейти на главную">
     </a>
 `]]

10. Страницы ошибок

При попадании на такую страницу, важно не потерять пользователя. Дать понятное описание произошедшей ошибке и предоставить возможность перейти в популярный раздел или вернуться на главную страницу. 404-я и 403-я должны быть. Должны быть четкими, лаконичными и без лишней «мути» в виде хлебных крошек, больших картинок сверху, когда не виден текст ошибки и ссылки на уход с нее.

Бонус: две «плюшки» для MODX REVO

И на последок два Лайфхака, от которых я просто «тащусь» последние месяцы. Первое – это системные настройки для пользователя.

Не секрет, что вызов системной настройки быстрее, чем вызов дополнительного поля у страницы. И, если нам нужно засунуть куда-то данные телефонов, адресов и фраз из «подвала» или «шапки», то самым «шустрым» решением будет их размещение в системных настройках.

Но! Нам же нельзя туда пускать руко…х менеджеров. Что делаем?

  1. Ставим классный компонент settingsWidget с modstore.pro (https://modstore.pro/packages/utilities/settingswidget) от пока лично не знакомого мне DocentBF. Пишем в него наши, созданные ранее настройки. У автора описана инструкция, там легко разберетесь.
  2. Идем в управление панелями и создаем новую панель. Старую затрет при обновлении MODX, поверьте. В нее создаем и добавляем данный виджет. Именуем по своему. Назначаем виджет политике менеджера. Но! Не запрещаем в политике доступ к системным настройкам, иначе он их не увидит.
  3. Настройки прячем иным способом. Идем в настройки меню и из верхнего меню вкладку «Админ» отправляем в управление. Так она скроется с глаз, но не скроется с панели. Свою рабочую политику менеджера прикладываю в ссылке. Но сделайте это в конце работы. Вас выбесит, когда меню будет переломанным. Реально выбесит.




Лайфхак два. Открываем любой шаблон, например Главная. В поле Значок (после Имя и Описания) пишем icon-home. Сохраняем, обновляем. Открываем вкладку Ресурсы. Прикольно, да? 🙂 А это из бутсрапа, просто название иконок. Балуйтесь.

На этом пока все. Может будет вторая часть, но позже. У меня снова два ТЗ на рабочем окне, плюс еще надо оправиться после сложного периода депрессии. Так что пару месяцев я тут вряд ли снова вдохновенно накатаю статейку. Но я по прежнему люблю вас, сообщество MODX и EVO CMS.

Быстрый старт в MODX Revolution / Habr

Revolution дорос уже до версии 2.0.8, но большинство разработчиков не спешит его использовать, так как документация еще не полная, да и статей на русском очень мало.
Лично я не нашел ни одной пошаговой инструкции «для чайников», и поэтому решил написать ее сам.

Конечно, это топик для не «совсем чайников», а для людей, которые хоть немного знакомы с Evolution и при переходе на Revolution обломались от всего непривычного, как я. Никаких секретов и ловких методик тут не будет. Обычный how-to с картинками (их довольно много).

Установка

Лично я для нового сайта создаю новый аккаунт на %Мойлюбимыйхостер%. У него есть по умолчанию доступ в ssh, чем я и пользуюсь.
Итак, заходим на сервер, в директорию сайта (public_html или как-то так) и в консоли набираем
wget modx.com/download/direct/modx-2.0.8-pl.zip
unzip ./modx-2.0.8-pl.zip
mv ./modx-2.0.8-pl/* ./
rm -rf ./modx-2.0.8-pl
mv ./ht.access ./.htaccess

Так мы качаем последний на сегодня релиз Revolution, распаковываем его и перемещаем сразу в корень сайта.
Также нужно активировать htaccess для использования дружественных url.
Если вам проще это проделать через панель управления хостера — на здоровье.

MODX распакован, нужно создать ему БД. Это делается из админки хостера. Создаем еще пользователя и назначаем ему полные права на базу и пароль покруче. У %Мойлюбимыйхостер% это все делается в 6 кликов мышью.
Правда, я потом еще залезаю через phpmyadmin и вручную ставлю тип БД в utf-8, так как по умолчанию там cp1251. utf-8 очень хорошая штука, настоятельно рекомендую использовать ее.

Теперь можно устанавливать MODX. Заходим по адресу %sitename%/setup (да-да, не /install!)
Если у вас PHP 5.3 и вылезает ошибка 503, то скорее всего вам нужно прописать в .htaccess свой часовой пояс, например:
php_value date.timezone "Asia/Novosibirsk"

Кликаем по кнопочкам.

Вводим данные для подключения к БД

Проверка окружения

Установка окончена + удаление файлов установки в целях безопасности

Можно входить в панель управления с заданным ранее логином и паролем.

Поздравляю, MODX установлен!

Установка пакетов

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

Заходим в меню Система->управление пакета

Обязательно ставим:
Wayfinder — генерация меню.
getResources — замена Ditto, работа с ресурсами.
CodeMirror — редактор с подсветкой синтаксиса.

Еще очень рекомендую поставить
TinyMCE — WYSIWYG редактор для самых маленьких. Пригодится, если вы плохо помните html.
phpThumbOf — ресайз картинок при выводе на экран. Работает как фильтр PHx.
Breadcrumbs — цепочка меню, для вывода навигации типа «Главная->раздел->подраздел».
translit — автоматическая транслитерация псевдонимов ресурсов для дружественных url.

Вот еще таблица соответствия сниппетов Evo и Revo.

Обратите внимания, что после загрузки пакетов их нужно еще и установить.

А после установки, желательно еще поставить обновления на пакеты, если есть.

Настройка рабочего пространства

Тыкаем Система->Настройка системы

Настройка системы довольно таки отличается от Evo внешним видом, но суть — та же. Находим нужный параметр и меняем.
Есть фильтр по категорям + поиск по имени. Также, отдельно настраиваются движок (core) и сниппеты.

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

Нам нужно задать имя сайта и дружественные url.

Для того, чтобы автоматом генерировался псевдоним дружественного url в зависимости от pagetitle, мы уже поставили пакет translit — аналог transalias из Evo. Теперь настройте у себя все как показано на скриншоте.

Сходным образом меняются и все остальные настройки.

Почти все

В принципе, типовая установка и настройка закончена. Можно создавать ресурсы, рисовать шаблоны и радовать домочадцев довольным урчанием. Revolution оказался не так уж и страшен.

В заключение, несколько моментов:

Разница в тегах

Табличка соответствия тэгов Evo и Revo

Теперь все тэги заключаются в скобки [[]]:
[[*templatevar]]
[[$chunk]]
[[snippet]]
[[+placeholder]]
[[~link]]
[[++system_setting]]

Кэшируются и чанки и сниппеты, и даже, наверное, плейсхолдеры. Чтобы вызвать их без кэша — добавляем как раньше восклицательный знак.
[[!$chunk]]
[[!snippet]]

Встроенный PHx

Свершилось то, о чем все знающие мечтали! Теперь PHx встроен в ядро и его можно использовать везде!
Для тех, кто не в курсе, что это — викиучебник. Он написан для Evolution, но в целом — все то же.

Отличия от Evo:
Вызывается на любой плейсхолдер или параметр вот так:
[[*templatevar:filter=``]]
[[+placeholder:filter=``]]

Фильтром может выступать ЛЮБОЙ сниппет, который принимает параметры $output и $options и выдает результат с помощью echo.

Простейший пример использования:
[[*longtitle:is=``:then=`Расширенный заголовок отсутствует`:else=`Заголовок: [[*longtitle]]`]]

Обработка TVs

При создании TV можно указать тип вывода.

Пример:
Создаете TV с именем img, указываете для него тип вывода image, заполняете дефолтные параметры и при выводе на страницу как [[*img]] у вас и будет выводиться картинка! То есть прям с тэгами img title и т.д., что указали. А если выставить тип вывода текст — выведется только путь к изображению, как раньше.
Эту фишку, кстати, понимает и getResources.

Сниппет getResources

Этот сниппет — основной инструмент для работы с ресурсами. Он пришел на смену Ditto2 (Ditto3 для Revo тоже есть, но он бета, и обновляться больше не будет).

Сниппет имеет несколько отличий от Ditto.
1. Он не включает по умолчанию обработку TV. Нужно &includeTVs=`1`, чтобы сразу обрабатывать TVs нужно &processTVs=`1`
2. Не включает по умолчанию вывод контента! Юзать &includeContent=`1`.
3. Лимит на вывод ресурсов по умолчанию — 5. Я сначала тупил, почему выводит всего 5 документов из любого контейнера, так как Ditto выводил все.
4. Нет дефолтного шаблона, если вызываете getResources без &tpl=«, он выведет список ресурсов со всеми свойствами в виде массива — очень удобно, кстати.
5. Параметра startID нет, есть parents, работает как тот же параметр у Ditto.

Дерево ресурсов

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

Вообще, если привыкнуть к новому дереву ресурсов, возвращаться в Evolution просто не хочется. Очень удобно, очень.
Заключение

Надеюсь, эта статья хоть немного поможет вам в освоении MODX Revolution. Буду рад отвечать на вопросы в комментариях и обновлять топик, по мере надобности.
Основную информацию по Revolution можно найти тут (англ.).

Что мы знаем о MODX 3 на данный момент? (перевод)

Несколько недель назад ведущий архитектор Джейсон Ковард (Jason Coward, «opengeek») поделился своим видением о будущем MODX на площадке Medium. Основываясь на этой информации, а также на других обсуждениях в сети, что мы знаем о MODX 3? Каков его статус, и когда мы можем увидеть что-то вживую?

Честно говоря, у нас пока нет точных ответов. Есть только некоторые части информации, которые мы можем сложить вместе. Поскольку MODX 3 еще попросту не создан, существует множество допущений и «продвинутых» предположений. MODX 3 – это долгосрочный проект, который только запускается.

Почему нам все равно нужен MODX 3?

Множество людей отлично пользуются текущей версией MODX. Система позволяет дизайнерам и фронтенд разработчикам создавать полностью уникальные сайты с минимальными усилиями и изменениями ядра в отличие от некоторых конкурентов. Даже в текущей версии разработка сайтов будет простым и полностью осуществимым делом в течение многих последующих лет. Очень мощный язык шаблонов и элементов, дополнительные поля (TV) и расширения – все это уже готово для использования в будущем.

Возможно, наибольшая причина, почему нам нужен MODX 3, – это просто число. С целью очищения унаследованного кода и предоставления разработчикам улучшенных средств, соответствующих стандартам отрасли, системе MODX будут нужны критические изменения. А поскольку MODX следует принципам семантического версионирования, это означает, что мажорная версия должна увеличиться в момент реализации критических изменений. Для MODX Revolution установлена версия №2, значит, нам будет нужна версия №3.

Так почему же нам нужны критические изменения, если текущая версия MODX все еще очень актуальна? Я бы сказал, это нужно для того, чтобы MODX следовал в потоке изменений мира PHP. Сообщество PHP становится более профессиональным и стандартизированным (в частности, благодаря The Framework Interoperability Group – группе концепции совместимости и инициативам вроде PHP: The Right Way – PHP: правильный путь) с впечатляющей скоростью в последние несколько лет. Включаясь в это движение, код ядра MODX может стать намного более классным (читай: стабильным, тестируемым и, возможно, меньше по объему). И наоборот, MODX стал бы намного более привлекательной платформой для других разработчиков на PHP.

В мире разработки критические изменения происходят постоянно. С исключительным прыжком от Evo к Revo MODX стал на самом деле стабильнее и продолжал развиваться в прошедшие года, но с определенных точек зрения критический релиз должен произойти, чтобы превзойти все то, что позволяет существующий код.

Синдром «это придумали не мы»

Во многих случаях MODX был разработан при использовании концепции «неприятия чужой разработки» (тенденция сознательно или инстинктивно игнорировать все инновации, которые происходят за пределами организации – прим. переводчика), являющейся не лучшим паттерном проектирования. В основном это означает, что если ранее каждая часть кода была разработана внутри сообщества MODX, то в будущем могут быть использованы более стандартизированные библиотеки, которые разработаны внешними сообществами. Благодаря Composer и Packagist, такое изменение произошло внутри сообщества PHP в последние годы, что позволило максимально просто использовать код внешних разработчиков, а также ускорило рост отдельных библиотек, выполняющих исключительно хорошо одну, четко определенную задачу.

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

Приведу некоторые примеры модулей, которые были разработаны внутри команды MODX ранее до использования внешних библиотек:

  • Журналирование. На данный момент существует удобный метод $modx->log(), однако при изменении данного метода в соответствии с поддержкой интерфейса PSR-3 разработчики смогут сбрасывать записи лога в различные системы журналирования, например, в такие, как Monolog. Система Monolog предоставляет огромное количество впечатляющих возможностей по управлению логами, и когда MODX начнет поддерживать PSR-3, можно будет поддерживать любые из них без изменения ядра MODX.
  • Маршрутизация. Существуют библиотеки, которые могут делать довольно крутые штуки с трансформированием запроса в правильный ответ. Смотрите раздел о фреймворке Slim ниже.
  • Система шаблонов. Честно говоря, мне действительно нравится язык шаблонов в Revolution, но, возможно, использование чего-то более «стандартного» наподобие Twig могло быть интересным улучшением. В любом случае это снизит кривую обучения для многих людей, поскольку Twig используется во многих других проектах.
Это только самые первые вещи, которые приходят на ум, когда мы говорим о повторном использовании готового внешнего кода.

Что такое Slim и зачем его использовать?

Во второй части серии своих статей «Поддерживая MODX в актуальном состоянии», Джейсон отметил фреймворк Slim (версия 3) как наиболее вероятного кандидата для использования в ядре MODX. Это не прошло незамеченным – многие люди начали рассматривать Slim, выясняя, что это такое и как он работает.

Вот что нам нужно знать о Slim:

  • Slim – это маршрутизатор. Он трансформирует Запросы (например, GET /manager/resource/update) в Ответ (например, в форму для обновления ресурса).
  • Slim поддерживает паттерн Middleware (промежуточное программное обеспечение). При использовании данного паттерна вы по существу получаете множество слоев, которые обрабатывают каждый отдельный запрос, а также ответы с возможностью менять их до того, как они достигнут следующего слоя. Техническое объяснение паттерна Middleware можно найти здесь. Паттерн Middleware – это очень эффективный путь для расширения поведения. Slim 3 фактически поддерживает стандарт PSR-7 (черновик) из PHP FIG в его реализации Middleware, что означает, что любой middleware-код с поддержкой паттерна PSR-7 может быть спокойно использован вместе с Slim 3.
  • Slim 3 пока еще находится в разработке; иными словами, он еще не готов для работы в реальном производстве, но похоже, код Slim 3 становится стабильным.
Предположительно, Slim займет место текущих обработчиков запросов и ответов в MODX. Учитывая возможность добавления middleware-кода, это привело бы к крайне гибкой и мощной системе.

Что насчет Менеджера и ExtJS?

Если вы спросите случайную группу MODX-разработчиков об их самой нелюбимой части системы, скорее всего, это будет ExtJS (или в более общей форме – «Менеджер»). На данный момент пока не существует определенного направления для Менеджера, о котором я бы знал, но привязка к ExtJS 3.4 – это явно не то, что должно произойти. ExtJS 3 очень устарел, он недостаточно быстрый и не обеспечивает должной поддержки мобильных устройств. Более того, ExtJS 3.4 больше не обновляется, поскольку ExtJS 6 уже доступен в раннем доступе.

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

Но что же мы знаем?

Учитывая выбор Джейсона в виде Slim как библиотеки ядра, его работы над неким проектом Tacit («высокопроизводительным RESTful фреймворком», основанном на Slim), а также некоторые обсуждения в различных IRC каналах и Slack, наиболее похоже, что следующий Менеджер получит RESTful API в качестве своей основы. Текущий Менеджер также обладает API, но его структура не полностью стандартизирована, а местами направлена именно на то, что от него ожидает ExtJS. Определенно, это не RESTful.

При переходе на RESTful API в качестве основной службы бекенд и интерфейс будут дополнительно разделены с точки зрения кода. Это должно позволить проще разрабатывать по-настоящему уникальные Менеджеры, причем делать эти две части платформы независимо друг от друга. Дизайнеры могли бы сфокусироваться на разработке интерфейса Менеджера третьей версии, а разработчики тем временем работали бы над надежным API.

Что дальше?

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

На данный момент основной фокус MODX – это версия 2.3 и приближающаяся версия 2.4. Выпуск MODX 3 обещает стать захватывающим и привлекательным, так что важно потратить некоторое время для выработки решений перед определением основ новой революции в MODX.

Автор статьи: Mark Hamstra,
оригинал: modx.today/posts/2015/05/what-do-we-know-about-modx-3

Урок 5. Специальные теги MODx | | Уроки MODx Evo

Уроки MODx

Что такое специальные теги MODx – это определенные конструкции, которые необходимо вставлять в код шаблона сайта, чтобы вывести ту или иную динамическую информацию на сайте.

При настройке шаблона мы использовали тег [*content*] для вывода содержимого страниц и тег [(base_url)] для указания базового URL для всех страниц сайта.

В этом уроке мы более подробно разберем основные теги, с которыми вам придется столкнуться при разработке сайтов на MODx.


Наиболее распространенные теги MODx

[(site_name)] – этот тег выводит заголовок вашего сайта. Обычно используется в заглавии страниц HTML в теге <title>. Ниже на рисунке изображено поле, содержимое которого выводит эта конструкция. Отредактировать его можно на странице системной конфигурации.

Рисунок 5.1

[(base_url)] или [(site_url)] – два тега идентичны между собой. Эти конструкции позволяют выводить URL вашего сайта. При создании шаблона мы использовали тег [(base_url)] для указания базового URL для корректной работы с относительными путями.

[*pagetitle*] – эта конструкция выводит содержимое поля Заголовок, которое мы будем заполнять на странице создания/редактирования ресурса.

[*longtitle*] – выводит содержимое поля Расширенный заголовок. Обычно используется как главный заголовок <h2> на странице.

[*description*] – выводит содержимое поля Описание. Это поле будем использовать для вывода содержимого в META-теге description.

[*introtext*] – выводит содержимое поля Аннотация. Это поле чаще всего используют при создании новостей, заметок в блоге и т.п. для организации страниц с кратким описанием заметок.

[*content*] – основное содержимое страниц. Конструкция выводит любой текст или HTML код, написанный или отредактированный в визуальном редакторе.

[*id*] – выводит идентификатор ресурса.

[*alias*] – выводит псевдоним ресурса.

[~идентификатор~] – выводит URL адрес ресурса, идентификатор которого указан. Например, если ID страницы Новости – 4, а псевдоним этой страницы – news, то конструкция [~4~] выведет URL вашей страницы с новостями.  

Обратите внимание:  результатом обработки данной конструкции является лишь строка в виде URL страницы, не перепутайте ее со ссылкой на документ. Ссылка на страницу с использованием этой конструкции будет иметь следующий вид:

<a href=”[~4~]”>Новости</a>

Для простоты понимания приведенных выше тегов MODx мы приводим изображение, на котором изображена страница редактирования ресурса с указанием того, какие теги отвечают за вывод в шаблоне содержимого того или иного поля.

Рисунок 5.2

Выше представлены часто употребляемые теги MODx. Но вы должны иметь ввиду, что всего тегов существует гораздо больше. Чтобы вы имели о них представление, мы дополним список менее распространенными тегами.

[*pub_date*] – дата публикации ресурса

[*unpub_date*] – дата завершения публикации

[*createdby*] – идентификатор пользователя, создавшего ресурс

[*createdon*] – дата создания ресурса

[*editedby*] – идентификатор пользователя, редактировавшего ресурс

[*editedon*] – дата редактирования ресурса

[*contentType*] – тип содержимого (например, text/html)

[*type*] – тип (ресурс, папка или ссылка)

[*published*] – опубликован ли ресурс (1|0)

[*parent*] – номер (ID) родительского ресурса

[*isfolder*] – является ли ресурс папкой (1|0)

[*richtext*] – используется ли при редактировании страницы визуальный редактор

[*template*] – номер (ID) используемого шаблона для ресурса

[*menuindex*] – порядковый номер отображения в меню

[*searchable*] – доступен ли ресурс для поиска (1|0)

[*cacheable*] – кэшируется ли ресурс (1|0)

[*deleted*] – ресурс удален (1|0)

[*deletedby*] – идентификатор пользователя, удалившего ресурс

[*menutitle*] – заголовок меню, если таковой есть

[*donthit*] – слежение за количеством посещений отключено (1|0)

[*haskeywords*] – ресурс содержит ключевые слова (1|0)

[*hasmetatags*] – ресурс имеет META теги (1|0)

[*privateweb*] – ресурс входит в частную группу пользовательских документов (1|0)

[*privatemgr*] – ресурс входит в частную группу менеджерских документов (1|0)

[*content_dispo*] – вариант выдачи содержимого (1 – для отображения | 0 – прикрепленное для скачивания)

[*hidemenu*] –документ не отображается в меню (1|0)

[(modx_charset)] – выводит название используемой кодировки

[^qt^] – выводит время запросов к базе данных

[^q^] – выводит количество запросов к базе данных

[^p^] – выводит время работы PHP скриптов

[^t^] – выводит общее время генерации страницы

[^s^] – выводит источник содержимого (база или кэш)

 

1. Откройте для редактирования чанк HEAD и в теге <title> вставьте констркуцию:

[*pagetitle*] | [(site_name)]

Эта конструкция будет выводить в названии HTML-страницы название ресурса и заголовок сайта, разделенные знаком «|».

2. Затем можно добавить META тег description, в содержимое которого вписываем конструкцию [*description*]

<meta name=»description» content=»[*description*]»/>

3. Можно сразу изменить кодировку в шаблоне. Если помните, у нас она была выставлена в UTF-8. В списке выше указан тег, который выводит название кодировки используемой на сайте.

После внесения всех перечисленных изменений чанк HEAD будет иметь следующий вид:

<head>
<base href=»[(site_url)]» />
<title>[*pagetitle*] | [(site_name)]</title>
<meta http-equiv=»Content-Type» content=»text/html; charset=[(modx_charset)] «/>
<meta name=»description» content =»[*description*]»/>
<meta http-equiv=»imagetoolbar» content=»no» />
<link rel=»stylesheet» href=»/assets/templates/site-labmodx/styles/layout.css» type=»text/css» />
<script type=»text/javascript» src=»/assets/templates/site-labmodx/scripts/jquery-1.4.1.min.js»></script>
<script type=»text/javascript» src=»/assets/templates/site-labmodx/scripts/jquery.jcarousel.pack.js»></script>
<script type=»text/javascript» src=»/assets/templates/site-labmodx/scripts/jquery.jcarousel.setup.js»></script>
</head>

4. Вы можете посмотреть, как выглядит заголовок страницы в окне браузера. У нас выглядит так:

Рисунок 5.3

5. Сейчас неплохо было бы автоматизировать вывод главного заголовка <h2> на страницах сайта. Для этого отправляемся на страницу редактирования чанка и перед уже знакомым тегом вывода содержимого страницы вставляем вывод заголовка, содержимое которого будем брать из поля Расширенный заголовок. Как мы видели из рисунка – этому полю соответствует тег [*longtitle*]. После внесения изменений чанк CONTENT примет следующий вид:

<div>
<h2>[*longtitle*]</h2>
[*content*]
</div>

Таким образом, главные заголовки <h2> наших страниц будут выставляться автоматически, и их не нужно будет вписывать в визуальном редакторе. Главное – это не оставлять пустым поле Расширенный заголовок при редактировании ресурса. Так же для организации заголовков Вы можете использовать содержимое других полей, например, поле Заголовок. В этом случае в чанк CONTENT вам необходимо будет добавлять конструкцию <h2>[*pagetitle*]</h2>.

Стили для заголовка в шаблоне уже прописаны. Поэтому, если поле Расширенный заголовок вы не оставили пустым на странице у вас появится заголовок. Вот так он выглядит:

Рисунок 5.4 

6. После этого нам необходимо добавить вывод заголовков в шаблон Во всю ширину, ведь Вы помните, что в этом шаблоне чанка CONTENT у нас нет, а содержимое страниц мы вызываем сразу из шаблона с помощью тега [*content*]. Поэтому, откройте страницу редактирования шаблона и добавьте над этим тегом вывод заголовка: <h2>[*longtitle*]</h2>. После изменений шаблон Во всю ширину должен выглядеть следующим образом. 

Рисунок 5.5

Реализация цепочки навигации «Хлебные крошки». Сниппет Breadcrumbs

Цепочка навигации будет показывать посетителю, где он находится относительно главной страницы.

Рисунок 5.6

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

Чтобы вызвать сниппет Breadcrumbs в шаблоне мы должны вставить следующую конструкцию:

В этом случае результат работы будет кэшироваться, и при  повторном вызове сниппета код не обрабатывается, а берется из кэш. Некэшируемый вызов осуществляется с помощью названия сниппета, помещенного в квадратные скобки с восклицательными знаками. Вот как бы выглядел некэшируемый вызов: [!Breadcrumbs!].

Результатом работы этого сниппета будет вывод пунктов,  которые отражают иерархию сайта для активной страницы. При этом все пункты навигации будут описаны соответствующими CSS классами.

Например, в нашем случае на странице О нас этот сниппет выведет разметку следующего вида:

<span>
    <span><a href="/main.html" title="Описание страницы">Главная</a></span>
    <span>
        <span>О нас</span>
    </span>
</span>

 Если проанализировать этот код, то мы увидим, что каждый пункт имеет свой класс, при этом последний пункт у нас выводится без ссылки. Разделителем между пунктами служит правая кавычка-ёлочка. Код этого символа: &raquo;.

Для оформления внешнего вида при выводе сниппета используются следующие CSS классы, которые вы должны знать:

  • .B_crumbBox – служит для оформления всего блока цепочки навигации
  • .B_homeCrumb – служит для оформления ссылки, ведущей на главную страницу
  • .B_currentCrumb – служит для оформления пункта текущей страницы
  • .B_firstCrumb – служит для оформления первого элемента цепочки
  • .B_lastCrumb – оформление последнего пункта цепочки
  • .B_crumb – оформление всех остальных элементов (кроме первого, последнего и текущего)
  • .B_hideCrumb – оформление блока c многоточием «…», который появляется в том случае, когда количество пунктов больше установленного вами значения

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

В нашем шаблоне хлебные крошки будут отображаться на всех страницах, кроме главной. Мы вынесли этот элемент в отдельный чанк с именем BREADCRUMB. Сейчас в этом чанке находится следующий код:

<div>
  <div>
   <ul>
      <li>You Are Here</li>
      <li>»</li>
      <li><a href="#">Home</a></li>
      <li>»</li>
      <li><a href="#">Grand Parent</a></li>
      <li>»</li>
      <li><a href="#">Parent</a></li>
      <li>»</li>
      <li><a href="#">Child</a></li>
    </ul>
  </div>
</div>

7. Навигационная цепочка в этом чанке представляет собой ненумерованный список, помещенный в два контейнера <div> и <div>. При этом первый элемент цепочки обозначен классом first, а текущий – current. Чтобы сделать динамическую цепочку навигации мы удаляем этот список и на его место вставляем конструкцию вызова сниппета Breadcrumbs. После чего чанк BREADCRUMB будет содержать в себе следующий код:

<div>
   <div>
    [[Breadcrumbs]]
   </div>
</div>

Внимание: в конструкции вызова сниппета имя должно быть написано точно так же, как на странице в администраторской панели: Элементы – Управление элементами – Сниппеты. Это значит, что если Вы напишите с маленькой буквы, либо все буквы будут заглавными, то вызов сниппета осуществлен не будет.

8. Обновите сайт. В браузере на всех страницах, кроме главной будет отображаться динамическая цепочка навигации. Вот как она будет выглядеть на странице Услуги:

Рисунок 5.7

Рассмотрим специальные параметры, которые Вы сможете передавать сниппету Breadcrumbs, чтобы иметь полный доступ к оформлению цепочки навигации.

Напомним, что передача параметров сниппету осуществляется с помощью следующей конструкции:

[[Breadcrumbs? &имя_параметра1=`значение` &имя_параметра2=`значение`]]

Мы уже пользовались подобным синтаксисом при передаче параметров сниппету Wayfinder в уроке о реализации динамического меню.

Параметры Breadcrumbs

Общие настройки:

  • &maxCrumbs – максимальное число пунктов в цепочке. 
    Возможные значения: целое число. 
    По умолчанию: 100.

    Примечание: если установлено число меньше возможного количества пунктов, то посредине цепочки появится многоточие «…» вместо лишних пунктов.

  • &respectHidemenu – скрывать пункты, не помеченные для показа в меню. 
    Возможные значения: 0 — отображать | 1 — скрывать.
    По умолчанию: 1.

    Примечание: включать и отключать пункты для показа в меню можно на странице редактирования ресурса на вкладке «Общие». галочка «Показывать в меню».

  • &showCurrentCrumb – показывать в цепочке пункт с  названием текущей страницы.
    Возможные значения 0 — не показывать | 1 — показывать.
    По умолчанию: 1.

    Примечание: с помощью этого параметра можно отключить отображение последнего пункта в цепочке.

  • &currentAsLink – отображать пункт текущей страницы в виде ссылки или в текстовом виде.
    Возможные значения 0 — текст | 1 — ссылка.
    По умолчанию: 0.

    Примечание: по умолчанию этот параметр отображает пункт текущей страницы в виде простого текста, если вы захотите отобразить пункт в виде ссылки на текущую страницу, выставьте значение 1.

  • &linkTextField – название пунктов в цепочке навигации.
    По умолчанию: menutitle или pagetitle.
    Возможные значения: description | longtitle | pagetitle | menutitle.

    Примечание: от этого параметра зависит, какое поле будет браться для формирования названия пунктов цепочки навигации. По умолчанию название пункта цепочки будет совпадать с названием пункта меню, которое можно изменить на странице редактирования ресурса в поле «Пункт меню».

  • &linkDescField – атрибут title для ссылок в цепочке навигации.
    По умолчанию: description.
    Возможные значения: pagetitle, longtitle, description, menutitle.

    Примечание: значение атрибута title всплывает при наведении мышки на ссылку в цепочке навигации. По умолчанию берется значение поля «Описание», которое можно изменить на странице редактирования ресурса.
  • &showCrumbsAsLinks – пункты цепочки навигации являются ссылками или текстом.
    Возможные значения: 0 — текст | 1 — ссылки.
    По умолчанию: 1.

    Примечание: можете установить значение 0, если по какой-то причине хотите, чтобы цепочка навигации была некликабельна и отображалась в виде текста.

  • &crumbGap – строка, которая будет представлять собой разрыв цепочки навигации.
    Возможные значения: строка.
    По умолчанию: многоточие «…».

    Примечание: вы можете указать какие символы будут разрывать цепочку навигации, если количество пунктов в цепочке больше указанного в &maxCrumbs значения.

  • &stylePrefix – приставка в названиях CSS классов.
    Возможные значения: строка.
    По умолчанию: B_.

    Примечание: значение этого параметра определяет префикс в названии CSS классов. Чуть выше мы уже отметили, какие классы используются при выводе HTML разметки и за что они отвечают.

Настройки для ссылки на главную страницу:

  • &showHomeCrumb – отображать ссылку на главную страницу.
    Возможные значения: 0 — не отображать | 1 — отображать.
    По умолчанию: 1.

    Примечание: по умолчанию в начале цепочки навигации отображается ссылка на главную страницу, даже если ее нет в иерархии текущего документа.

  • &homeId – идентификатор страницы, которая будет считаться главной.
    Возможные значения: целое число.
    По умолчанию: $modx->config[‘site_start’].

    Примечание: по умолчанию главной страницей будет считаться та, идентификатор которой указан на странице системной конфигурации в поле «Первая страница».

  • &homeCrumbTitle – текст пункта главной страницы в цепочке навигации.
    Возможные значения: строка.
    По умолчанию: menutitle или pagetitle.

    Примечание: использовать этот параметр вы можете в том случае, когда захотите, чтобы текст пункта главной страницы отличался от названия пункта меню главной страницы или заголовка страницы, которые можно изменить при редактировании ресурсов. Например, некоторые разработчики вписывают вместо названия «Главная страница» в цепочке навигации название домена.

  • &homeCrumbDescription – пользовательский текст, который может быть использован в качестве атрибута title для ссылки на главную страницу.
    Возможные значения: строка.
    По умолчанию: значение, указанное в параметре linkDescField.

    Примечание: если поле оставить пустым, то текст для атрибута title будет определяться параметром &linkDescField. При желании можете вписать текст, который всплывет при наведении курсора на ссылку. Например, «Перейти на главную страницу»

Настройки для отображения цепочки навигации на различных страницах:

  • &showCrumbsAtHome – отображать цепочку навигации на главной странице.
    Возможные значения: 0 — не отображать | 1 — отображать.
    По умолчанию: 1.

    Примечание: с помощью этого параметра можно отключить показ цепочки навигации на главной странице.

  • &hideOn – не отображать цепочку навигации на страницах
    Возможные значения: разделенные запятыми идентификаторы страниц, на которых не должна отображаться цепочка навигации.

    Примечание: этот параметр удобно использовать для небольшого количества страниц, на которых в качестве исключения не нужен вывод строки навигации. Если же таких страниц много, то лучше воспользоваться параметром &hideUnder либо подумать над созданием еще одного шаблона.

  • &hideUnder – не отображать цепочку навигации на дочерних страницах
    Возможные значения: разделенные запятыми идентификаторы папок, на дочерних документах которых не должна отображаться строка навигации.

    Примечание: указание ID папок скрывает строку навигации только на дочерних страницах. Если вы хотите, чтобы строка не отображалась как на дочерних, так и на родительских страницах, добавьте ID родительских ресурсов как в &hideUnder так и в &hideOn.

Потренируемся передавать дополнительные параметры во время вызова сниппета.

Давайте выведем цепочку навигации, у которой текст ссылки на главную страницу будет Главная, при наведении мышки на ссылку главной страницы будет всплывать надпись Перейти на главную страницу, атрибут title для всех остальных ссылок будет подставляться из поля Расширенный заголовок. Остальные все значения параметров оставим по умолчанию.

9. В чанке BREADCRUMB вставьте конструкцию, приведенную ниже:

[[Breadcrumbs?  &homeCrumbDescription=`Перейти на главную страницу` &linkDescField=`longtitle`]]

Рисунок 5.8

 

10. Обновите страницу в браузере. Вот как будет выглядеть получившаяся цепочка навигации:

Рисунок 5.9

11. Теперь изменим внешний вид цепочки навигации в CSS стилях (файл layout.css). Давайте сделаем так, чтобы ссылки отличались от обычного текста. Сделаем ссылки подчеркнутыми, а при наведении курсора на ссылку – без подчеркивания. Для этого мы идем редактировать CSS-файл, который лежит в директории:

assets/templates/site-labmodx/styles/layout.css

Находим в этом файле стили, отвечающие за отображение блока BreadCrumb (в 114 строке). Удалите эти стили.

/* ----------------BreadCrumb--------------*/
 
#breadcrumb{
    padding:20px 0;
    }
 
#breadcrumb ul{
    margin:0;
    padding:0;
    list-style:none;
    }
 
#breadcrumb ul li{display:inline;}
#breadcrumb ul li.current a{text-decoration:underline;}

12. Вставьте следующие стили вместо удаленных:

#breadcrumb {padding:20px 0;}
#breadcrumb a{text-decoration:underline;}
#breadcrumb a:hover{text-decoration:none;}

Обновите страницу. Если после обновления не видно изменений (мы ведь используем кэшируемый вызов сниппета Breadcrumb), нажмите Ctrl+F5, чтобы загрузить страницу не из кэша браузера. После обновления страницы внешний вид нашей цепочки навигации изменится, но незначительно. Ссылки будут подчеркнуты.

Рисунок 5.10

Как перенести сайт на MODx с компьютера на компьютер
или на другой хостинг

Маркетплейс дополнений для MODX / modstore.pro

Маркетплейс готовых дополнений для CMS MODX Revolution от лучших русскоговорящих разработчиков.

Интегрирован с хостингом Modhost.

Цифры и факты

Дополнений390
Пользователей16 721
Загрузок287 696
Ключей49 016
Авторов79

Подпишитесь на рассылку!

Мы не спамим и отправляем письма с обновлениями Modstore.pro и Modhost.pro не чаще раза в месяц.

Возможность работы на тестовом и “боевом” доменах

Подробная документация

Техническая поддержка напрямую от авторов дополнений

Крупнейший поставщик дополнений для MODX

Схема работы маркетплейса Скрыть Показать

Бесплатное демо дополнений на тестовом тарифе modhost.pro Платные дополнения

Авторизация в ЛК Modstore

Создание ключа для 1 сайта в ЛК

Возможность задавать вопросы по купленному дополнению в Технической поддержке 1 год.

Покупка дополнения для ключа

Бесплатные дополнения

Возможность сбросить привязку ключа к домену один раз в ЛК

Настройка репозитория Modstore в “админке” вашего сайта

Подключение и загрузка дополнения из репозитория Modstore

Бесплатное демо дополнений на тестовом тарифе modhost.pro Платные дополнения

 

Бесплатные дополнения

Авторизация в ЛК Modstore

Создание ключа для 1 сайта в ЛК

Возможность задавать вопросы по купленному дополнению в Технической поддержке 1 год.

Покупка дополнения для ключа

 

Возможность сбросить привязку ключа к домену один раз в ЛК

Настройка репозитория Modstore в “админке” вашего сайта

 

 

Подключение и загрузка дополнения из репозитория Modstore

 

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *