Огляд CMS WordPress та Drupal

58 переглядів

Вступ

Під час обговорення нових проектів часто виникає питання про вибір найбільш підхожої CMS. Щоб зробити правильний вибір, потрібно врахувати ряд важливих факторів, що стосуються проекту: вихідні вимоги, розміри проекту, швидкодію, можливості налагодження, рівень навичок адміністраторів CMS, дружній інтерфейс, а також фактори, які стосуються спрямованості проекту та його адміністрування.

Існує досить велика кількість статей про переваги і недоліки популярних CMS. З їх допомогою можна швидко зрозуміти, яку CMS вибрати, але всі вони більше стосуються призначеного для користувача інтерфейсу, доступних від початку можливостей, а також доступності фахівців на ринку і витрат на підтримку сайту. У даній статті хочеться змістити акцент у бік внутрішнього улаштування і зручності, а також складнощів при роботі з CMS з боку розробника.

Давайте розповім більш предметно про Wordpress і Drupal CMS, оскільки в цьому питанні я експерт.

Пропоную розглянути вибрані CMS за такими критеріями

  • Спільнота розробників
  • Зворотна сумісність
  • Поріг входження
  • Стандарти кодування
  • Зручність інтерфейсу
  • CMS/CMF
  • Оновлення та підтримка коду в актуальному стані
  • Стійкість до атак
  • Модульність і розширюваність
  • Робота з базою даних
  • Імплементація верстки

Спільнота розробників

Wordpress-спільнота широка. Можна навіть виділяти окремі сегменти, які працюють паралельно один з одним. Кожен з цих сегментів самодостатній, і часто можна знайти відповідь на одне і те ж питання різними мовами. Крім офіційного сайту з безкоштовною CMS і великою кількістю розширень (плагінів), є багато сайтів з модулями і темами. Існують навіть сайти, де можна скачати безкоштовно версії платних плагінів і тем. Велика частина "крутих" плагінів платна. Це не дивно, оскільки над створенням дійсно довелося попрацювати. Ціни частіше за все доступні, і куплений функціонал багаторазово перевершує те, що можна отримати, якщо найняти стороннього розробника.

Drupal-спільнота досить велика і здебільшого централізована. На офіційному сайті зібрані всі розширення, модулі і ядро CMS, які можна скачати безкоштовно. Кількість платних розширень і тем менша в порівнянні з Wordpress, і в цілому ціни теж менше.

Зворотна сумісність

Wordpress підтримує зворотну сумісність ядра і модулів у межах кількох попередніх версій. Якщо вийшла нова версія ядра, то, ймовірно, більшість модулів будуть працювати. Така ситуація дає як плюси, так і мінуси. З одного боку, можна встановити старий модуль, і він буде працювати, а з іншого боку, він може зламати сайт. Іноді для відновлення працездатності сайту потрібно користуватися FTP або панеллю адміністрування на сайті хостера.

Drupal не підтримує зворотну сумісність ядра і модулів, тобто модулі попередньої версії не підходять до поточної версії ядра. З одного боку, поломка сайту через установку модуля вкрай малоймовірна. Відсутність зворотної сумісності дозволяє переосмислити попередню реалізацію і виконати її з використанням прогресивних рішень. Але, з іншого боку, навіть якщо є модуль для даної версії ядра, то не факт, що він існує для наступної. Доведеться або чекати виходу модуля для нової версії, або шукати аналоги.

Поріг входження

Wordpress — проста система шаблонів, спочатку 12 таблиць в БД, відсутність специфічних вказівок щодо архітектури коду і жорсткої прив'язки в MVC концепції. Все це робить Wordpress простішою, і розібратися у ній легше, ніж у Drupal. А з урахуванням зворотної сумісності, знання CMS залишаються актуальними дуже довго. Але існує й інша сторона низького порогу входження. Вивчити Wordpress нескладно, і багато людей починають знайомство зі світом web саме з Wordpress. Як наслідок, страждає якість коду. На виході маємо величезну кількість проектів з кодом низької якості. На Wordpress дійсно можна писати круті проекти, в мережі є безліч прикладів.

Drupal має розвинену систему шаблонів різних рівнів, чи то сторінок, полів, блоків та ін. Спочатку 69 таблиць в БД, наявність вказівок як щодо найменування функцій і класів, так і щодо форматування коду. Підтримка стандартів PSR-4, що дає можливість використовувати розширення від Symfony і Zend Framework, а також вбудований шаблонізатор twig. Щоб почати працювати з Drupal, потрібно знати значно більше. Такий підхід відкриває нові можливості швидкості розробки, гнучкості налаштувань і масштабованості проекту. Водночас це не захищає від неякісного коду, хоча його відсоток у загальній кількості проектів значно нижче. Можливо, це також пов'язано з тим, що для людини, яка не займається web-розробкою, зробити що-небудь в коді Drupal складно.

Модульність і розширюваність

Wordpress-плагіни часто додають на сайт завершену частину функціоналу і є самодостатніми. Звичайно, це не стосується великих полігонів, які також можуть розширюватися і навіть мають свої hooks і плагіни, наприклад, WooCommerce. Але загалом ситуація така, що плагіни містять і логіку, і адміністративний інтерфейс, і виведення усього цього користувачеві.

Drupal-модулі часто мають дещо іншу архітектуру. Часто один модуль містить в собі кілька модулів, наприклад, сам функціонал, і UI до нього. І якщо UI-функціонал не потрібний, то і UI-модуль можна не включати. Також модуль може спиратися на функціонал іншого модуля, розширюючи або використовуючи його можливості. В цілому, залежність одного модуля від інших в Drupal зустрічається набагато частіше, ніж у Wordpress. Отримуємо своєрідне "лего", з якого можна зібрати те, що потрібно.

Стандарти кодування

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

Drupal має свої стандарти кодування, хоч вони і не є обов'язковими, але якщо є бажання поділитися своїми напрацюваннями з спільнотою, потрібно дотримуватися всіх стандартів. І навіть більше: доведеться пройти кілька перевірок свого коду членами спільноти, перш ніж його побачить світ. З іншого боку, Drupal має свою архітектуру програми для роботи з якою потрібно її розуміння. Архітектура програми теж змінюється від версії до версії, нехай і залишається впізнаваною. Це вимагає часу на вивчення змін та написання розширень за новими стандартами.

Зручність інтерфейсу

Wordpress має базовий однаковий інтерфейс для всіх сайтів. Його можна розширювати написанням коду або встановлюючи плагіни і теми. Але за стилістикою, як правило, це дуже впізнавана адмінка. І якщо у вас коли-небудь був сайт під керуванням Wordpress, вам не важко буде розібратися в адміністративній частині іншого сайту під управлінням Wordpress. Адміністративна тема добре адаптована під мобільні пристрої. Наприклад, текстовий редактор для desktop-версії відображається зверху над редагованим текстом, а для mobile-версії текстовий редактор відображається внизу, що дуже зручно.

Drupal має можливість вибору адміністративної теми для сайту. Одна тема може використовуватися як для адміністрування сайту, так і для відображення вмісту. Для адміністрування сайту годиться не будь-яка тема: щоб вона могла вважатися адміністративною, вона повинна забезпечувати стилями майже всі елементи на сайті, а це досить об'ємна задача. Тому таких тем мало. Як правило, більшість проектів зупиняються на одній з двох базових тем для адміністративної панелі або мінімально стилізують тему, яка і використовується для самого сайту. На перший погляд меню Drupal теж спочатку однакове для всіх сайтів. Тільки пунктів меню більше, ніж в Wordpress, але ситуація змінюється, коли встановлюється додатковий функціонал сайту. Меню управління сайту стає надмірним для адміністратора сайту і більше підходить для розробника. Потрібно відзначити, що є можливість розмежування доступа до меню як для розробника, так і для менеджера. І зробити це можна прямо з адміністративної панелі, але на це потрібно витратити якийсь час, оскільки система доступів (permissions) досить розвинена. Щодо мобільної версії, то адміністративні теми теж адаптовані під mobile. Але все ж админка не настільки продумана і зручна, як у Wordpress.

Оновлення, підтримка коду в актуальному стані

Wordpress має вбудований функціонал оновлення модулів і ядра. Але потрібно постійно робити резервні копії, оскільки часто буває, що після оновлення втрачається частина функціоналу, а при використанні плагінів низької якості іноді ламається навіть сам сайт.

Drupal має вбудований функціонал оновлення модулів, а ось ядро оновити з адмінки не вийде. Часто з Drupal використовуються допоміжні утиліти, такі як drush і composer, що дозволяють не тільки оновлювати модулі і ядро, а повністю управляти їх версіями. При оновленні Drupal-модулів теж може ламатися частина функціоналу, особливо якщо модулі давно не оновлювалися або змінилася підверсія модуля.

Стійкість до атак

Ядро Wordpress досить добре захищене від атак. Але Wordpress часто ламають через встановлені на нього плагіни і теми. Ситуацію погіршує те, що один і той же модуль можна скачати з різних місць і немає гарантії справжності модуля. Плюс більшість модулів не проходять перевірку безпеки коду. Також у доступі є безкоштовні версії платних модулів, які часто містять віруси. Якщо встановлювати плагіни з офіційних джерел і купувати модулі у продавців і своєчасно оновлювати їх, це в 99% випадків врятує від злому.

Ядро і модулі Drupal добре захищені від атак. Вони проходять перевірку співтовариством на відповідність стандартам кодування, а також код проглядається кількома учасниками спільноти перш, ніж буде опублікований. Майже всі доступні модулі викачуються з єдиного сховища та є безкоштовними. Тому шансів скачати шкідливий код мало. Проте ідеального коду не існує, і дірки в коді іноді знаходять. Своєчасне оновлення коду ядра і модулів також необхідне.

Робота з базою даних

Wordpress поставляється з налаштованої для роботи з mysql базою даних. Існує можливість переключитися на SQLite при встановленні додаткових плагінів. Використання інших типів БД можливе, але реалізація прошарку цілком лягає на плечі розробника. Для роботи з БД Wordpress використовує клас WP_Query і кілька функцій, що дозволяють вибрати ті чи інші записи з БД із застосуванням фільтрів сортування, пагінацію і іншим.

Drupal поставляється відразу з можливістю використовувати кілька типівБД, а саме MySQL, MariaDB, PostgreSQL, SQLite а також Microsoft SQL Server and MongoDB за умови установки відповідних модулів. Drupal реалізовує PDO, тобто прошарок для роботи з БД. Таким чином, всі запити з боку Drupal виглядають однаково, а потім перетворюються в запити обраної БД.

Імплементація верстки

Wordpress не використовує шаблонізатор і не виставляє майже ніяких обмежень на структуру шаблонів, але реалізує ієрархію шаблонів, які можуть бути використані для сторінок. Можна виводити записи блоку і сторінки за допомогою різних шаблонів. Також можна використовувати свої шаблони або ж реалізувати логіку їх підключення. Залишається також можливість прикріпити і шаблонізатор, але це теж лягає на плечі розробника. Але оскільки wordpress не реалізовує MVC-концепцію, то може давати і негативні аспекти. Складність масштабування і налагодження, заплутаність розмітка шаблону. У підсумку це підвищить витрати на підтримку сайту. Щодо аспекту безпосередньої імплементації сторонньої верстки в шаблоні, то, як правило, імплементація, за винятком пари-трійки нюансів, відбувається нормально. Звичайно, іноді бувають труднощі, але, як правило, їх можна вирішити або незначною зміною верстки, або реалізацією кількох filters. Підключення стилів і скриптів можна побудувати в чергу, а також вказати залежності один від одного.

Drupal змінив шаблонізатор з template php на twig, чим ще більше підтвердив свою прихильність MVC-концепції. Drupal також реалізує розширвану систему шаблонів з можливістю перевизначення. Такі шаблони існують для сторінок, блоків, полів, користувачів та інших типів сутностей. І це часто створює багато зайвої роботи, якщо потрібно перевизначити шаблони для більшості елементів. Існують альтернативи і компроміси, але використання рідної системи буде швидше трудомістким. Особливо гостро це відчувається, коли потрібно реалізувати сторонню верстку, не змінюючи її. Питання, що потрібно — верстати під Drupal або ж Drupal повинен імплементувати будь-яку верстку — причина багатьох холіварів, оскільки Drupal за замовчуванням додає свої класи і обгортки майже для кожного елемента на сторінці і робить це за своєю логікою зі своїм ім'ям класів. Фактино, верстати з допомогою готових класів зручно і швидко, це дає можливість покрити стилями ще не існуючі сторінки. Але це потрібно верстати під Drupal, тобто верстальник повинен володіти специфічними даними про структуру Drupal сайту. У разі сторонньої верстки або ж у разі, коли верстка робиться до того, як була обрана CMS, це не буде реалізовано. Перевизначати безліч шаблонів теж трудомістко. І доводиться шукати компроміс, за що в бік Drupal часто можна почути невтішні відгуки. Что стосується підключення стилів і скриптів, то Drupal тяжіє до SMACSS-концепції, тобто для кожного блоку необхідні стилі і скрипти підключаються окремо.Після вони збираються в групи і можуть об'єднуватися в один файл за відповідних налаштувань в адмінці.

CMS/CMF

Тут слід розповісти про Drupal, оскільки він позиціонується не тільки як CMS, але і як CMF. В Drupal можна не тільки наповнювати сайт вмістом, але також створювати нові види вмісту, додавати поля до існуючих, управляти відображенням цих полів, і все це з адміністративної частини сайту, не написавши жодного рядка коду.

07 вересня 2020