Статьи

Покращуємо процеси розробки в Modx Revo: робота з git, Деплой з gulp, тестові оточення

  1. Детальніше про те, що нас не влаштовує в Modx
  2. Основна ідея цього оповідання
  3. Структура проекту Modx Revo.
  4. Питання: а як створювати чанкі, шаблони і сніппети
  5. Відключення кешування в Modx
  6. Git і Modx
  7. Деплой сайту по ftp за допомогою gulp
  8. Налаштування різних оточень в Modx.
  9. підводимо підсумки

Давно не писав статті про мою улюблену CMS Modx Revo, а даремно. Яндекс.Метрика переконливо говорить, що статті на цю тему користуються великою популярністю у відвідувачів блогу. Сьогодні цю прогалину частково виправлю і хочу поговорити ось про що. На жаль чи на щастя, однією з головних фішок Modx є той факт, що практично весь вміст сайту, включаючи, ресурси, шаблони, сніпети, чанкі і таке інше зберігається в mysql-базі. З цього випливають і плюси, і мінуси, але мені мінусів бачиться більше.
Основні претензії: робота з git в Modx, настройка робочого оточення, конфіги для бойових і тестових серверів, Деплой і вбудовані редактори коду
Отже, в цій статті я покажу, як я розбирався з цими пунктами, що вдалося зробити успішно і які моменти не вийшло реалізувати до кінця. Ласкаво просимо в статтю і коменти!


Детальніше про те, що нас не влаштовує в Modx

Головний мінус - це незрозумілість, а хтось стверджує, що і неможливість подружити цю cms з будь-якою системою контролю версій. У cms тупо немає "девелоперських" файлів - все в таблицях БД! Не знаю, як іншим modx-колегам, але мені зовсім не хочеться вести розробку без звичного git-а. Скільки я не Яндекс по інтернету, так і не знайшов адекватного опису, як працювати з git в Modx.
Друга проблема - це незручність деплоя на тестовий або бойової сайт. Ви можете сказати, що можна кожен раз робити дамп всієї бази і заливати її через умовний phpMyAdmin, а після копіювати все папки-файли цілком по ftp, але задоволення досить сумнівне. Перший раз це все одно доведеться робити, але для послерелізних дрібних правок не хочеться возитися з дампами бази, а хочеться зробити щось на зразок gulp deploy з командного рядка і перезаліть сайт без оновлення бази.
Третя проблема, це вже мої особисті таргани, але Modx-ські редактори коду далекі від ідеалу. Щодо непоганий редактор коду Ace, не кажучи вже про передвстановленому редакторі коду, не дозволяє робити купу речей, до яких швидко звикаєш в улюбленому sublime або phpStorm.


Основна ідея цього оповідання

Робимо кожен елемент Modx статичним!
Так, саме так. Якщо git не йде до Modx, то нехай сам Modx йде до git.
Для тих, хто не в курсі: в Modx є можливість кожен елемент (шаблон, чанк, сниппет) зробити статичним. Це означає, що вміст цього елементу зберігається в зовнішньому файлі, а не в таблицях БД. У налаштуваннях є скромна галочка Статичний, включення якої дозволяє вибрати файл для зберігання коду цього елементу.
Я не знаю, навіщо розробники Modx ввели цю штуку, але саме їй ми скористаємося для організації дружби з git (хм, а може, для цього і ввели творці Modx статичні елементи? ..)

Отже, ідея озвучена, тепер докладніше, як ми її будемо реалізовувати і що з цього вийде.


Структура проекту Modx Revo.

Припустимо, ми створюємо сайт webdevkin.ru.

Перше: після установки Modx в корені проекту крім стандартних папок assets, core, connectors і manager створюємо папку modx. Це нехитре назва говорить нам, що саме в ній ми будемо зберігати код для шаблонів, чанкі і сніпетів. А в папці modx створимо ще 3 татка: templates, chunks і snippets. Щоб не звалювати файли в одну купу. Також в корені заведемо папку scripts, де будемо зберігати зовнішні php-файли. Думаю, практично на кожному сайті парочка таких php-скриптів та є. Вони потихеньку сіпаються з клієнта Аяксом і роблять щось корисне, наприклад, відправляють повідомлення власнику сайту з форми зворотного зв'язку.

Друге: створюємо в каталозі assets папку templates, а в ній папку webdevkin. webdevkin - це назва шаблону для нашого сайту. У webdevkin лежать такі папки: css, js, fonts, img. Призначення їх, думаю, зрозуміло. Таким чином, вся статика для сайту лежить в одному місці - в папці assets / templates / webdevkin


Питання: а як створювати чанкі, шаблони і сніппети

Відповідь: створюємо як зазвичай, в адмінці Modx. Після створення відзначаємо галочку Статичний і вибираємо файл, в якому буде зберігатися вміст елемента. Не забуваємо, для складу цих файлів ми і створили папку Modx. Я віддаю перевагу для чанкі і шаблонів створювати файли .tpl, для фрагментів .php. Як зручно, так і робіть, хоч зберігайте в .txt все підряд. Після створення файлу ми можемо працювати з ним не в адмінці Modx, а в звичному редакторі коду.

По суті, основна ідея вже розписана, базова структура проекту у нас створена, як створюються елементи, розібрали. Далі підуть деталі. Але перш ніж перейти до налаштування git, розглянемо такий невеликий момент, як кешування.


Відключення кешування в Modx

Про проблеми кешування розказано вже багато і всім, кому не лінь. Навіть на нашому сайті є стаття про кешування в Modx Revo .

Як зачіпає кешування нас саме зараз? Коли ми пишемо код якогось елементу в адмінці Modx і натискаємо Зберегти, то, як правило, кеш очищується і ми відразу можемо оновити сторінку і помилуватися результатом. Звичайно, якщо ми не зняли спеціально галочку Очистити кеш при збереженні. Якщо ж ми створюємо код по нашій схемі, то Modx не розуміє, в який момент ми зберігаємо сниппет в умовному sublime і відповідно, не очищає кеш. Ви оновлюєте сторінку і не бачите жодних змін: все взято з кешу, збереженого раніше. Як бути? Чи не лізти ж в адмінку Modx вручну очищати кеш після кожної правки якогось чанка? Ні, не для такого ми все це замутили.
Потрібно просто відключити кешування ресурсів в Modx на час розробки.
Важливо: тільки на час розробки!
Залишити сайт на Modx працювати без кешування - це страх і жах, modx-товариші, вважаю, добре розуміють, про що мова :-)
Найпростіший і надійний спосіб тимчасово відключити кешування за допомогою гугла знайшовся такий:

  • 1. Створюємо плагін DisableCache
  • 2. Додаємо в нього такий кодік
global $ modx; $ Modx-> documentObject [ "cacheable"] = 0;
  • 3. Вішаємо цей плагін на подію OnLoadWebDocument
  • 4. Profit!
    • Тепер кожен раз документ буде рендери заново, що не залазячи в кеш - то, що нам і потрібно.

    Git і Modx

    Я не буду розповідати, як встановити git, як провести ініціалізацію та інше - це тема для окремої статті (втім, ось вона ). Думаю, соратники по сайтобудівництва, звичні до Гіту, добре уявляють, що потрібно робити, але одну цікаву річ коштує показати: файлик .gitignore саме для Modx.

    /.idea /webdevkin.sublime-project /webdevkin.sublime-workspace / node_modules components / connectors / core / manager / setup custom.log error.log

    Розбираємо: .idea і .sublime- * - службові файли редакторів phpStorm і sublime (працюю і з тим, і іншим) node_modules - папка для npm-модулів, як мінімум, модуль для деплоя, розберемо трохи пізніше. Далі йдуть 5 службових папок Modx. components вказуємо без /, тому як на увазі папку / assets / components / І 2 файли з балками, хоча можна і закинути їх в папку logs.

    Таким чином, при цій системі ми ігноруємо всі зміни в службових файлах Modx і відстежуємо зміни в "робочих" файлах, тобто тих, які ми створюємо безпосередньо в процесі розробки.

    Я привів найпростіший варіант, коли стандартної поставки Modx цілком вистачає для розробки, нам не потрібно створювати ніяких додаткових файли і папки. У реальному житті структура проекту найчастіше разветвленнее, але Ви напевно по цьому прикладу зможете налаштувати .gitignore під свої потреби.


    Деплой сайту по ftp за допомогою gulp

    Тепер, коли ми позбулися зберігання наших программистких кодів-скриптів в базі і винесли це добро в зовнішні файли, ми можемо приступати до Деплой сайту. Звичайно, можна руками копіювати файли через будь-який ftp-клієнт, а можна налаштувати плагін, наприклад, gulp для роботи з ftp. Основи gulp розберемо в одній з наступних статей, а поки будемо вважати, що читач знайомий з системами збирання або має бажання самостійно оволодіти будь-який з них.

    UPDATED: якщо Ви цікавитеся, що можна хорошого зробити з gulp ще, пропоную ознайомитися зі статтею Збірка додатки Backbone + Require.js за допомогою gulp

    Для настройки завдання деплоя нам знадобляться наступні модулі: сам gulp, gulp-util (де він тільки не потрібний) і, головне, vinyl-ftp. Вміст gulpfile.js таке (ми розглядаємо тільки одну задачу деплоя нашого сайту на бойовий сервер)

    'Use strict'; var gulp = require ( 'gulp'), gutil = require ( 'gulp-util'), ftp = require ( 'vinyl-ftp'); // Файли для копіювання по ftp var globs = [ 'assets / templates / webdevkin /**/*.*', 'scripts / ** / *. Php', 'modx /**/*.*']; // Шляхи, якими ftp function getConn () {return ftp.create ({host: '111.222.333.444', user: 'ftp_user', pass: 'ftp_pass'}); } Gulp.task ( 'deploy', function () {var conn = getConn (); return gulp.src (globs, {base: '.', Buffer: false}) .pipe (conn.dest ( '/ path_to_your_files' )) .pipe (gutil.noop ());});

    Детальніше.
    На початку ми підключаємо 3 потрібних для роботи модуля. Далі вказуємо в масиві, що ми хочемо заливати на бойовий сайт.

    • 1. Статика (css, js, img, fonts)
    • 2. Скрипти php, якщо вони у вас є, звичайно
    • 3. Чанкі, шаблони, сніпети з папки modx
    Функція getConn () створює з'єднання з ftp-сервером, вказуєте в параметрах налаштування Вашого ftp. Завдання "deploy" виконує саме копіювання файлів.
    Якщо все налаштовано правильно, починаючи з установки самого gulp, то по запуску gulp deploy з командного рядка в корені проекту на Ваш бойовий сайт скопійовано все потрібні файли. І більше не потрібно буде створювати дамп локальної бази, заходити в phpMyAdmin бойового сайту і відновлювати всю базу заради правки трьох шаблонів. Єдино, потрібно пам'ятати про кеші і скидати його кожен раз після процедури деплоя. Можна робити це в адмінці Modx бойового сайту, особисто мене не напружує, або покопатися в плагінах того ж gulp - напевно є плагін, що дозволяє очищати кеш Modx, а саме вміст папки core / cache. У Вас є якісь ідеї з цього приводу? Із задоволенням почитаю в коментарях.

    Налаштування різних оточень в Modx.

    Що я маю на увазі під цією гучною фразою?
    Найчастіше в розробці на Modx ми маємо справу як мінімум з двома середовищами - локальна машина і хостинг клієнта, тобто бойової сайт. Кожен раз при заливці файлів на сайт і копіювання назад на свій комп'ютер потрібно не забувати міняти в конфігах настройки доступу до mysql, а також шляхи до кореневої папці проекту. На хостингу це виглядає приблизно як /home/user1234/site.ru/www/, на своєму комп'ютері - c: /projects/www/site.ru/ І відповідно, настройки БД теж різні. І це в простому випадку, якщо ми деплоім з локального середовища відразу на робочий сайт. Також доводиться попередньо перевіряти функціонал на тестовому сервері, настройки якого знову-таки відрізняються від вищенаведених.
    Звичайно, можна один раз створити 3 варіанти файлів налаштувань для всіх оточень, розмістити їх на кожному з іспльзуемих серверів і копіювати файли сайту тільки нашим способом, який ми розібрали вище. Але іноді все-таки доводиться пере сайт цілком і потрібно кожного разу не забувати міняти все 4 файлу конфіга:

    • /config.core.php
    • /manager/config.core.php
    • /connectors/config.core.php
    • /core/config/config.inc.php

    Звичайно, можна з цим жити, але іноді стає досить сумно. Хочеться налаштувати ці злощасні параметри тільки один раз і згадувати тільки тоді, коли нам потрібно буде зробити ще одну тестову площадку. Наприклад, до роботи над проектом приєднується Ваш колега, на робочій машині якого свої настройки бази.

    Подивимося на перші 3 файлу. Практично у всіх вони збігаються до єдиного пропуску - в них вказується шлях до ядра Modx, приблизно так

    define ( 'MODX_CORE_PATH', 'c: /www/site.ru/core/'); define ( 'MODX_CONFIG_KEY', 'config');

    До речі, буду дуже вдячний читачам, якщо підкажете нерозумному, з яких причин був взагалі створений цей файл та ще й скопіпащен в трьох примірниках. Якщо Вам потрібно в константі MODX_CORE_PATH вказати шлях до папки core, то можна це зробити і так

    $ RootPath = $ _SERVER [ 'DOCUMENT_ROOT']; if ($ rootPath [strlen ($ rootPath) - 1]! = '/') {$ rootPath = $ rootPath. '/'; } Define ( 'MODX_CORE_PATH', $ rootPath. 'Core /'); define ( 'MODX_CONFIG_KEY', 'config');

    Що змінилося? Та нічого, крім того, що ми не прописуємо шлях до кореня проекту руками, а витягуємо його з змінної $ _SERVER [ 'DOCUMENT_ROOT']. Умова з додаванням слеша в кінець шляху додано на всякий випадок. Деякі веб-сервери додають цей слеш, деякі ні (стикався з таким пару раз). А нам цей слеш категорично потрібен для правильного формування повного шляху до core /

    Таким чином, замінивши вміст всіх трьох файлів config.core.php на вищенаведений код, нам стає абсолютно по барабану, на якому хостингу або машині розташовується наш проект. Шлях до папки core завжди буде визначатися точно.

    А тепер давайте подивимося на більш цікавий файл core / config / config.inc.php Там крім купи шляхів до різних папках і хостам містяться настройки до бази даних. Виглядає це приблизно так:

    / ** * MODX Configuration file * / $ database_type = 'mysql'; $ Database_server = 'localhost'; $ Database_user = 'user_siteru'; $ Database_password = 'password_siteru'; $ Database_connection_charset = 'utf8'; $ Dbase = 'db_siteru'; $ Table_prefix = 'modx_'; $ Database_dsn = 'mysql: host = localhost; dbname = db_siteru; charset = utf8'; ... if (! Defined ( 'MODX_CORE_PATH')) {$ modx_core_path = '/home/site.ru/public_html/core/'; define ( 'MODX_CORE_PATH', $ modx_core_path); } ... // Тут ще десяток аналогічних умов

    І кожен раз при Деплой всіх файлів сайту доводиться шерстити цей конфіг і міняти в ньому все настройки під поточне оточення. Звичайно, питання уважності, але не всі програмісти роботи, можуть і помилитися в одній букві і довго розбиратися, чому сайт відмовляється працювати. Особливо весело буває у випадках розгортання проекту на site.ru і test.site.ru. Часто доступ до бази один і той же, а ось назва самої бази, природно, різниться. При частих деплоях забути про це зовсім не дивно. Як же це виправити?

    Нам потрібен спосіб визначати поточне оточення розробки: локальний комп'ютер, тестовий сервер і бойової сайт. Найпростіше, що спадає на думку - це визначати оточення через той же $ _SERVER [ 'DOCUMENT_ROOT']. Наприклад, на локальному комп'ютері шлях включає в себе projects / www / site, на бойовому - siteru / public_html, а на тестовому - siteru / test. Подивимося на код:

    / ** * MODX Configuration file * / // Якщо константи не визначені, то задаємо їх // Перевірка на наявність константи важлива, так як файл конфіга може підключатися кілька разів if (! Defined ( 'CONFIG_DBSERVER')) {// Визначаємо оточення $ env = 0; // за замовчуванням локальне оточення site.lc if (strpos ($ _ SERVER [ 'DOCUMENT_ROOT'], 'siteru / public_html')! == false) {$ env = 1; // бойової сайт site.ru} if (strpos ($ _ SERVER [ 'DOCUMENT_ROOT'], 'siteru / test')! == false) {$ env = 2; // тестовий сервер test.site.ru} // Налаштування для локального оточення if ($ env === 0) {DEFINE ( ​​'CONFIG_DBSERVER', 'localhost'); DEFINE ( ​​'CONFIG_DBUSER', 'root'); DEFINE ( ​​'CONFIG_DBPASSWORD', 'root'); DEFINE ( ​​'CONFIG_DBNAME', 'siteru'); DEFINE ( ​​'CONFIG_PATH', 'C: / projects / www / site /'); DEFINE ( ​​'CONFIG_HOST', 'site.lc'); } // Налаштування для бойового сайту if ($ env === 1) {DEFINE ( ​​'CONFIG_DBSERVER', '111.222.333.444'); DEFINE ( ​​'CONFIG_DBUSER', 'user_siteru'); DEFINE ( ​​'CONFIG_DBPASSWORD', 'password_siteru'); DEFINE ( ​​'CONFIG_DBNAME', 'db_siteru'); DEFINE ( ​​'CONFIG_PATH', '/ home / siteru / public_html /'); DEFINE ( ​​'CONFIG_HOST', 'site.ru'); } // Налаштування для тестового сайту test.site.ru if ($ env === 2) {DEFINE ( ​​'CONFIG_DBSERVER', '111.222.333.444'); DEFINE ( ​​'CONFIG_DBUSER', 'user_test_siteru'); DEFINE ( ​​'CONFIG_DBPASSWORD', 'password_test_siteru'); DEFINE ( ​​'CONFIG_DBNAME', 'db_test_siteru'); DEFINE ( ​​'CONFIG_PATH', '/ home / www / siteru / test /'); DEFINE ( ​​'CONFIG_HOST', 'test.site.ru'); }} $ Database_type = 'mysql'; $ Database_server = CONFIG_DBSERVER; $ Database_user = CONFIG_DBUSER; $ Database_password = CONFIG_DBPASSWORD; $ Database_connection_charset = 'utf8'; $ Dbase = CONFIG_DBNAME; $ Table_prefix = 'modx_'; $ Database_dsn = 'mysql: host ='. CONFIG_DBSERVER. '; Dbname ='. CONFIG_DBNAME. '; Charset = utf8'; // ... if (! Defined ( 'MODX_CORE_PATH')) {$ modx_core_path = CONFIG_PATH. 'Core /'; define ( 'MODX_CORE_PATH', $ modx_core_path); } // ...

    Як видно з коду, спочатку ми визначаємо настройки бази, хост і шлях до кореневої директорії, а потім використовуємо отримані дані для завдання констант Modx. Наведено тільки один приклад для MODX_CORE_PATH, інші задаються аналогічно. Спеціально не наводжу код всього файлу, так як настройки в різних версіях cms можуть відрізнятися. Використовуючи такий файл конфіга, ми легко можемо додавати нові оточення, хоч греблю гати пере сайти на бойові і тестові сервера з локальної машини і в зворотний бік, не боячись, що через неуважність забудемо поправити якусь настройку.


    підводимо підсумки

    Modx - цікава cms для розробки сайтів, як невеликих, так і досить великих і складних. Але принцип зберігання ресурсів, закладених в архітектурі, не дозволяє зручно працювати над проектом і поодинці, і особливо в команді. У статті я запропонував деякі прийоми, які виробилися у мене за час роботи з Modx. Розповів, як можна подружити cms з git, як налаштувати Деплой, як організувати роботу з різними оточеннями. У наведеній схемі є кілька моментів, які я поки не обійшов:

    • 1. Як спростити роботу з кешем? (Очищення кеша після деплоя)
    • 2. Головне питання: як створювати чанкі, шаблони і сніппети на всіх середовищах не вручну? Адже все одно ці елементи потрібно заводити в базі і створювати для кожного оточення руками. Незручність таке є, воно позначається при частому створенні нових елементів.
    • 3. Чи можна поліпшити визначення оточення, робити це не через $ _SERVER [ 'DOCUMENT_ROOT'], а якимось більш елегантним способом?
    У Вас є пропозиції з цього приводу або можете поділитися своїм досвідом облаштування роботи з Modx?
    Напишіть все, що думаєте, в коментарях!

    Як Вам стаття? Оцініть!

    Сподобалася стаття? Поділися з іншими!

    Підписка на нові статті

    Підписатися

    М, а може, для цього і ввели творці Modx статичні елементи?
    Як зачіпає кешування нас саме зараз?
    Як бути?
    Чи не лізти ж в адмінку Modx вручну очищати кеш після кожної правки якогось чанка?
    У Вас є якісь ідеї з цього приводу?
    Що я маю на увазі під цією гучною фразою?
    Як же це виправити?
    1. Як спростити роботу з кешем?
    2. Головне питання: як створювати чанкі, шаблони і сніппети на всіх середовищах не вручну?
    3. Чи можна поліпшити визначення оточення, робити це не через $ _SERVER [ 'DOCUMENT_ROOT'], а якимось більш елегантним способом?

    Новости