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

Зараз до виходу готується 6-а версія, код якої вже досить давно заморожений.Поточна 5-а версія в порівнянні з 4.7 виглядає хорошим еволюційним етапом. Нові версії довго тестуються. Ядро стабільне. Баги в затребуваних модулях зазвичай фіксують оперативно. Зараз цілий ряд великих корпоративних сайтів компаній зі світовими іменами працює на Drupal, тому у розробників до безпеки серйозне ставлення.

Ситуація на даний момент така - всі шанувальники Joomla перебувають в очікуванні версії 1.5. А гілка 1.0.х зазнає лише косметичні зміни, в основному що поліпшують безпеку. Так що з наявністю нових версій у Joomla "повний порядок". Безпека теж на рівні, версію 1.0.13 можна сміливо вважати дуже-дуже стабільною і безпечною.
Що ж стосується безпеки сторонніх розширень, то тут все не так гладко, що взагалі-то повторює ситуацію в цілому в мові PHP, як популярному серед новачків і людей які не знають нічого про те, як ламаються сайти. 90% софта глючна, а платні програмісти готові працювати за їжу. Дійсно сильних розширень мало, але вони є, наприклад OpenSEF або MosetsTREE.

Хоча офіційно і заявлено, що версії WordPress будуть виходити за графіком, насправді цього не відбувається. Якщо буде виявлено будь-яка серйозна "дірка", то розробники оперативно випускають оновлення, тому графік версій збивається. Існують дві лінійки WordPress: 2.0 .* та 2.1 +. Перша (поточна 2.0.12) все ще підтримується і до неї випускаються оновлення безпеки. Але нові можливості з'являються тільки в лінійці 2.1 + (поточна 2.2.2). Поділ відбулося після того, як було вирішено відмовитися від підтримки MySQL <4.0. За рахунок оптимізації запитів, швидкість роботи нових версій вище. Також зіграло свою роль і те, що в WordPress'е активно став використовуватися AJAX, якому потрібно UTF-8. Все це призвело до певних проблем сумісності, але, на мій погляд, воно було того варте.

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

Російськомовної документації достатньо, я б сказав - багато. Причому вона не простий переклад офіційної допомоги, а вже приходить до стадії написання авторських статей.

WordPress має дуже великий документацією (к.н. Codex / Кодекс), але на жаль вона лише англійською мовою. Хоча, справедливості заради варто відзначити, що складена вона грамотно і практично не потребує особливого знання мови. Документація побудована таким чином, що дозволяє досить швидко знайти потрібну відповідь. Практично кожна стаття має кілька прикладів, а також посилання на суміжні питання.

Розвивається, причому досить бурхливо, оскільки останнім часом про Drupal багато говорять в рунеті. Є люди що розбираються в архітектурі. Що важливо, вони відповідають на форумі. У цілому спільнота відкрита і доброзичлива, але зловживати цим не варто.

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

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

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

Боротьба зі спамом в інтернеті на даний момент ведеться тільки в одному місці - коментарі до публікацій. Компонентів коментарів досить багато, і про такі, без підтримки captcha я не чув (хіба що дуже давні і не використовуються на даний момент). На цьому власне боротьба зі спамом закінчується.

Стандартно в WordPress входить плагін Akismet, що досить ефективно бореться з цим злом. Крім цього можна створити чорний список і фільтри з слів. З їх допомогою можна просто заблокувати будь-який коментар, який містить заборонене слово або відправити його на модерацію. Найбільшу ж ефективність у боротьбі зі спамом можна домогтися за допомогою т.зв. капчи - картинки з набором символів. У цьому випадку ставиться повний заслін від автоматичних спам-роботів. Установка більшості полігонів антиспаму дуже проста, зачасту достатньо тільки його активувати в адмін-панелі (наприклад, популярна SpamKarma). За допомогою спеціального плагіна є можливість модерувати спам-коментарі. Причому доступні як звичайні коментарі, так і пінг і трекбакі. У цілому ж плагінів для антиспаму безліч (я нарахував більше сімдесяти).

Базовий пакет Drupal містить досить функціональний форум, який підійде для організації невеликих спільнот. Для організації великих спільнот він теж, втім, підійде - на форумі drupal.org зараз більше 320 000 повідомлень.
Є модератори, групи користувачів з різними правами доступу, повідомлення по email, аватари, підписи, RSS. Перевага вбудованого форуму - єдина база користувачів, яку використовують інші частини сайту.

Разом з Joomla не поставляється компоненту форуму, проте на даний момент самим оптимальним варіантом створення вбудованого форуму є FireBoard і його російська редакція від Adeptus'а. Що ж до інтеграцій - вони існують. Найпоширенішою є зв'язка Joomla-SMF, під яку є не одна інтеграція, навіть комерційна.

Для WordPress'а розроблений і рекомендується форум BBPress (є і русифікація), який повністю інтегрується в блог. Правда, можливості у цього форум більш ніж скромні. На офіційному сайті WordPress'а використовується саме цей форум. Також існують плагіни, які дозволяють частково інтегрувати деякі популярні форуми в блог. Щоправда, для цього потрібні хороші знання програмування, і при цьому, все одно стовідсоткової інтеграції не вийде - все-таки це різні системи.

У Drupal можна вбудувати TinyMCE або FCKEditor. І той і інший гнучко налаштовуються. Обидва є потужними засобами. У TinyMCE, наприклад, можна працювати з таблицями, додаючи і видаляючи рядки й стовпи, та об'єднуючи осередки. Ще TinyMCE може "чистити" скопійовані з Ворда тексти від надлишкових тегів.

Таких під неї безліч. Однак найбільш зручним і гарним з безкоштовних є редактор JCE, розроблений спеціально для Joomla (а спочатку ще для Mambo, тоді він називався MosCE), здатний скласти дуже гарну альтернативу платному WysiwygPro.

Стандартно в WordPress'е використовується трохи урізаний TinyMCE і, поряд ж - простий текстовий редактор (перемикання між ними "на льоту"). При бажанні можна встановити і повну версію TinyMCE, тоді буде доступно три панелі кнопок з усім можливостями. Потрібно відзначити, що в WordPress'е є можливість стороннім плагінам додавати кнопки в редактор. Таким чином можна наприклад отримати функції для додавання відео, аудіо і т.д. Якщо TinyMCE не влаштовує, то можна встановити замість нього інший редактор, наприклад FCKMonkey. Але в цілому, вибір редактора справа смаку. В профілі користувача можна взагалі відключити використання візуального редактора.

У базовому пакеті вставка картинок не передбачена. Вирішити цю проблему можна кількома шляхами. Є варіант з додаванням зображення в стилі "Додати файл до посту". Альтернатива - установка WYSIWYG-редактора TinyMCE і медіаменеджери IMCE зверху. Підтримується зміна розмірів зображення при завантаженні і генерація тамбнейлов. Я б не назвав роботу із зображеннями сильною стороною Drupal: занадто багато кліків доводиться робити.

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

У WordPress'е цілком зручно можна додавати картинки в редактор. Під час завантаження файлу можна одразу вказати його назву, підпис. Автоматично буде зроблена мініатюра. Тобто розрахунок на те, щоб з цим завданням впорався недосвідчений користувач. Якщо ж скористатися окремим плагіном, то можна додатково вказати розміри картинки, мініатюри та інші параметри. Після додавання зображення в редактор, можна змінити різні параметри (стилі, розміри, бордюри, відступи і т.д.). Хоча це вже можливості самого візуального редактора.

Шаблони - сильна сторона Drupal. Цей компонент добротно спроектований, тому розібратися з інтеграцією своїх шаблонів зможе початківець PHP-програміст. Взагалі Drupal надає цілий букет можливостей керування темами: можна навіть як в ЖЖ настроювати кольори різних елементів прямо з адмінки. Втім, ці новації на любителя.
На Drupal є красиві сайти, однак, пристойних загальнодоступних тим вкрай мало. Якщо забажаєте обзавестися сайтом на Drupal, приготуйтеся витратитися на шаблон.

Joomla гілки 1.0.х не підтримує шаблони. Звичайно, в ній є загальний і великий шаблон, який дозволяє на PHP створювати цілком хитромудрі структури загальної структури сайту і розташування модулів, але ось шаблонізаціі окремих елементів немає, і все обмежується застосуємо CSS (до речі, дуже система дуже гнучка, взяти той же "префікс класу модуля "і добре задокументована) і копирсання в компонентах. Однак для статей вже давно існує ContentTemplater, що дозволяє створювати шаблони оформлення для статей і дуже непогано управляти їх зовнішнім виглядом.
Другим моментом, про який варто сказати окремо є система модулів. Модулі об'єднуються в позиції, які вже й підвантажуються в потрібних місцях шаблону. Модулі можна прив'язувати до конкретних сторінок (вмикати і вимикати відображення), а також виводити різними способами по ходу сторінки. Часом, за допомогою маніпуляцій в шаблоні можна декількома модулями скласти дуже красиву головну (або будь-яку іншу) сторінку, просто вимкнувши компонент працює там і розташувавши замість нього модулі (наприклад, що відображають новини з різних категорій).

Для WordPress'а створені тисячі шаблонів і багато хто з них виконані на дуже хорошому дизайнерському рівні. Пристрій WordPress таке, що під нього нескладно переробити, скажімо, html-шаблон. У шаблонах використовуватися звичайні PHP-функції, тому ніяких складнощів з вивченням т.зв. мов шаблонів немає. На створення шаблонів є досить багато статей, навіть є он-лайн генератор. Готові шаблони достатньо завантажити в окремий каталог і після цього в адмін-панелі вибрати потрібний. Існує також можливість перемикати шаблони та відвідувачами.

Зараз в офіційній репозиторії зберігається під тисячі безкоштовних модулів. Серед інших є рішення для електронної комерції, CRM-система, wiki-движок. Ще зазначу модулі Views і CCK, які дають Друпалу повне право називатися CMF, а не CMS. CCK (Content Construction Kit), наприклад, дозволяє за допомогою графічного інтерфейсу описувати об'єкти предметної області в базі даних і відразу ж створювати форми для управління ними.

Найбільш сильною стороною Joomla є, я вважаю, система розширень. Мало того, що їх існує кілька видів, ще є спеціальна система їх встановлення, що дозволяє за допомогою xml-файлу описувати всі дії необхідні для здійснення під час створення запису про розширення (наприклад, SQL-запити, копіюються файли або дії виконуються відразу після установки, які не можна виконати автоматично).
У цьому я думаю Joomla попереду всіх трьох інших систем, тому що одних лише видів розширень існує три штуки. Та й конкурентів у офіційного сайту розширень серед інших систем я думаю немає (extensions.joomla.org) і бути не може. Одна тільки циферки (1915) нагорі з кількістю розширень в архіві змушує замислитися.

WordPress можна розширити за рахунок плагінів - це різні php-скрипти, які автоматично підключаються до основного "ядра". Таким чином можна не просто додати потрібну функціональність, але і змінити вже існуючу. Створити доданок не дуже складно, все залежить від рівня знання PHP. Підключення до WordPress'у зовсім просто: плагін копіюється в спеціальний каталог та активується в адмін-панелі. Деякі плагіни можна налаштовувати, деякі треба прописувати в шаблоні, а деякі працюють повністю автоматично.
Плагіни для WordPress написано кілька тисяч (лише на одному wp-plugins.net - 2568, але думаю, що цілому цифру можна подвоїти), тому можна знайти плагін практично під будь-які потреби. Виняток становлять плагіни, які вимагають значної переробки шаблону. З ними зазвичай доводиться повозитися.

У Drupal це називається "блоки". Їх можна розташовувати в різних областях сторінок в залежності від можливостей шаблону. У кожній області блоки можна сортувати для керування порядком виведення. Спочатку п'ять областей - шапка, центральна, ліва і права колонки, підвал. Блоки можна показувати не на всіх сторінках.

Так і не зрозумів що це таке. Ну, подумаєш, блоки переміщаються. При бажанні на Joomla теж можна таке зробити. Тільки питання - в чому їх корінний задум. Можливо, в Joomla це називається модулі, нехай і не перетягується, зате дуже зручно розташовуються по всьому шаблоном у будь-якому вигляді.

Повноцінна підтримка віджетів з'явилася тільки у версії 2.2. До цього потрібно було встановлювати окремий плагін. Те що віджети дуже зручні, багато хто вже встиг переконатися. Для користувача тепер немає потреби щось змінювати у своєму шаблоні: управління чисто візуальне, досить відзначити необхідні параметри, розташувати блоки як потрібно і зміни відразу ж набирають чинності. Внутрішня реалізація віджетів така, що з їх можна використовувати для виведення будь-якого плагіна або своєї функції.



Славиться тим, що з нього можна зробити платформу для блогів в кілька кліків. Підтримуються як персональні, так і колективні блоги. Одна з вбудованих фішок друпал - можливість публікації книг (деякі блогери хочуть хронологічного порядку).

Якщо вбудований компонент контенту можна вважати блогом, то так - блоги підтримуються. При бажанні однокористувацький блог з гарним оформленням легко робиться з компонента контенту, ContentTemplater і компонента коментарів. З багатокористувацьким все складніше. З певною натяжкою можна сказати "так", хоча це буде досить важко. Все-таки це CMS Joomla загального призначення. Сторонніх ж гарних, якісних компонентів, які підтримують російську мову на рівні Аякса без помилок - ні. Ну або майже немає, особисто я хороших прикладів впровадження не знаю.

WordPress досить добре зарекомендував себе як многоавторский блог. У всякому разі стандартні можливості у нього не викликають побоювань. А от для того, щоб розширити їх, потрібно використання додаткових плагінів. Наприклад це стосується додавання довільних полів в профіль автора, аватарка, фото і т.п. Парадокс у тому, що в WordPress'е вже закладено практично весь потенціал для цього, але так і не доведено до кінця.
Для управління авторами використовується система ролей. За допомогою спеціального плагіна можна легко (візуально) відредагувати будь-яку роль або дозволити / заборонити виконувати будь-які дії окремому авторові.
Для багатокористувацьких блогів існує окрема версія: WordPress Multi User. Вимоги та можливості в неї практично такі ж як і у звичайного WordPress'а, хоча є деякі відмінності. На WordPressMU працює одна з найбільших блог-сервісів WordPress.com, на якому зареєстровано майже 1,3 мільйона блогів.

Друпал популярний у світі, тому всі "модні" фішки там швидко реалізуються. У базовому пакеті є можливість ведення блогу посредствам блогова клієнта. Є модуль, пінг спеціальні каталоги Drupal-сайтів.

Joomla це CMS, і говорити про впровадження таких речей можна тільки на рівні сторонніх компонентів. Мабуть для Drupal'а і Wordpress'а це питання дуже актуальне, бо спочатку це все-таки блогова движки, а не CMS, і нікуди від цього не дітися. А в Joomla треба все розглядати на рівні якихось компонентів, наприклад того ж платного MyBlog. Якщо реалізують - добре, ні - позиції Joomla від цього ні скільки не похитнуться.

Трекбакі, пінг підтримуються вже давно. Причому для їх використання не потрібно взагалі ніяких додаткових дій: все працює на рівні "движка". Що стосується XML-RPC, то WordPress підтримує відразу кілька API, тому додавати / редагувати записи в WordPress можна з багатьох програм блог-клієнтів або он-лайн, наприклад за допомогою Google-Docs.
WordPress повністю підтримує RSS та Atom. Можна підписатися на останні записи блога, визначеної рубрики, коментарі або всі коментарі. За допомогою окремого плагіна можна зробити автоматичну переадресацію RSS-стрічки блога на feedburner.com.

Drupal працює на UTF-8. Якихось забутих строкових функцій, які не працюють з UTF-8 я не помічав. Деякі хостери по-старому віддають сторінки в cp1251, але це легко чиниться. Проблеми з MySQL теж зазвичай вирішуються одним рядком коду. Мені подобається UTF-8

Усі проблеми з російської версій в кодуванні CP1251 вже давно вирішені і на не дуже високих версіях MySQL проблем майже не викликають, потрібно лише почитати документацію. У параною (збірка Joomla від порталовцев, не зовсім від них, але це одна й та ж пісочниця) все вирішено більш вдало (це її основна особливість) і система сама обирає потрібну конфігурацію підключення в залежності від версії MySQL.
З UTF-8 все складніше, про це досить написано, скажу лише, що повна підтримка очікується (власне вона вже є) у версії 1.5. Зараз можна говорити лише про однобайтних кодуваннях і спробах зробити utf-сайти на непридатному для цього движку (хоча часом і вельми успішних). З Аяксом все теж складно, бо компоненти в основному роблять буржуї, які знати не знають про наші заморочках. А компонент цих стільки, що рук не вистачає ламати голову і мудрувати щось з iconv'ом.

У самому WordPress'е є можливість встановити будь-яку кодування. Головне, щоб кодування бази даних співпадала з кодуванням блогу. Щоправда, починаючи з версії 2.1 WordPress повинен працювати в UTF-8. Це прямо пов'язано з використанням AJAX.