Привіт, шановні читачі блогу LifeExample. сьогодні я б хотів торкнутися теми, з якої варто було б починати цикл статей про розробку інтернет магазину. Говорити ми будемо про процес створення CMS на етапі проектування.
Що повинна вміти CMS, для того щоб називатися такою, і в який момент движок сайту, або міні фреймворк переростає в систему управління контентом.
Процес створення CMS на етапі проектування визначає завдання, за планом яких будь-яка CMS повинна:
- Мати свій установник;
- Оновлюватися, не чіпаючи призначені для користувача файли. Тобто оновлювати тільки ядро;
- Підтримувати використання плагінів;
- Мати можливість кешування сторінок;
- Зберігати резервні копії БД;
- Підтримувати шаблонізаціі;
Цей перелік - основа завдань для будь-якої створеної для користувачів системи управління контентом.
Звичайно, якщо ви займаєтеся розробкою продуктів, верстальником, дизайнером, користувачем та адміністратором в одній особі, то вище перераховані вимоги можуть виконуватися вами в ручному режимі.
У разі коли створеної CMS 'який хоче користуватися людина, що не має поняття навіть про HTML, все це повинно бути!
установник CMS
Під монтажником будемо розуміти скрипт або набір скриптів, відповідальних за перший крок на шляху до використання готового продукту, а саме за установку і настройку файлів системи необхідних для функціонування CMS.
Для установки будь-якої системи, як правило, отримавши готовий набір файлів в запакованому вигляді, що представляють собою CMS, користувач розпаковує його вміст на віддалений хостинг.
Серед розпакованих файлів при першому запуску системи повинен знаходитися каталог містить скрипти для установки, зазвичай він іменується - instal.
Після розпакування архіву, при зверненні до сайту користувач вже має отримувати робочу середу, а не набір неадекватних помилок кричущих про неможливі підключитися до БД або про відсутність того чи іншого модуля на сервері.
Іншими словами при першому запуску користувач повинен потрапляти в середу установки CMS, фізично знаходиться в каталозі install.
Ось блок схема алгоритму першого запуску:
Як бачите спочатку за планом настройка файлу конфігурації, потім видалення установника, і запуск.
підтримка плагінів
Тут все трохи складніше ніж з монтажником, і необхідно чітко спроектувати систему для підтримки плагінів. У найпростішому випадку плагіном може бути клас успадкований властивості і методи батьківського класу Plagin.
Сам клас Plagin повинен знаходитися в ядрі системи, і мати можливість оновлюватися з виходом нових версій. Це необхідно для нарощування функціоналу системи в подальшому.
У разі по складніше, наприклад, при використанні архітектури MVC плагіном може бути набір файлів, а може бути і каталогів.
оновлення системи
Нещодавно зіткнувся з завданням оновити сайт замовника створений на одній що розвивається CMS. Сайт пропустив останні два оновлення системи, і вже потребував хорошого апгрейде.
Прочитавши керівництво до оновлення версій ядра, я був трохи збентежений необхідністю послідовного оновлення. Потрібно було виконати оновлення в такому порядку v1.5 -> v1.6 -> v1.7. причому все це було в напівавтоматичному режимі з використанням декількох інтерфейсів і заміни файлів поточної версії вручну.
На мій погляд при створенні CMS, процес оновлення повинен бути основоположним і відбуватися повністю автоматично - безпосередньо з панелі адміністрування шляхом натискання на відповідну кнопку "Оновити до останньої версії".
Для того щоб це стало можливим, знову таки потрібно чітко продумати архітектуру програми і структуру каталогів.
Я думаю буде зручно винести в окремий каталог, ті файл які можуть оновлюватися в майбутньому, і яким користувачам краще не торкатися.
Кешування сторінок і підтримка шаблонізаціі
Дуже корисна властивість збереження динамічних даних в статичному вигляді. Воно істотно скоротить використання ресурсів сервера і прискорить роботу сайту. Для кешування сторінок можна звернутися наприклад до шаблонизатор SMARTY. який зручний в іспользозованіі і чітко відокремлює бізнес логіку від шаблону сторінок, а також має можливість кешувати дані.
Але якщо ми створюємо свою CMS та ще й за правилами MVC. то це передбачає. що вся логіка у нас вже відокремлена від уявлення, а відповідно ніякої сторонній шаблонизатор не потрібен.
Все що буде, досить це написати свій механізм кешування використовуючи стандартні PHP механізми управління виводу.
Збереження резервних копій БД
За підтримки та розвитку сайту створеного на будь-який CMS, буває надзвичайно важливим вести щоденне збереження резервних копій бази даних.
Найчастіше вбудованих механізмів автоматичного дампа бази в CMS можна годі й шукати. Взяти навіть всіма улюблений WordPress, він як не можна краще підходить під цей приклад, але ситуацію виправляють плагіни розроблені спеціально для ведення бекапів бази.
Це ще раз доводить необхідність в підтримці плагінів, які часом можуть значно доповнити функціонал системи.
Створення CMS вимагає великих зусиль і яскраво вираженою мотивації, часто перекриває процес якісного етапу проектування прагненням швидше почати робити функціонал.
Як би вам не хотілося швидше почати, і ще швидше завершити створення CMS. не забувайте, що етап проектування будь-якої системи - основний і самий головний. Приділяйте йому максимально допустиму кількість часу і зможете дійти до кінця, не склавши руки при зіткненні з завданням ламає всю архітектуру програми.
