Drupal 7 збіраецца быць вызваленыя, таму многія арганізацыі павінны вырашыць, ці варта абнавіць Drupal 5 або 6. Drupal выдатна, калі вы ствараеце шмат сайтаў і трэба ствараць новыя сайты хутка і без асаблівага кадавання, або калі вам проста трэба блог-на-пазіцыі, метадалагічнай змест сайта.
Працуе на Drupal, як жыць у падвойная шырыня : Гэта лепшае рашэнне, калі вы не можаце дазволіць сабе уласны дом. Калі ў вас ёсць сайт, які пачаўся на Drupal і досыць вырашчаны на працу распрацоўшчыкаў на поўны працоўны дзень, вы павінны разгледзець магчымасць пераходу на ваш сайт у Yii PHP рамкі , (PHP ненавіснікі могуць рушыць услед лук і выкарыстоўваць рамкі Django Python , Хоць гэта зойме больш часу, каб змяніць рамкі і моў праграмавання.)
Я CTO з сайт што перайшоў з Drupal на Yii 30 красавіка 2010 года было цяжка знайсці інфармацыю, калі мы абмяркоўвалі перапісаны і не было нават Кніга пра Yii яшчэ. Былі некалькі каментароў аб пераходзе з Drupal на Yii, але яны не ўключаюць у сябе дастаткова дадзеных, каб супакоіць мяне. Я турбаваўся, што Yii можа быць павольней, чым наш моцна аптымізаваны ўстаноўку Drupal, таму я вырашыў перапісаць ядро 20% нашага сайта (у якім утрымліваецца 80% нашай функцыянальнасці) на працягу 30 дзён. Здавалася, што гэта выдатны спосаб, каб праверыць прадукцыйнасць і прадукцыйнасць фреймворка, і калі Yii не было паляпшэнне пасля гэтага месяца мы заўсёды маглі вярнуцца да Drupal і скапіяваць любыя новыя дадзеныя.
Yii быў нашмат хутчэй, чым Drupal для нашага сайта з 150000 вузлоў (кожны з перапісанага URL) і 50000 наведвальнікаў у дзень. Так, мы працавалі вар'яцкія гадзіны на працягу гэтых 30 дзён (і наступныя 15), але яно таго каштавала. Час, якое мы раней правялі работы вакол павольных запытаў Drupal было б лепш выкарыстоўваць, і гэта было нашмат больш цікава развівацца на Yii, чым на Drupal. Рэальная выгада ад Yii прыйшла пазней, калі мы перапрацавалі наш сайт. З MVC Yii, мы толькі павінны былі змяніць 2 раскладку супраць некалькіх дзясяткаў у Drupal.
Я проста хачу, каб мы перайшлі годам раней. Вось што мы даведаліся:
- Drupal гэта не самы лепшы спосаб пазбегнуць , пачынаючы з нуля. Drupal асноўны кропка продажу для распрацоўнікаў «чаму згарнуць свой уласны CMS?" Як і многія распрацоўшчыкі, я напісаў цэлыя вэб - дадатак з нуля (у 1999 і 2000 ) І ацаніў магчымасць засяродзіцца на унікальных патрэбах бізнесу прыкладання замест напісання ўласнага кода, каб апрацоўваць ўсе аспекты аўтэнтыфікацыі, валідацыю формаў, SQL ін'екцый прадухілення нападаў і г.д. Кампанію я дапамог заснаваць у пачатку 2007 года быў прататып сайт на Drupal, і я быў гатовы ўбачыць, што Drupal можа зрабіць, перш чым выкінуць яго прэч для Ruby On Rails. Манія Рубін нагадаў мне захапленне Java ў 1997 годзе я быў стажорам у WebEx канкурэнт у 1997-99, які забіў іх прадукцыйнасць за кошт кадавання іх сервер у Java, перш чым сервернае абсталяванне і VM аптымізацый дазволіла маштабаванасці. PHP ўжо зарэкамендаваў сябе з перапісваннем Friendster і на Facebook, і нашы карыстальнікі ня хочуць бачыць Fail Whale калі мы сутыкнуліся з праблемамі маштабаванасці з Ruby.
Вядома, гэта лягчэй пачаць працу з Drupal, чым кадаваньне кожнага радка PHP самастойна. Але звязка PHP 5 рамак былі пачаты ў 2008 годзе і былі пастаўлены на выпрабаванні ў 2009 , PHP-распрацоўшчык, пачынаючы ад вэб-прыкладанняў у цяперашні час (і працуе поўны працоўны дзень, толькі на гэтым сайце) будзе альбо выбраць структуру або пачаць з нуля і выкарыстоўваць PHP бібліятэкі (PECL або грушападобнай.) - Калі Drupal з'яўляецца асновай, толькі Руба Голдберга можа любіць яго. Drupal распрацаваны, каб быць пашыраемым без асаблівых PHP праграмавання. Гэта добра, калі вы проста стылізацыі простага зместу сайта або мала трафіку. Калі вы працуеце поўны працоўны дзень модуляў пішучых для налады формаў і дадання функцыянальнасці, вы будзеце марнаваць больш часу, душачы функцыянальнасць Drupal, што вы не хочаце, чым вы маглі б будаваць на аснове. Yii мае супрацьлеглы падыход - вы можаце выкарыстоўваць лал на Рэйкі тыпу 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, я хутка зразумеў, што я хацеў толькі строгі PHP 5 рамак ААП 100%. Вы не бачыце шмат людзей , сцвярджаючы , што працэдурныя «гаплікі» у Drupal падыход пераўзыходзіць ААП. Хоць Drupal 7 патрабуе PHP 5, як CodeIgniter і іншыя структуры старэй PHP ён усё яшчэ нясе багаж зваротнай сумяшчальнасці. Хто хоча багаж кагосьці іншага?
- не хачу Drupal 6 ці 7 , каб запаволіць Drupal 5 сайт? Здзелка з састарэлай JQuery. Для большасці сайтаў гэта нармальна. Мы сапраўды клапоцімся аб хуткасці, паколькі Google і Microsoft паказалі, што карыстальнікі больш лаяльныя да хуткім сайтаў. У 2009 годзе, калі Drupal 6 быў, і створаны, мы затрымаліся з Drupal 5 з-за вымерна перавага ў хуткасці. Праблема складаецца ў тым, што Drupal 5 ўключае ў сябе JQuery 1.0. Вы можаце дадаць свой уклад модуль залатаць JQuery 1.2 (і абнавіць функцыі Drupal, якія спасылаюцца на яго), але гэта ўсё яшчэ старая версія. Забудзьцеся аб JQuery 1.3x і Drupal 5.
- Будаўніцтва поля API / ўтрыманне камплекты ў Drupal (СБК) будзе зводзіць вас з розуму, і гэта частка Drupal 7 ядра. Навошта выкарыстоўваць $ node-> IP, калі вы можаце выкарыстоўваць $ node-> field_ip [0] [ 'значэнне']. І калі вы вырашылі, што два тыпу кантэнту абодва павінны мець тэкставае поле з тым жа імем, CCK змесціць, што ў табліцы свайго ўласнага (content_field_ip) з цудоўнымі імёнамі слупкоў (field_ip_value). Вядома, Drupal можа разблытаць гэты беспарадак, калі поўны вузел загружаны, але гэта не вельмі, каб глядзець на ў базе дадзеных. MySQL запытаў спатрэбіцца шмат злева далучаецца апрацоўваць ўсе дадатковыя сталы СБК, а тыя залішне-складаныя запыты будуць у канчатковым выніку ў часопіс павольных запытаў занадта часта. Я, нарэшце, надакучыла спрабаваць аптымізаваць усе гэтыя павольныя запыты і вырашылі пазбавіцца ад СБК, што і прывяло мяне да фреймворк, а затым у Yii.
Міграцыя нашых дадзеных у Yii прынялі прыкладна столькі ж часу, як гэта было б штурхнуць CCK звычку яшчэ заставацца на Drupal. Тым не менш, мы змаглі пачаць з чыстай БД без усіх дадатковых табліц Drupal выкарыстоўвае для сваіх унутраных мэтаў. Наш стары DB было 173 табліц; наш новы адзін мае 54. 
Drupal нашмат павольней , чым Yii. Drupal маштабуецца толькі калі вы кэшаваць ВСЕ з Memcached і APC і перапісаць усё павольныя запыты. Кэшаванне асабліва важна, калі вы выкарыстоўваеце SEO дружалюбнага перезаписаные URL-адрас для ўсіх вашых спасылак, таму што кожная функцыя л () уяўляе сабой асобны выклік базы дадзеных. Так сярэдняя старонка мае 50+ запытаў на яго, у параўнанні з 3-5 у Yii. Пасля ўключэння, наша сярэдняя час загрузкі старонкі паменшылася з 162 мс да 67 мс згодна Інструменты Google для вэб-майстроў. Яшчэ лепш, Yii + APC настолькі хутка, што мы не трэба выкарыстоўваць memchached, спрасціўшы наш код і аперацыі.
Наша статыстыка сервераў кажуць самі за сябе - за тое ж колькасць адначасовых запытаў наведвальнікаў (Apache працэсаў), БД і загрузка працэсара пайшоў уніз. Выкарыстанне памяці засталося прыкладна тым жа. За апошні год наш трафік павялічыўся на 60% да 1,5 млн штомесячных наведванняў у той час як MySQL запыты знізіліся на 66%
