Друпал 7 ось-ось буде випущений, тому багатьом організаціям необхідно вирішити, чи буде оновлення з Drupal 5 або 6. Друпал добре, якщо ви будуєте багато веб-сайтів і потребуєте швидко створювати нові сайти без особливого кодування, або якщо вам просто потрібно веб-сайт із вмістом блогу на стероїдах.
Запуск на Drupal схожий на життя в подвійний : це найкраще рішення, якщо ви не можете дозволити собі власний будинок. Якщо у вас є сайт, що розпочався на Drupal, і він зростав достатньо, щоб задіяти розробників на повний робочий день, слід розглянути можливість міграції сайту на Yii PHP фреймворк . (Ненависники PHP можуть слідувати за цибулею і використовувати Фреймворк Django Python , хоча змінити рамки та мови програмування потрібно більше часу.)
Я - технічний директор сайту що перейшла з Drupal на Yii 30 квітня 2010 року. Важко було знайти інформацію, коли ми обговорювали перезапис, і навіть не було Книга про Yii ще. Було кілька коментарів про перехід від Drupal до Yii, але в них не було достатньо даних, щоб заспокоїти мене. Я був стурбований тим, що Yii може бути повільніше, ніж наша інтенсивно оптимізована установка Drupal, тому я вирішив переписати основний 20% нашого сайту (який забезпечив 80% нашої функціональності) за 30 днів. Здавалося, це чудовий спосіб перевірити продуктивність і продуктивність Yii, і якщо Yii не був удосконаленням після цього місяця, ми завжди могли повернутися до Drupal і скопіювати будь-які нові дані.
Yii був набагато швидше, ніж Drupal для нашого сайту з 150 000 вузлів (кожен з переписаною URL-адресою) і 50 000 відвідувачів на день. Так, ми працювали божевільні години за ці 30 днів (і наступні 15), але це було того варте. Час, який ми раніше проводили, працюючи навколо повільних запитів Drupal, був використаний краще, і це було набагато цікавіше розробляти на Yii, ніж на Drupal. Реальна користь Yii прийшла пізніше, коли ми переробили наш сайт. З MVC Yii, нам довелося лише змінити 2 файли компонування проти декількох десятків в Drupal.
Я бажаю, щоб ми перейшли роком раніше. Ось що ми дізналися:
- Друпал - це не найкращий спосіб уникнути початку роботи з нуля . Основний пункт продажу Drupal для розробників - це " чому розгортати власну CMS? " Як і багато інших розробників, я написав цілі веб-додатки з нуля ( 1999 і 2000 ) і оцінив можливість зосередитися на унікальних бізнес-потребах програми замість написання мого власного коду для обробки всіх аспектів аутентифікації, перевірки форми, запобігання атакам SQL і т.д. Компанія, якій я допомагав, виявив на початку 2007 року прототип веб-сайт на Drupal, і я був готовий побачити, що може зробити Drupal, перш ніж викинути його на Ruby on Rails. Захоплення Ruby нагадало мені про захоплення Java в 1997 році. Я був стажистом на Конкурент WebEx в 1997-99 роках, що знищили їх продуктивність, кодуючи їх сервер на Java перед серверним апаратним забезпеченням і оптимізацією VM, дозволили масштабованість. PHP зарекомендував себе з переписами Friendster і в Facebook, і наші користувачі не хотіли бачити кит якщо ми зіткнулися з проблемами масштабування з Ruby.
Звичайно, легше розпочати з Drupal, ніж кодувати кожну лінію PHP. Але в 2008 році було запущено купу каркасів PHP 5, які були випробувані в Росії 2009 . Розробник PHP, який зараз починає працювати з веб-додатком (і працює тільки на цьому сайті), вибирає фреймворк або починає з нуля і використовує бібліотеки PHP (PECL або PEAR.) - Якщо тільки Drupal - це фреймворк Рубі Голдберг міг любити його . Drupal розроблений, щоб бути розширюваним без багато PHP-програмування. Це прекрасно, якщо ви просто створюєте простий контентний сайт або маєте невеликий трафік. Якщо ви працюєте на повний робочий день написання модулів для налаштування форм і додати функціональність, ви будете витрачати більше часу придушення Drupal функціональність, що ви не хочете, ніж ви б побудувати на рамках. Yii має протилежний підхід - ви можете використовувати Ruby on Rails-подібний ORM якщо це досить швидко і лише оптимізує 10% запитів, які потребують MySQL.
- Модулі, що надаються спільнотою, схильні до featuritis та помилок, які є наслідком непотрібної складності . Є дуже багато вкладених в Drupal модулів, і якщо у вас є повний робочий день розробники ви, ймовірно, просто вирішити, як ми зробили, щоб засвоїти частини внесених модулів у ваші власні модулі. Моделі зміни розміру та кешування зображень Drupal є прекрасним прикладом цього. Оскільки модулі розроблені так, щоб бути загальними (щоб вони могли працювати з довільною кількістю інших модулів!), Вони включають тонни функціональних можливостей, які ви ніколи не будете використовувати. У нашому випадку нам просто потрібно зробити мініатюри різних розмірів, які конвертують двійкові файли ImageMagick. Щоб отримати це, нам довелося ввімкнути 4 модулі, кожен з яких має купу файлів php: ImageAPI, ImageAPI для ImageMagick, ImageCache і ImageCache UI. Тоді фактичні команди для створення мініатюр знаходяться в 2 таблицях бази даних. Якщо це припинить роботу, коли ви оновлюєте частину ланцюжка, діагностика проблеми займе набагато більше часу, ніж якщо б ви побудували тільки те, що вам потрібно.
Yii також має розширення розміру зображень (адаптованого з бібліотеки зображень Kohana), але це ускладнено, оскільки він призначений для легкого перемикання між ImageMagick і GD. (GD має проблеми з 2 Мб + зображеннями.) Незважаючи на все це, він все ще не дозволив нам змінювати розміри зображень на льоту за допомогою RewriteRule, якщо мініатюра не існувала. Таким чином, я створив простий файл index.php, який просто обробляє зворотні виклики RewriteRule на виділеному віртуальному хості для зображень і надсилає команди, які перехоплюють оболонки, безпосередньо до перетвореного двійкового файлу. Це означає, що зворотні виклики RewriteRule не проходять через файл Yii index.php, зменшуючи накладні витрати та час, необхідний для операцій зміни розміру та кешування зображень. Це лише сторінка PHP, і аргументи відправляються в одному виклику до конвертованого двійкового файлу, тому набагато простіше протестувати і підтримувати, коли ми оновлюємо ImageMagick. - У Drupal є багаж PHP 4 . Як тільки я вирішив розглянути PHP-фреймворки, я швидко зрозумів, що хочу лише 100% суворої PHP PHP ООП. Ви не бачите багато людей, які стверджують, що процедурний підхід "крюків" у Drupal перевершує ООП. Хоча для Drupal 7 потрібен PHP 5, як і CodeIgniter та інші старі фреймворки PHP, він все ще несе багаж зворотної сумісності. Хто хоче чужий багаж?
- Не хочу Drupal 6 або 7 для уповільнення Drupal 5 сайт? Робота з застарілим jQuery . Для більшості сайтів це нормально. Ми дійсно піклуємося про швидкість, оскільки Google і Microsoft продемонстрували, що користувачі більш лояльні до швидких сайтів. У 2009 році, коли Друпал 6 був встановлений, ми закріпилися за Drupal 5 через вимірну перевагу швидкості. Проблема в тому, що Drupal 5 включає в себе jQuery 1.0. Можна додати внесений модуль для виправлення jQuery до 1.2 (і оновити функції Drupal, які посилаються на неї), але це все ще стара версія. Забудьте про jQuery 1.3x і Drupal 5.
- Поле API для конструювання вмісту Drupal (CCK) змусить вас звести з розуму, і це частина ядра Drupal 7 . Навіщо використовувати $ node-> ip, коли ви можете використовувати $ node-> field_ip [0] ['value']. І якщо ви вирішите, що два типи вмісту повинні мати текстове поле з тим же ім'ям, CCK помістить його в свою таблицю (content_field_ip) з чудовими іменами стовпців (field_ip_value). Звичайно, Drupal може розплутати цей безлад, коли завантажується повний вузол, але це не дуже приємно дивитися в базі даних. Запити MySQL потребуватимуть багатьох лівих об'єднань для обробки всіх додаткових таблиць CCK, і ці непотрібно складні запити занадто часто закінчуватимуться у журналі повільних запитів. Я, нарешті, набридла намагатися оптимізувати всі ці повільні запити і вирішила позбутися CCK, що призвело мене до PHP-фреймворків, а потім до Yii.
Міграція даних до Yii тривала приблизно стільки ж часу, скільки треба було б кинути звичку CCK, але залишитися на Drupal. Однак, ми змогли почати з чистої БД без усіх додаткових таблиць, які Друпал використовує для своїх внутрішніх цілей. Наша стара БД мала 173 столи; наш новий має 54. 
Друпал - це МІЛЬШ повільніше, ніж Yii . Друпал масштабує лише, якщо кешувати ВСЕ з memcached і APC і переписувати всі повільні запити. Кешування особливо важливо, якщо ви використовуєте SEO-дружні URL для всіх ваших посилань, оскільки кожна функція l () є окремим викликом бази даних. Таким чином, середня сторінка має 50 + запитів на ній, проти 3-5 у Yii. Після перемикання, середнє час завантаження сторінки зменшилося з 162 мс до 67 мс відповідно до інструментів Google Webmaster. Ще краще, Yii + APC є настільки швидким, що нам не потрібно використовувати memchached, що спрощує наш код і операції.
Статистика нашого сервера говорить сама за себе - за таку ж кількість одночасних запитів відвідувачів (процеси Apache), використання БД і ЦП пішли вниз. Використання пам'яті залишилося приблизно однаковим. За останній рік наш трафік збільшився на 60% до 1,5 млн. Відвідувань щомісяця, в той час як MySQL-запити знизилися на 66%
