Реліз FFCMS 3.0.0 — нова перероблена система

Доброго часу доби мешканець habrahabr, сьогодні я хочу тобі розповісти про новий релізі ffcms — 3.0.0 і коротко висвітлити кардинальні зміни, які зазнала система з моменту попереднього релізу — 2.0.4.

Система зберегла безкоштовну модель розповсюдження і відкритий вихідний код (MIT), але вихідний код був повністю переписаний під MVC архітектуру і автозавантаження PSR-0. Багато «велосипеди» були прибрані з системи, а їх місце зайняли популярні компоненти: symfony http foundation, laravel eloquent і багато інших.


Переробка архітектури системи
Обговорюючи 2ую версію системи багато користувачів habrahabr радили істотно переробити систему з урахуванням сучасних тенденцій: додати менеджер залежностей і версій composer, ввести усталену MVC архітектуру і привести код до єдиного PSR-1/2 стилю. Код 2ой версії дійсно мав досить низьку якість і про нього можна було зламати ногу (а то й обидві). Так само було відмічено, що модель розробки розширень 2ой версії є дуже заплутаною і надлишковою, а разом з синтаксисом api ядра у деяких користувачів це викликало душевний біль.

Впровадити сучасні інструменти та принципи розробки додатків було просто необхідно, проте переписувати існуючий код було практично нереально — тому було ухвалено рішення переробити архітектуру системи «з нуля».

Система була розділена на кілька функціональних частин: базова структура, ядро, консоль. Для кожної частини був створений репозиторій, налаштований composer і проект був опублікований на packagist. Всі частини зв'язуються за допомогою залежностей в composer.json базового компонента.

Відмова від велосипедів
За останні роки розробки додатків я познайомився з більшістю популярних фреймворків, такими як symfony, laravel, yii і codeigniter. Більшість «ідей взаємодій», які я намагався самостійно реалізувати у своїй CMS, як не дивно, вже були реалізовані в популярних фреймворках — де то вони монстроподібно складні, де то — надто прості і недостатньо функціональні. Багато з них мені сподобалися і я використовую їх донині, запровадивши в ffcms.

Отже, такі власні частини «велосипеда» були замінені на вже усталені популярні компоненти:

  • Робота з мережею (Networking): symfony http foundation
  • Робота з базою даних (DB manager): laravel eloquent
  • Безпека HTML коду HTML purifier
  • Робота з консоллю: symfony console
  • Ядро кешування (Caching): php fast cache
  • Налагодження (Debugging): debugBar
  • Робота з поштою (Mailer): swiftmailer
  • oAuth 2.0 авторизація: hybridauth
Для деяких з використовуваних компонентів були написані «нащадки», що розширюють або спрощують функціональні можливості компонента для потреб системи. Використання даних компонентів дозволило досить спростити базове ядро системи і знизити поріг входження для інших розробників.

Продуктивність і сумісність
А не ввести чи нам підтримку php 5.2 і не юзнуть чи polyfill? Ні, ні і ще раз ні. Зараз, на хвилі виходу php 7.1 і руху до deprecated 5.5 немає абсолютно ніякого сенсу підтримувати застарілі версії php. Спокуса використовувати polyfill, звичайно, великий, але і від нього можна відмовитися щоб не ускладнювати і без того непросту систему.

FFCMS 3 буде працювати на будь-якому інтерпретатор php починаючи з версії 5.5, в зв'язці nginx — php-fpm, apache2 — php або будь-якими іншими зв'язками (за умови переписания правил перезапису uri).

Продуктивність системи суттєво не постраждала, хоча витрата ресурсів став трохи більшим, ніж у 2-ій версії (воно й не дивно), але все ж до рівня bitrix дотягнути не вдалося. Завантаження сторінки так само < 0.1 сек, споживання пам'яті — < 7mb (для php 5.6 без opcache). Останній performance тест можна знайти на google.docs разом з тестовим контейнером під virtualbox.

Шаблонизация (або голий php?)
В даному спорі бійці зламали чимало списів, але єдиної думки в питанні немає. Багато хто вважає, що самого синтаксису php цілком достатньо для шаблонізації, а деякі без twig і blade не бачать свого життя. У 2-ій версії системи використовувався twig, але мною було прийнято рішення обмежитися класичним php синтаксисом для генерації html коду в уявленнях.

Трошки коду для досвідчених
// екшен контролера:
public function actionIndex()
{
// blablabla
return $this- > view- > render('dir/file', [
'param' => 'my value'
]);
}
// в'юшка
<h1>Demo view</h1>
<p>param value is: <?= $param ?>


З UI залишилося все як і раніше — jquery & bootstrap цілком перевірена часом зв'язка.

БД, запити і ActiveRecords
Для взаємодії з базою даних в рамках PHP існує безліч різних шляхів. Хтось працює з голим PDO, хто то з Doctrine і QueryBuilder'ами. У FFCMS використовується бібліотека laravel eloquent, яка дозволяє взаємодіяти з базою даних по засобам складальника запитів (Query builder) а так само за допомогою підходу ActiveRecords.

ActiveRecords дуже зручні для роботи з БД і істотно спрощує і скорочує синтаксис запитів. Звичайно, це не повноцінний ORM рівня Doctrine, однак для цілей CMS його цілком достатньо.

Міграції
Без міграцій та їх подальшого «деплоя» зараз нікуди. Ні, є звичайно ж люди використовують mysqldump/pg_dump але ми не будемо йти цим шляхом. У ffcms 3 присутня стандартна реалізація міграцій — класи з 3мя методами up(), seed() і down(), можливість створення, застосування і відкату міграцій. Стандартні міграції зберігаються в /Private/Migrations, але за допомогою MigrationsManager можуть бути імплементовані міграції з будь-яких директорій.

Налагодження
Для зручності швидкого налагодження і профілювання запитів в ffcms вбудований функціонал phpdebugbar. Даний механізм дозволяє виконувати налагодження «на швидку руку», коли немає можливості або часу на підключення xdebug/zenddebug. Відладчик виглядає у вигляді панелі і доступний для включення у налаштуваннях адмін панелі.

Картинка з debugbar

Тестування
Тестування працездатності продукту вручну не є тенденцією сучасної розробки. Для цілей автоматичного тестування коду системи та UI була впроваджена система автоматичних тестів — codeception, яка поєднує в собі стандартний unit-тестування і acceptance тестування інтерфейсів.

Тести можна запустити з кореня за допомогою команди codecept run, попередньо запустивши selenium з драйвером для chrome чи іншого браузера. Так само необхідно відредагувати конфіг тестового оточення (/tests/acceptance.suite.yml) під вашу прошарок. Для налаштування тестів є невеликий документ з інструкціями до застосування (документ не був спочатку призначений для «всіх око», вже вибачте).

Мотивуюча gif-ка з виконанням тестів (5Mb!!!)

Розширення
Через наявність PSR-0 автозавантаження система розширень була переглянута. Зараз всі розширення розділені на 2 типи — додатки і віджети, перші — займають певний кореневої URI в залежності від контролера і за допомогою actions обробляють ті чи інші запити; другі — призначені для відображення в якомусь місці уявлень шляхом прямого звернення до класу віджета.

Крім того, весь набір «реалізацій» може бути загорнутий в один пакет і за допомогою git-а і composer-а дотримуючись стандарт автозавантаження може поширюватись як самодостатня реалізація. Яскравим прикладом є реалізація форуму або демо-пакет.

Що ж, мій розповідь достатньо затягнувся, але мабуть в одну статтю все вмістити неможливо. Буду радий відповісти на ваші запитання, вислухати ваші побажання.

→ Офіційний сайт: ffcms.org (дзеркало: ffcms.ru
→ Проект на github: phpffcms
→ Документація адміністратора та розробника: doc.ffcms.ru (в процесі доопрацювання).
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.