ГлавнаяModxModx разработка

MODX Revo — создание сайта на основе шаблона. Modx разработка


MODx Revolution. Разработка компонентов: от задачи до сборки в пакет!

👍 Проверенный курс от канала OpenModx🖥 Создатель курса — эксперт веб-разработки и MODx Revolution — Артем Зернов!💎 Контент качественный и уникальный! Хорошая картинка и звук!👨‍💻 Предназначен для разработчиков, знакомых с MODx.

Более 50 человек успешно прошли курс

В рамках курса мы рассмотрим весь процесс разработки компонента: от постановки задачи до сборки в пакет.

Как разрабатывать компоненты?

Сколько раз ты вбивал в поиске похожую строку?

В интернете есть много разрозненной неструктурированной информации по этому вопросу. В этом курсе ты увидишь все в подробностях, поэтапно — от постановки задачи, до сборки в пакет.

Через какие темы мы пройдем?

В процессе все видео-курса мы пройдем через следующие темы:

Для кого подходит этот курс?

Артем Зернов

РАЗРАБОТЧИК КУРСА

Я начал создавать сайты в 2006-м году. Позже я основал студию Open Colour. А еще немного позже я познакомился с MODx Revolution, который стал для меня примером отлично спроектированного фреймворка и системы управления сайтами.

Я лично разработал все видео, в которых поделился всеми знаниями на тему разработки компонентов и даже больше!

 @zernov

Ценность курса

Многолетний опыт спикера, создателя канала OpenModx и эксперта в области MODx Revolution, собранный в едином курсе. Данный курс содержит ценную наглядную информацию, последовательно и подробно изложенную доступным и понятным языком.

 >10лет Опыт спикера в разработке сайтов

Состав курса

Курс представляет собой набор из 14-ти видео-уроков по 15-30 минут на каждый.

Каждый урок освещает отдельный аспект разработки компонентов для MODx Revolution.

УЗНАТЬ ПОДРОБНЕЕ

info-cast.ru

Разработка дополнения в MODX Revolution. Часть 1 MODX

Содержание статьи:

Обзор

Этот урок написан как всеобъемлющий пример разработки дополнения для MODX Revolution 2.2 и выше, а также описывает как упаковать дополнение в Транспортный пакет, кроме этого рассказывается как разрабатывать Дополнение вне корневого каталога MODX, чтобы можно было использовать программы контроля версий (такие как Git).

Мы рассмотрим Дополнение "Doodles" - простое дополнение, которое использует пользовательскую таблицу для хранения объектов называемых "Doodles" с полями name (имя) и description (описание). Мы создадим Сниппет, который извлекает их и выводит список, шаблонируемый через чанк, также создадим Пользовательскую страницу менеджера используя ExtJS с CRUD-сеткой для редактирования (CRUD - create, read, update, delete) и сделаем скрипт упаковки. Это всеобъемлющий урок, поэтому если вам нужны какие-то отдельные части, то см. выше Содержание.

Установка каталогов

Есть много способов как начать разрабатывать собственное дополнение - вы можете это сделать прямо в MODX и упаковать его с помощью такого инструмента как PackMan или можете разрабатывать вне корневого каталога MODX разместить его в такой системе контроля версий как Git, например. Этот урок будет использовать последний способ, так как он имеет несколько преимуществ:

Давайте начнём. Я создал каталог в моём корневом /www/ каталоге: /www/doodles/

Вы можете создать свой где хотите, но в этом уроке я буду ссылаться на /www/doodles/. Сделайте локальную копию каталога для дальнейших нужд. У меня локальная копия /www/ находится в корне / в моём локальном отладочном окружении, например.

Можно добавить Системную настройку с именем "session_cookie_path" и дать ей значение "/" (без кавычек оба). Это скажет MODX использовать ту же сессию, когда вы запускаете что-то по адресу http://localhost/doodles/. Также, дать этой настройке уникальное имя через session_name (например "modxlocaldevsession") это тоже хорошая идея. Это предотвратит конфликты с другими MODX установками на вашей локальной машине. После этого очистите core/cache/ каталог и перезайдите после.

Итак у нас получиться несколько рабочих каталогов:

Давайте обратим внимание на несколько вещей. Во-первых наши 3 основных каталога - это core/, assets/ и _build/. Давайте разберёмся в нескольких моментах того, как работают MODX Дополнения - обычно (но не на 100% всегда), Дополнения разделяются при установке и попадают в 2 различных каталога: core/components/doodles/ и assets/components/doodles/. Почему? Потому что каталог assets/components/ содержит только веб-специфические объекты - JavaScript файлы, CSS файлы и т.д. Это файлы, которые доступны через сеть. Все PHP файлы, классы, карты и другие файлы в то же время находятся в каталоге core/components/. Это предохраняет от нежелательного доступа в каталоге core/ (который может быть перенесён куда-либо вне корня в некоторых MODX установках для большей безопасности).

Итак мы разделим наши файлы по каталогам для имитации того, как они будут разделены в MODX установке после установки из Транспортного пакета.

Каталог _build/ не упаковывается в zip файл после создания Транспортного пакета. Он служит для построения самого Транспортного пакета. Мы рассмотрим этот момент ближе к концу урока.

Давайте пройдёмся более детально по каждому подкаталогу. В каталоге assets/ единственный неочевидный файл - это connector.php. Этот файл позволит нам использовать кастомные процессоры на нашей Пользовательской странице менеджера (ПСМ), которую мы чуть позже создадим.

В каталоге core/components/doodles/ у нас есть несколько каталогов, которые нужно рассмотреть:

Также обратите внимание, что эта директория находиться полностью вне нашего корневого каталога MODX. Поэтому, да - вы можете запускать "git init" и делать собственный Git репозиторий вне каталога /www/doodles/ (или как там вы его назовёте). И вы можете делать push без особых забот (есть правда несколько файлов о которых мы поговорим чуть позже, их нужно будет добавить к .gitignore файлу).

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

Создание сниппета-заготовки Doodles

Давайте продолжим и создадим файл snippet.doodles.php:

/www/doodles/core/components/doodles/elements/snippets/snippet.doodles.php

Вам нужно создать каталог snippets/, если он у вас ещё не создан. Давайте добавим пару строчек кода в ваш пустой файл:

Давайте разберёмся с этим кодом. Во-первых, у нас есть вызов getService. Сейчас он оформлен одной строкой, поэтому давайте разделим её и разберёмся что к чему:

Ну во-первых, что такое $modx->getOption? Это метод, который берёт системную настройку по ключу (первый параметр). В первой строчке мы получаем путь по-умолчанию к нашему сниппету Doodles (подразумеваем, что он находиться в папке core/). Полный путь будет: /www/modx/core/components/doodles/

Далее мы передаём это значение по-умолчанию как запасное для метода получения опции getOption. Этот метод содержит 3 параметра: ключ с именем "doodles.core_path", null и наш путь по-умолчанию. В getOption второй параметр - это массив для поиска ключа (который мы не используем, поэтому дали ему значение null) и 3й параметр для случая, когда ключ не найден.

Поэтому прямо сейчас наша 2ая строчка возвратит /www/modx/core/components/doodles/. Но это не путь к нашему Doodles ядру! (подсказка: правильный путь /www/doodles/core/components/doodles). Мы хотим этими строками задать поиск его. Так что же нам делать?

Создание настроек волшебного пути

Мы создаём несколько Системных настроек (специально для нашей среды разработки), которые сообщат нашим строкам, где нужно искать наши файлы! Давайте продолжим и создадим их:

Если вам нужно поменять данные значения для корректировки путей, таких как URL, то сделайте это. Теперь наша первая строчка кода возвратит: /www/doodles/core/components/doodles/ Отлично! Продолжим?

Для чего мы всё это делаем? Почему взять просто и не написать /www/doodles/core/components/doodles/? Ну, хотя бы потому, что это не сработает в чей-то другой установке. Скорее всего данный путь будет таким: MODXPATH/core/components/doodles/. Наш транспортный пакет (позже) будет обрабатывать все эти динамические настройки, но мы хотим добавить возможность записи их для того, чтобы можно было разрабатывать Doodles вне каталога MODX. Так как мы только что сделали!

Перейдём к третьей строке:

Метод $modx->getService загружает класс и инициализирует его объект, если он существует, устанавливает его в $modx->doodles в нашем случае (первый параметр передаётся). Больше информации можно найти здесь. Но подождите! У нас ещё нет Doodles класса! Самое время сделать его.

Создание базового Doodles класса

Во-первых, вы скорее всего спросите меня, почему мы создаём этот класс. Ну, он поможет нам в нескольких аспектах: мы можем определить некоторый базовые пути в нём, которые потом будем использовать во всём нашем Компоненте и он может дать нам некоторые методы для использования. Поверьте мне, он полезен. Давайте создадим его в /www/doodles/core/components/doodles/model/doodles/doodles.class.php:

Отлично! Всё пока довольно-таки просто - просто создаём объект класса, который имеет конструктор, который устанавливает ссылку на modX объект в $doodles->modx. Это пригодиться позже. Также он задаёт некоторые базовые пути, которые мы будем использовать позже в $doodles->config массиве и этот трюк с Системными настройками приведёт нас к пути в /www/doodles/.

Вернёмся к нашему сниппету. Давайте продолжим и добавим некоторые свойства по-умолчанию к нашему Сниппету. После упомянутых выше строчек он будет выглядеть так:

Отлично. Теперь мы хотим использовать xPDO для получения записей из базы... НО, мы ещё не сделали xPDO модель для них. Давайте вначале сделаем это.

Создание модели

xPDO абстрагирует БД в ООП методы запросов. На данный момент оно начало поддерживать различные типы БД и оно делает это через абстракцию запросов к БД. Также оно позволяет вам содержать ваши строки БД в виде упорядоченых, чистых классов и изящно выполнять все работы через короткие строчки кода. Но чтобы сделать это, нам нужно добавить xPDO модель к нашему сниппету (через $modx->addPackage метод). Но вначале нам нужно создать эту модель, используя xPDO схему. Есть отличный урок по созданию xPDO модели как это можно сделать, но мы пройдём быстро этот вопрос.

Продолжим и создадим xml файл в /www/doodles/core/components/doodles/model/schema/doodles.mysql.schema.xml. Вставим в него следующий код:

Отлично. Тут много всего. Во-первых, первая строка:

Она сообщает схеме, что наш xPDO пакет называется 'doodles'. Это то, на что мы будем ссылаться в нашем addPackage() вызове. Отлично. Это также говорит, что базовый класс для всех объектов определён здесь как "xPDOObject" и что эта схема сделана для MySQL. Наконец, она задаёт по умолчанию MySQL движёк как MyISAM. Дальше пойдём!

"Объект" в xPDO схеме - это в основном таблица БД. Эта строка сообщает, дайте xPDO имя для таблицы с названием '{table_prefix}doodles'. Подразумеваем, что в вашей установке префикс таблицы - это "modx", что создаст нам "modx_doodles". Далее она сообщает, что он расширяет "xPDOSimpleObject". Что это значит? xPDOObject - это базовый объект для любого xPDO табличного класса. xPDOSimpleObject расширяет его, но добавляет хорошенькое автоинкрементное поле "id" к этой таблице. Поэтому, если нам нужно поле "id" в таблице, то мы используем xPDOSimpleObject.

Следующие поля вполне очевидны - это поля таблицы БД. Давайте продвинемся к следующим двум частям:

Отлично, это место, где вступают в xPDO игру связанные объекты. Для целей этого урока, просто знайте, что они сообщают xPDO, что поле createdby связано с modUser и поле editedby ведёт к другому modUser. Круто? Теперь давайте перейдём к парсингу этого xml файла и к созданию наших классов и связей.

Скрипт парсинга схемы

Самое время взглянуть на нашу подзабытый _build каталог. Создадим там файл: /www/doodles/_build/build.schema.php и поместим туда код:

В основном этот файл парсит вашу XML схему и создаёт xPDO классы и связи (PHP представление XML файла) для вашего компонента. Мы вернёмся позже к этому, но так просто он не запустится. Он засбоит в поиске файла a /www/doodles/_build/build.config.php. Время сделать такой файл!

Очевидно, что вам понадобятся эти пути, где бы не находилась ваша MODX установка.

Теперь вы можете перейти к вашему _build/build.schema.php файлу и запустить его. Я делаю это в строке браузера: http://localhost/doodles/_build/build.schema.php. Вам скорее всего будет нужно поменять это на другой адрес, по которому находиться ваш doodle каталог.

Это должно запуститься и сгенерировать нужные файлы и связи:

Браво! Теперь вы сделали ваши связи и классы. Давайте сделаем уточнения в нашем базовом Doodle классе, чтобы он автоматически добавлял в Doodles xPDO пакет при загрузке этого класса. Добавьте следущую строку после этой $this->config = array_merge part, прямо в конце конструктора:

Это сообщает xPDO, что мы хотим добавить 'doodles' xPDO пакет, позволяя нам делать запросы к пользовательской таблице. Отлично!

Ок, наш сниппет теперь выглядит приблизительно так:

Ламерский сниппет, согласны? Хорошо, что мы сейчас делаем, так это устанавливаем объект Doodles класса в переменную $dood и устанавливаем некоторые значения по-умолчанию для свойств для дальнейшего использования. $scriptProperties - это массив, между прочим, всех передаваемых в сниппет свойств. Вызов getOption парсит его для поиска в них свойств и если они не установлены, то берёт свойства по-умолчанию.

Статический сниппет

Возможно вы подумаете: "Это всё ещё даже не в MODX manager! Что он нам тут рассказывает? Наверное шутит?" Отличный вопрос, давайте сделаем это!

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

Создайте новый сниппет чекнув "Is Static". Появятся два новых поля. Первое, Медиа Источник (Media Source) для поля файла (Static File). Оно предложит список медиа источников для базового использования. Так как наш Doodles находиться не в MODX веб пространстве, нам нужно выставить это поле в Нет ("None"). Теперь нам нужно ввести путь к файлу сниппета. Также используем установки пути, которые мы создали в Системных настройках и добавить остаток пути к действительному сниппет файлу.

Обратите внимание на дополнительный слеш между системной настройкой и остальным путём. В core_path этот слеш есть, но по дороге он где-то затерялся, поэтому добавим его здесь. Путь будет рендериться как /www/doodles/core/components/doodles/elements/snippets/snippet.doodles.php

Отлично сработано! Далее можно продолжать редактировать наш сниппет в своей любимой IDE и делать в нём нужные вещи. Он также передаёт все параметры, которые мы передаём в вызове сниппета в наш Doodles сниппет. Круто! Возвращаемся к нашему сниппету.

Построение запроса

Во-первых, нужно создать таблицу. Это будет сделано в преобразователе (резольвере) позже, но сейчас просто добавьте следующий код к вашему сниппету прямо перед оператором return:

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

Добавим это к нашему сниппету перед оператором return:

Это возьмёт наш массив Doodle объектов или в терминах не xPDO, несколько рядов из таблицы БД. Сохраним наш сниппет и запустим через строку браузера http://localhost/modx/doodles.html (или какой у вас там будет адрес ресурса). У вас должно вывести:

0

Ха, обманул вас! В действительности, в первый запуск ничего не выведет, так как в таблице нет данных. Давайте добавим туда какие-нибудь данные.

Для этого используйте любое удобное для вас ПО для работы с БД (например phpMyAdmin) и найдите таблицу 'modx_doodles' в вашей БД. Добавьте несколько рядов к ней (просто добавьте name/description значения). Это должно выдать вам какие-то данные. Допустим вы добавили 2 ряда. Продолжим и запустим сниппет, получим следующее:

2

Отлично! Ваш пользовательский запрос к БД сработал! Давайте усложним его. Мы можем использовать xPDO xPDOQuery для создания сложных запросов. На данный момент добавьте команду сортировки:

Отлично. Это отсортирует поле по $sort (который мы определили ранее) в направлении $dir. Теперь нам нужно создать вывод!

Метод getChunk класса Doodles class

Во многих из моих экстра, я добавляю парочку вспомогательных методов к моему базовому классу getChunk. Они позволяют мне использовать чанки-файлы для разработки. Давайте так и сделаем. Откроем Doodles класс и добавим эти два метода:

В данный момент всё что нужно знать: эти методы будут искать Чанки в вашем /www/doodles/core/components/doodles/elements/chunks/ каталоге с постфиксами '.chunk.tpl' и все в нижнем регистре (маленькими буквами). Если чанки не найдутся в файловой системе, то будет продолжен поиск в MODX. Поэтому, когда мы вызываем:

То это задаст для $o содержимое /www/doodles/core/components/doodles/elements/chunks/hello.chunk.tpl со свойством [[+name]] спарсенным как Joe. Это позволит вам отредактировать ваши Чанки в вашей IDE, а не в MODX. Это также позволит вам упаковать ваш Компонент без установки чанков по-умолчанию в пользовательскую MODX установку (которую они будут пытаться перезаписать, что будет стёрто при обновлении вашего Компонента).

Возвращаемся к нашему сниппету. Создадим файл-чанк /www/doodles/core/components/doodles/elements/chunks/rowtpl.chunk.tpl и вставим туда код:

Теперь добавим это после вашего запроса, но перед return в вашем Сниппете:

Этот код итерирует через все Doodle объекты, которые у нас есть с вызовом getCollection и создаёт PHP массив из их значений методом toArray. Далее он использует getChunk и этот массив для шаблонирования чанком каждого ряда вывода и склейкой выводимого результата в переменную $output. Таким образом мы получим группу \<li\> тегов (столько, сколько вы добавили рядов в БД). Всё будет выглядеть приблизительно так:

Конечно же, вы можете внести любые изменения в этот Чанк и можете как угодно его назвать, мы получили возможность шаблонизировать вывод Сниппета! Ура!

Давайте ещё раз всё пройдём. Наш сниппет выглядит вот так:

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

Выводы

Мы сделали неплохую пользовательскую модель БД, которую использует наш Doodles сниппет для получения записей из БД. Также мы рассмотрели базовую структуру обобщённого MODX компонента.

Нам нужно ещё, чтобы эти данные как-то редактировались в MODX менеджере, правильно? Вот где нам пригодятся Пользовательские страницы менеджера (Custom Manager Pages). Перейдём к следующей части данного урока.

Остальные статьи:

modx.ws

Система управления контентом MODX Revolution

 

Недавно мне посчастливилось познакомиться с невиданной мной доселе CMS - MODX ("модекс"). Все случилось просто - позвонил старый знакомый и попросил "посмотреть" его сайт и взять его на поддержку. Когда-то его сайт был сделан на всеми любимым Wordpress, но постоянные атаки видимо сподвигли его отказаться от этого движка и перейти на что-то "более другое". Этим "более другим" оказалась система MODX Revolution.

Когда я зашел в админку, у меня сначало закралось ощущение - "а не отказаться ли мне от этого". На первый взгляд вроде все просто и понятно - админка разбита на две колонки, в левой - древовидная структура разделов и материалов, можно сказать, рай для контент-менеджера. В правой - редактор содержимого страницы и/или настройка свойств того или иного объекта. Но если дело коснется администрирования сайта, его модификации и доработки функционала, тут все совсем не так, как в Joomla или Wordpress...

Если в Joomla и Wordpress "программирование" осуществлялось преимущественно мышкой, то в MODX нужно писать код с вручную, причем, иногда достаточно в большом количестве. Синтаксис кода весьма своеобразный. Скорее всего это отпугнет большинство веб-мастеров, не знакомых с программированием на PHP. Я тоже сперва пытался ужаснуться, но потом вспомнил, что когда-то освоил основы работы с php-фреймворком Laravel и меня тогда не напугало, что там вручную нужно писать ВСЕ, а часть команд вообще выполнять через командную строку :) После пары недель привыкания я уже достаточно свободно владел Laravel на таком уровне, чтобы создать на нем простенький проект вроде блога. Посему решил не сдаваться и стал читать документацию по MODX.

На удивление, освоение продвигалось довольно легко. По сложности я бы позиционировал MODX как промежуточное звено между Joomla, там где все делается мышкой и php-фреймворком, тем же Laravel, там где все делается вручную. У MODX уже есть готовая админка, но функционал "из коробки" просто ничтожен - максимум, на что способен MODX в базовой комплектации - создание сайта-визитки из нескольких страниц. Все остальные возможности расширяются дополнениями - плагинами, чанками, сниппетами. Какое-то время понадобилось, чтобы разобраться что это такое. Оказалось, все несложно:

По мере расширения функциональности сайта неизбежно возникает необходимость установки дополнительных плагинов и сниппетов, поскольку стандартными средствами нельзя даже вывести список статей категории. Установка расширений не вызывает каких-либо затруднений - все до безобразия автоматизировано, точно так же как в Wordpress и Joomla.

Чем мне понравился и чем не понравился MODX?

Во-первых понравился быстродействием. Сложно оценить этот фактор на локальном хосте, тем не менее, админка работает заметно быстрее, чем в той же Joomla.

Во-вторых - ничего лишнего. В комплектации "из коробки" MODX "гол как сокол". С одной стороны это недостаток, но с другой - мы можем устанавливать те компоненты, которые нам действительно нужны, не нагружая сервер никакими лишними плагинами (типа "hello dolly" в Wordpress).

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

Если сравнивать с Joomla и Wordpress, сам подход к созданию сайта в MODX несколько иной, но мне он почему-то нравится больше.

Для MODX есть много документации на русском языке.

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

webmaster.artem-kashkanov.ru

Создание сайта на MODX Revo, на основе шаблона

Решил написать новый цикл уроков по созданию сайта на основе шаблона в MODX Revolution. В связи с тем, что подход к разработке сайта и натяжке шаблонов у меня изменился, и я им хочу поделиться (в боковом меню справа можете найти весь цикл прошлых статей, настройки сайта, ЧПУ и т.д. остались прежними (произведите их перед тем как продолжить), нововведения начинаются с процесса интеграции дизайна. В рамках сегодняшнего урока мы перенесем (установим) html шаблон в MODX Revo.

Я буду переделать личный сайт портфолио, так как обычно верстать самому себе некогда, я решил купить готовый шаблон на основе сетки Bootstrap 3. Третий бутстрап выбран не случайно: во-первых — это хороший, гибкий фреймворк. Во-вторых, многие дополнения из modstore.pro используют его стили. Конечно можно залезть во все чанки и переверстать их под себя, но это лишний геморрой, проще поправить готовое решение. Купленный мною шаблон называется Meheraj (стоит 10 баксов): Meheraj — Personal Portfolio Template. Выкладывать его не буду. Используйте свой (так лучше освоите натяжку), если своего нет, идем в статью: MODX шаблоны – где их достать (скачать, заказать, купить).

Загрузка файлов в MODX

У нас есть шаблон содержащий html, css, js и прочие файлы структурированные по папкам.

файлы шаблона

Эти файлы (кроме html — они красненькие в моем случае) нужно залить (загрузить) на сервер, где установлен MODX. Я обычно храню все файлы в директории «assets«.

Вы можете хранить где угодно, создать любую папку (директорию) и хранить там. Можете залить все прямо в корень сайта, тогда не придется менять пути к файлам — не рекомендую так делать.  

Если вы работаете на реальном хостинге, то файлы туда проще всего загрузить через FTP менеджер, например через FilleZilla, если на локальном сервере, то просто скопировать. В результате должны получить следующее.

файлы шаблона в дереве modx

Перенос кода шаблона.

Идем во вкладку «Элементы» — «Шаблоны» — «Начальный шаблон» открываем его и удаляем из него содержимое, а на его место копируем весь код из главного html файла шаблона (index.html), и сохраняем.

переносим html код в modx шаблон

HTML файлы можно открыть при помощи обычного блокнота, но лучше открывать при помощи редактора кода (notepad++, Brackets или любым другим)

Если мы сейчас откроем главную страницу, то увидим следующее.

внешний вид шаблона без подключения скриптов и стилей

Выглядит страшно, не пугайтесь. Выводиться чистый HTML (без css, js, картинок), так как пути к ним сменились). Чтобы все подхватилось (картинки, стили, скрипты), нужно поменять их пути. Сделать это проще всего Notepad++ прямо на компьютере (предварительно сделайте копию оригинального файла), и затем скопировать его в код. Ну либо прямо из административной панели MODX (рекомендую предварительно установить дополнение ace — подсвечивает код и в нем есть emmet).

Редактируем пути к файлам

Сейчас путь до основного css файла выглядит так:href=»style.css»,а так как все файлы залиты в папку (директорию) assets, то нужно заменить путь на:href=»/assets/style.css» и так меняем все адреса до стилей, скриптов, изображений.

редактируем пути в modx шаблоне

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

главная страница

 

 

Бывает, разработчики подгружают картинки при помощи css, так что возможно вам придется менять пути в CSS.

 

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

web-revenue.ru

Создание компонентов MODX / Курсы обучения / bezumkin.ru

Вводное занятие

Это занятие открывает новую веху на сайте bezumkin.ru — курсы обучения. Больше нет «программы поддержки автора», нет особых заметок. Есть новый раздел на сайте, где будут публиковаться разные обучающие курсы.

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

Ну а сегодня я закончил все необходимые приготовления и объявляю о запуске новой программы!

Приблизительный план первого курса:

  1. Настройка рабочего места и IDE PhpStorm
  2. Разбор структуры компонента, зачем нужны assets, core и остальные?
  3. Основы Git и первый коммит заготовки компонента на Github
  4. Продумываем логику работы, определяем схему и модель таблицы в БД
  5. Первые наброски логики, собираем и устанавливаем альфа-версию пакета
  6. Интерфейс админки на ExtJS. Создаём группы рассылок и подписываем на них пользователей.
  7. Интерфейс админки на ExtJS. Создаём рассылку и привязываем её к группе.
  8. Проверяем работу нашего интерфейса, пробуем что-то разослать.
  9. Фронтент. Сниппет вывода доступных подписок пользователю.
  10. Фронтент. Работа с подпиской и отпиской от рассылки.
  11. Тестирование, сборка пакета, окончание работ.
Говорю сразу — список неточный, все может 10 раз поменяться, так как мы пишем новый компонент, а не разбираем существующий. Вы вполне можете что-то изменить в работе, предложить свои идеи или решения.

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

Эта заметка вводная, она объявляет о начале работ и мне уже нужна ваша помощь. Пожалуйста, предложите название для нашего компонента, так как простое и лаконичное Subscribe уже занято.

Без хорошего названия начинать никак нельзя!

Читать дальше

bezumkin.ru

MODX Revolution, MODX Revo, CMS MODX, бесплатные CMS

Возможности MODX Revolution

Хотя каждый пункт из списка ниже не способен полностью отразить всю доступную функциональность, простоту разработки и дружелюбность к пользователю системы управления MODX Revolution, вы cможете представить основные возможности, узнав о некоторых из них:

Безопасность и защита MODX довольно серьезно заботится о безопасности. Вся архитектура MODX Revolution была создана с учетом требований безопасности. Каждый ввод данных фильтруется, а каждый запрос в базу данных при использовании API выполняется через подготовленные запросы (prepared statements), которые устраняют возможность SQL инъекции. Команда разработчиков постоянно проводит аудит кода MODX для того, чтобы быть уверенными в актуальности кода, и исправляет любые проблемы, которые могут возникнуть. Полная свобода творчества Система управления сайтами MODX позволяет создавать сайты точно такими, как вы их себе представляете, с абсолютно неограниченными возможностями для творчества. Мы считаем, что средства разработки сайтов должны учитывать творческое видение пользователей, не вводя никаких специальных ограничений. Бесподобная оптимизация сайтов (SEO) MODX позволяет вам практически без усилий контролировать вывод информации на все 100%. В отличие от других систем, которые требуют изучения сложных движков темизации, в MODX вы работаете напрямую с HTML и с таким количеством специальных переменных сайта, которые действительно вам нужны. Порой тратятся минуты на создание сайта, который занимает удивительно хорошие позиции в поисковых системах. А вследствие того, что разработчик сайта полностью контролирует и может изменять вывод информации в любое время, для внесения улучшений потребуется всего несколько кликов. Устанавливайте MODX как и где хотите Гибкая система установки позволяет развертывать систему практически в любых условиях. Вы можете установить ядро системы вне корня веб-сервера, переименовав директорию ядра для дополнительной безопасности. Также вы можете поддерживать несколько сайтов на MODX из одного набора файлов. Устанавливайте дополнения (add-ons) внутри приложения Система управления пакетами в MODX позволяет администраторам сайтов устанавливать, обновлять и переносить содержимое, шаблоны, дополнения или даже полностью сайты, не беспокоясь о потерянных шагах или зависимостях. Все работает из единого интерфейса внутри Менеджера MODX, который удаленно получает информацию с сайта MODX. Новый Менеджер со встроенной системой индивидуализации Свежий новый интерфейс, построенный на MODX API и работающий на индивидуальной реализации ExtJS, создает новые возможности для разработчиков MODX быстро разрабатывать индивидуальные интерфейсы и дополнения. Разработчики могут создавать такие интерфейсы Менеджера, которые будут показывать только специальные поля и меню, необходимые для обычных редакторов сайта. Безопасность промышленного уровня, модели пользователей и аутентификация Характеристики на основе списка управления доступом (ABAC, Attribute Based Access Control) позволяет администраторам сайтов детально разграничить доступ к сайтам на MODX Revolution. Аутентификация может производиться через встроенную систему пользователей, службу каталогов Active Directory, LDAP, OpenID или в сущности через любую другую систему, которая может использовать MODX API. Прекрасная интернационализация и локализация MODX Revolution предоставляет множество подходов для работы с мультиязычными сайтами. Среди них обязательно имеется подходящий вариант почти для любого сайта. Культуры и контексты могут работать вместе, создавая детальные настройки интернационализации внутри фреймворка. Это позволяет разработчикам определить язык, валюту и формат даты, а также еще что-либо, что может быть нужно локализовать в разработке. Объектно-ориентированное ядро и API Переписанная CMS с нуля при использовании xPDO система MODX позволяет легко работать со специальными источниками данных, даже с несколькими разными типами баз данных. Сочетание полностью объектно-ориентированным API с последовательной архитектурой работа с MODX делает программистов просто счастливыми. Контексты Системные настройки MODX с помощью контекстов могут быть перезаписаны, расширены, изолированы или разделены между доменами, поддоменами, подсайтами, несколькими сайтами, специфическими языковыми разделами, различными веб приложениями и т.д. Расширяемое кеширование Новое ядро и техника кеширования на уровне частей веб-страницы позволяют уменьшить общий размер кеша одновременно с уменьшением нагрузки сервера путем организации файлов кеша в иерархическую структуру директорий. Новое ядро MODX также позволяет сохранять результаты запросов базы данных в файл, память (при использовании memcached) или в индивидуальную систему кеширования. Это приводит к уменьшению нагрузки на базу данных и расширению возможностей для комфортной работы с высоконагруженными сайтами. Фильтрация контента Любой элемент MODX (TV, Content, Chunk, Placeholder) может иметь сложную систему пре- и постобработки, примененной через фильтры ввода и вывода. Например, вы можете использовать их для обрезки части текста, форматирования даты, математических вычислений или чего-либо еще, что вы могли бы придумать с маленьким кусочком кода. Парсер контента с частичным кешированием страницы MODX предоставляет полностью рекурсивный парсер. Любой элемент MODX, включая сниппеты, чанки, переменные шаблонов (TV) и плейсхолдеры могут быть сделаны некешируемыми для частичного кеширования страницы. Расширения без изменений ядра Объектно-ориентированное ядро MODX позволяет вам создавать свои собственные индивидуальные реализации множества возможностей ядра без изменений кода ядра. Это помогает защитить разработку и гарантирует возможность обновления в будущем. Переопределяйте все! В MODX вас никто не заставляет разрабатывать только в одном единственно возможном стиле. Если у вас есть специфические требования, вы можете использовать индивидуальную программу работы MODX путем расширения классов ядра. Это включает в себя парсер контента, обработку запросов и ответов, сессии, обработку ошибок, частичное кеширование страниц и кеширование результатов запросов базы данных. Родные JSON и очередь сообщений MODX включает и использует родную обработку JSON для взаимодействия с другими системами с помощью архитектуры REST. Простая встроенная очередь сообщений позволяет реализовать публикацию сообщений и подписку на передачу сообщений для продуманного взаимодействия с внешними системами в промышленных приложениях. Сессии, управляемые базами данных Параметры конфигурации обработчика сессий реализуют совместимость с системами кластеризации веб-серверов. Журналирование ядра Система предоставляет различные уровни ошибок и выводимых данных, включая ECHO, HTML и FILE. Разработчики используют эту функциональность для журналов аудита, аудита ошибок, отладки или других целей.

modx.ru

Разработка и поддержка на MODx - почему MODx Evo и MODx Revo для разработки сложных корпоративных сайтов

MODx - система для управления сайтами с открытым исходным кодом. Мы используем её для разработки больших и сложных корпоративных сайтов.

Чем разработка на MODx отличается от других CMS

Хотя эту систему часто ставят в один ряд с другими популярными CMS - Wordpress, Joomla, Drupal - это не совсем правильно. Разработка на MODx принципиально отличается от разработки на Wordpress и Joomla. Пр своей идеологии и архитектуре MODx - CMF - content management framework (фреймворк по управлению контентом), и в этом он схож с Drupal, тогда как Wordpress и Joomla - CMS - content management system (система по управлению контентом). 

В чем же разница и почему мы выбираем MODx для разработки сложных корпоративных сайтов для клиентов как в Киеве, Украине так и далеко за её пределами?

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

При всём при этом MODx, особенно версия MODx Evo практически не накладывает ограничений на стиль кодирования и использование API самого MODx. Вы можете портировать под MODx любую библиотеку которая вам нужна. MODx Revo в этом отношении более строгий и требуется больше знаний (xPDO, ExtJS и др.) но при этом разработка на MODx Revo гораздо более гибкая.

Верстка как под MODx Revolution, так и под MODx Evolution практически не отличается и не доставляет неудобств и не заставляет разработчика каким-то специальным образом компоновать шаблон. Поэтому на MODx можно сделать очень разные по уровню проекты.

Применение и возможности MODx разработки

Как Evergreen рекомендует использовать MODx для разработки различных по типу сайтов:

Разрабатывая сайты на MODx важно понимать несколько ограничений этой системы: 

Если вас заинтересовали преимущества MODx и вы понимаете его ограничения, пишите нам на [email protected] и мы расскажем о разработке сайтов и порталов на MODx всё что вы захотите узнать.

Техподдержка сайтов на MODx

Благодаря модульной системе и гибкой архитектуры сайты на MODx можно поддерживать и "выращивать" большие технические сложные проекты. При этом со временем техподдержка на MODx не превращается в тихий ад как на многих других системах. MODx гибко адаптируется к выбранному стилю разработки (CMS-стилю или Framework-стилю) и позволяет сохранять проект простым для администрирования. Смотрите подробнее о поддержке сайтов.

Технические преимущества разработки на MODx

Если всё описанное выше в целом понятно, постараемся описать почему мы считаем MODx разработку технически более совершенной чем разработку на ряде других CMS.

Итак, во-первых это система разделения кода на шаблоны, чанки и сниппеты. В шаблонах хранится струтура страницы или блока, в чанках – части повторяющегося HTML-кода, а в сниппетах – php код. В рамках MVC-подхода, чанки и шаблоны отвечают за представления (view), а сниппеты за контроллеры. 

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

Далее используя компонент MIGX (MODx Revo) или API самого MODx можно очень быстро разработать новые компоненты для MODx и разделить страницы сайта и управление другими сущностями, например товарами или поставщиками. В других CMS вам обычно приходится заводить эти сущности как страницы сайта, что не правильно, потому что снижается нагрузочная способность сайта. В MODx вы заводите их как отдельную сущность, которая хранится в отдельной таблице в базе данных.

Также MODx очень удобен как админ-панель. На самом деле вы можете написать клиентскую часть сайта на чем угодно, например на laravel, а modx использовать только как админку, таким образом сделать highload проект на MODx.

Если вы технический специалист, и вам интересны нестандартные возможности MODx – не стесняйтесь связываться с нами, мы будем рады ответить вам.

Почему с Evergreen стоит разработать и поддерживать сайт на MODx как клиентам из Киева, Украины, так из СНГ?

По рейтингу CMSMagazine мы занимаем второе место в Киеве среди разработчиков MODx. По Рейтингу Рунета мы занимаем 4 место в СНГ среди разработчиков MODx в верхнем ценовом сегменте. 

04.09.2016

Рейтинг: 0 / 5 (0)

evergreens.com.ua

Prostoy-Site | Все права защищены © 2018 | Карта сайта