Парады па ўжыванні Drupal

  1. Галоўны мінус Drupal
  2. Савет # 1: Кожнаму праекту - свой Drupal
  3. Савет # 2: Рулим Drupal'ом з каманднага радка
  4. Савет # 3: Аўтарызацыя па OpenID
  5. Савет # 4: Drupal + «У Кантакце»
  6. Савет # 5: Выбіраем прасунуты шаблонизатор
  7. Савет # 6: З чаго пачынаць стварэнне першай ўласнай тэмы для Drupal
  8. Савет # 7: Shared хостынг або VPS?
  9. Савет # 8: Пачатковы аптымізацыя
  10. Савет # 9: Серверныя кампаненты
  11. Савет # 10: Альтэрнатыўнае кэшаванне
  12. Савет # 11: Views замест сваіх запытаў
  13. Совет # 12: Drupal.API
  14. Савет # 13: нагрузачнага тэставання
  15. Савет # 14: Добры індзеец - мёртвы індзеец
  16. Савет # 15: прыручаць nginx
  17. Савет # 16: Рыхтуйся да Drupal 8
  18. заключэнне

Пра яго кажуць: гнуткі і складаны, бяспечны і хуткі. Ім многія захапляюцца, але не ўсе вырашаюцца ўжываць у сваіх праектах. Ды ён такі, гэты Drupal. Ўмее многае, але каб атрымаць максімальную аддачу ад гэтай сістэмы распрацоўніку прыйдзецца, як след папацець і разабрацца ў шматлікіх тонкасцях. Гэты шлях цярністы і цяжкі, але мэта адназначна таго варта. Я пачаў прымяняць Drupal у сваім вялікім праекце не так даўно, але ўжо паспеў напакаваць некалькі гузоў і хачу зберагчы ад гэтага цябе. Заінтрыгаваны? Тады, падрыхтуйся выслухаць парады ад ужо не зусім пачаткоўца Drupal'ера.

Галоўны мінус Drupal

Адным з галоўных мінусаў Drupal'а заўсёды быў адсутнасць нармальнай, структураванай дакументацыі. Няма, ёсць форумы, маюцца афіцыйныя докі, але гэта ўсё не тое. Уся смачная інфармацыя раскідана па закутках сусветнай павуціны, і хутка знайсці адказ атрымліваецца не заўсёды. Яшчэ складаней распрацоўнікам, незнаю мова Шэкспіра. У гэтым артыкуле я паспрабую даць парады і прыклады рашэння задач, з якімі я сам калісьці сутыкнуўся. Упэўнены, што з падобнымі цяжкасцямі сутыкаюцца многія. Вельмі спадзяюся, што пасля чытання артыкула, такіх ня шчасліўчыкаў стане менш. Адразу абмоўлюся, што ў рамках часопіснай артыкула асвяціць усё што хочацца - нерэальна. Частка саветаў застанецца за кадрам, але ты зможаш у любы час іх пачытаць на сайце праекта VR-Online (поўную спасылку на артыкул шукай ва ўрэзцы).

Савет # 1: Кожнаму праекту - свой Drupal

Drupal прыдатны не толькі для будаўніцтва web-сайтаў. На аснове гэтага рухавічка зручна распрацоўваць розныя web-прыкладання. Часцяком, падобныя прыкладання распрацоўваюцца для ўнутрыкарпаратыўных патрэб. Да такіх праектах прад'яўляюцца зусім іншыя патрабаванні, і тыповай зборкі Drupal можа апынуцца мала. Так, усё лёгка дапіў і наладзіць, але часам турбавацца пра гэта не трэба, бо аматары Drupal'а ўжо ўсё зрабілі.

З альтэрнатыўных «версій» Drupal я магу параіць: BrainstormBlogger і Open Atrium . Першы праект - гэта зборка Drupal'а, спецыяльна створаная для хуткага стварэння блогаў. Выкарыстоўваць чысты Drupal для будаўніцтва блога - працэс працаёмкі і не кожны пачатковец з ім справіцца. Спецыяльна для такіх выпадкаў і людзей наш суайчыннік зрабіў альтэрнатыўную зборку Drupal. З скрынкі brainstormblogger гатовы да працы і змяшчае ў сабе ўсе неабходныя модулі (воблака тэгаў, блог і г.д.) для разгортвання паўнавартаснага блога. У выпадках, калі патрэбен просты блог, то гэта ідэальны варыянт. Хачу таксама адзначыць, што ўжыванне Brainstorm blogger ня накладвае ніякіх абмежаванняў. Ты таксама можаш ўсталёўваць дадатковыя модулі, выконваць аўтаматычнае абнаўленне рухавічка і г.д.

Другі праект, пра які я хачу табе расказаць - Open Atrium. Ён дазваляе ў самыя кароткія тэрміны падняць сістэму для сумеснай працы. Калі ты вядзеш аддзелам, то адназначна знаёмы з падобнымі праектамі. Яны дазваляюць замацоўваць задачы за пэўным супрацоўнікам, планаваць час іх выканання, адсочваць працэс завяршэння, фарміраваць справаздачы і г.д. Большасць такіх праграм - платныя, але ў функцыянальным плане яны недалёка сыходзяць (або зусім адстаюць) ад Open Atrium. Калі перад табой паўстала задача знайсці і разгарнуць падобны софт, то абавязкова прыгледзься да гэтага прадукту. Ён хуткі, функцыянальны, бясплатны і пры вострай неабходнасці яго можна дапіў пад сябе. Набор ключавых функцый прыводжу ніжэй:

  • Сістэма тикетов;
  • блогі;
  • каляндар;
  • Дакументы wiki;
  • Дошка для групавой працы;
  • Савет # 2: Рулим Drupal'ом з каманднага радка

    Зручны web-інтэрфейс панэлі адміністравання Drupal - гэта добра, але зусім не заўсёды зручна. Як было б выдатна, мець магчымасць выконваць адміністрацыйныя аперацыі прама з каманднага радка. А бо гэта магчыма! Досыць загрузіць і ўсталяваць пакет drush . З яго дапамогай адміністратар drupal'а можа выконваць разнастайныя дзеянні прама з кансолі:

  • Атрымліваць інфармацыю пра налады сайта;
  • Ўсталёўваць / выдаляць модулі;
  • Выконваць абнаўленне рухавічка;
  • і г.д.
  • З усіх магчымасцяў drush я часцей за ўсё карыстаюся функцыяй абнаўлення модуляў. Стандартны працэс загрузкі апдэйтаў славіцца сваёй занудна. Першапачаткова патрабуецца скласці спіс абновяць модуляў, затым зайсці на афіцыйны сайт Drupal і перайсці на старонку модуля. Потым загрузіць яго, перамясціць у патрэбную дырэкторыю, выканаць скрыпт абнаўлення і г.д. Добра, калі трэба абнавіць адзін модуль, а калі іх 10, 20? Папросту можна сысці з розуму! Куды весялей выконваць гэтую працэдуру пры дапамозе Drush. У гэтым выпадку досыць скарыстацца камандамі up і upc. Выдаленне / адключэнне новых модуляў выконваецца аналагічным чынам. Напрыклад, для выдалення модуля прадугледжана каманда:

    $ ./Drush uninstall <модуль або спіс модуляў> Прыкладна таксама адбываецца адключэнне і ўключэнне модуляў: $ ./drush en blog // ўключаем модуль blog $ ./drush dis blog // адключаем модуль blog

    Акрамя пералічаных смачнасцяў, drush саслужыць добрую службу, калі ты прымудрыўся ўсталяваць глючны модуль і пакладзеш адлюстраванне панэлі адміністравання. Як у такой нялёгкай сітуацыі карэктна выдаліць вінаваты модуль? Пры такім раскладзе drush зможа аказаць першую дапамогу і з дапамогай адной каманды выдаліць капрызны модуль.

    Савет # 3: Аўтарызацыя па OpenID

    Сайты з уласнай сістэмай аўтарызацыі адыходзяць на другі план. Жыццёва-неабходных web-сэрвісаў з кожным днём станавіцца ўсё больш і захоўваць у галаве дзясяткі звязкаў з лагінаў / пароляў задача не з лёгкіх. Каб неяк яе вырашыць, у свой час і быў створаны OpenID - адкрытая цэнтралізаваная сістэма, якая дазваляе карыстачу выкарыстоўваць адзіны лагін / пароль для выканання аўтарызацыі на розных сайтах. Апошняе актуальна, калі яны падтрымліваюць OpenID.

    Пачынаючы з шостай версіі, у складзе Drupal ідзе модуль, які забяспечвае магчымасць аўтарызацыі па OpenID. Аднак, каб пачаць выкарыстоўваць на сайце OpenID, неабходна падключыць яшчэ адзін модуль, які змяшчае налады для розных пастаўшчыкоў OpenID. Такіх пастаўшчыкоў шмат, але найбольш папулярнымі (для расійскіх карыстальнікаў) з'яўляюцца: Yandex, Rambler, Google, VKontakte, FaceBook і г.д. Для замежных сэрвісаў (google, livejournal, facebook) у рэпазітарах drupal ёсць адпаведныя модулі, а вось для нашых - не. Калі перада мной паўстала задача прыкруціць OpenID-аўтарызацыю, то мне прыйшлося прошурстить інтэрнэт, з мэтай пошуку рашэння. І яно знайшлося! Каб усё было ціп-топ, трэба скарыстацца модулем OpenID Extension ад нашага суайчынніка. Звярні ўвагу, дадзены модуль - не чарговы варыянт ўзаемадзеяння з OpenID. Гэта проста зручны блок для выканання аўтарызацыі, а таксама магчымасць выбару поствыщка ў нашай краіне ID параметраў.

    Савет # 4: Drupal + «У Кантакце»

    Падключыць на сайт аўтарызацыю па OpenID несумненна карысна, ну, а што калі толькі патрабуецца забяспечыць больш просты ўваход на сайт (без рэгістрацыі) карыстальнікам, якія маюць рахунак на сацыяльнай сетцы «У Кантакце»? Так, можна проста адключыць лішніх пастаўшчыкоў у External Form Login, але гэта не вырашыць праблему. Выконваючы ўваход па VKontakteID, карыстачу фактычна прыйдзецца стварыць новы ўліковы запіс на сайце. Пры ўваходзе ён убачыць стандартную рэгістрацыйную форму, якая чакае запаўнення. Так, яму нават пароль прыйдзецца прыдумляць.

    Толькі пасля стварэння акаўнта да яго будзе прывязаны OpenID ідэнтыфікатар (у дадзеным выпадку VKontakteID) і карыстальнік зможа выконваць ўваход па ім. Сам разумееш, такі падыход не вельмі зручны і скарыстацца ім можна не заўсёды. Часам патрабуецца рэалізаваць нешта больш проста. Уяві, як было б выдатна, маючы карыстальнік рахунак на «У Кантакце», мог адразу ўвайсці на твой сайт. Іншымі словамі, Drupal павінен ствараць новы ўліковы запіс аўтаматычна на падставе атрыманых дадзеных ад «У Кантакце». На шчасце, дамагчыся такога эфекту не так-то складана. Прыкладна паўгода таму распрацоўшчыкі папулярнай сацыяльнай сеткі адкрылі доступ да OpenAPI інтэрфейсу. Дзякуючы гэтаму, карыстальнікі атрымліваюць магчымасць выконваць аўтарызацыю на іншых сайтах, выкарыстоўваючы уліковы запіс «У Кантакце».

    Дадаць у Drupal падтрымку «У Кантакце OpenAPI» дазваляе модуль VK OpenAPI . Модуль просты ў выкарыстанні і з яго дапамогай лёгка наладзіць «новую» сістэму аўтарызацыі. Акрамя аўтарызацыі, VK OpenAPI можа дадаць да матэрыялаў кнопку "Share", якая дазваляе карыстальнікам дзяліцца упадабаным матэрыялам.

    Савет # 5: Выбіраем прасунуты шаблонизатор

    Адным з самых удалых шаблонизаторов для PHP лічыцца Smarty . У многіх сучасных CMS выкарыстоўваецца менавіта ён і на гэта ёсць прычыны. Галоўныя з іх - гнуткасць, зручнасць і вялікія магчымасці. Нажаль, па змаўчанні ў Drupal ўжываецца уласны шаблонизатор, але пры жаданні лёгка падключыць smarty. Для гэтага неабходна загрузіць smarty theme engine для Drupal і ўласна сам Smarty (спасылку ужо даваў). Пасля прароблівання гэтых няхітрых аперацый, ты атрымаеш магчымасць ствараць тэмы на базе Smarty. Дарэчы, чамусьці гатовых тым на аснове Smarty не так шмат, таму ў цябе ёсць усе шанцы стаць аўтарам самай прыгожай і зручнай Smarty тэмы, на якой будуць вучыцца за тысячу карыстальнікаў.

    Савет # 6: З чаго пачынаць стварэнне першай ўласнай тэмы для Drupal

    Рана ці позна перад Drupal'ером ўстае задача па распрацоўцы уласнай тэмы афармлення. Я б сказаў, што менавіта на гэтым этапе, 90% пачаткоўцаў прымаюць фатальнае рашэнне - "Drupal не для мяне". Збольшага іх можна зразумець, бо темизация - адна з самых складаных і незразумелых рэчаў. Трэба прыкласці намаганні, каб добра асвоіць дадзены працэс і ўжываць яго ў далейшым без сучка і задзірынкі. Каб працэс асваення праходзіў больш гладка і зразумела, то я б рэкамендаваў табе выканаць некалькі простых крокаў.

  • Чытанне мануалаў. Калі ўзровень англійскай дазваляе, то знаёміцца ​​з темизацией варта пасля чытання афіцыйнай дакументацыі ( http://drupal.org/documentation/theme ). Напісана ў ёй шмат як карыснага, так і бескарыснага матэрыялу. У любым выпадку, вывучыўшы яго, ты адназначна зразумееш, як у Drupal працуюць тэмы, і пазнаёмішся з іншымі нюансамі гэтай галіне. Другім, абавязковым для чытання дакументам будзе цыкл артыкулаў ад Рамана Архарова - прафесійнага Drupal распрацоўніка. Раман напісаў некалькі выдатных артыкулаў па Drupal . Сярод іх ёсць выдатная артыкул пра темизацию.
  • Вывучэнне тэмы Zen. Пачаць распрацоўваць новую тэму для Drupal з чыстага ліста - даволі складаны працэс. Пачаткоўцу наўрад ці хопіць сіл і цярпення завяршыць яго да канца. Для палягчэння жыцця лепш узяць за аснову тэму Zen . Увесь код тэмы добра прокомментірован і працаваць з ім адно задавальненне. Дарэчы, менавіта Zen рэкамендаваны распрацоўшчыкамі, прыступіў да вывучэння темизации Dupal.
  • Савет # 7: Shared хостынг або VPS?

    Сам па сабе Drupal досыць шустры, але варта абчапіць яго дадатковымі модулямі і вывесці ў рэальнае плаванне, як пачынаюцца праблемы з прадукцыйнасцю. Каб Drupal ляцеў таксама хутка, як падае кропля дажджу з неба, трэба паклапаціцца аб правільнай наладзе навакольнага яго асяроддзя. Гаворка вядома аб WEB-сэрвэры, СКБД, PHP і г.д. Максімальная прадукцыйнасць магчымая толькі пры дбайнай наладзе ўсіх кампанент. Да няшчасця, атрымаць доступ да многіх налад, пералічанага ПА, на звычайным хостынгу нельга. Прыходзіцца здавольвацца тым, што прапануе хостер.

    Калі сайт мала наведваем, то ўсё ok. У адваротным выпадку, наведвальнікі будуць часта бачыць белы экран смерці, чым чаканы рэсурс. Зыходзячы з вышэйсказанага, раю не выкарыстоўваць shared-хостынг для размяшчэння больш-менш наведвальнага рэсурсу. Лепш трохі выдаткаваць грошай і набыць VPS, дзе ты будзеш галоўным гаспадаром і будзеш сам вызначаць налады ўсіх серверных кампанент (уключаючы АС).

    Савет # 8: Пачатковы аптымізацыя

    Адразу пасля ўстаноўкі Drupal трэба прыступіць да базавай аптымізацыі. Хоць Drupal і хуткі, але калі ёсць магчымасць нешта паскорыць, ёй трэба карыстацца. Працэс аптымізацыі Drupal ўмоўна можна падзяліць на тры групы:

  • Базавая. Рэалізуецца сродкамі рухавічка. Руліць гэтымі параметрамі ты можаш самастойна з панэлі адміністравання адразу пасля завяршэння ўсталёўкі сістэмы.
  • Пашыраная. Для Drupal распрацаваны спецыяльныя модулі, якія дазваляюць павысіць агульную прадукцыйнасць сістэмы (напрыклад, з дапамогай прасунутага кэшавання).
  • Серверная. Пад сервернай аптымізацыяй маецца на ўвазе налада серверных кампанент, якія ўзаемадзейнічаюць з Drupal.
  • Такім чынам, спачатку паглядзім на базавую аптымізацыю. У наладах прадукцыйнасці сістэмы (admin / settings / performance) даступна некалькі налад, якія ўплываюць на хуткадзейнасць. Першае з чаго варта пачаць аптымізацыю - уключэнне кэша. Па змаўчанні ён адключаны і адміністратару даступна два варыянты кэшавання: нармальны і агрэсіўны. Самую вялікую прадукцыйнасць дае агрэсіўны рэжым, але не варта цешыць сябе. Лепш выбраць «Нармальны». Гэта аптымальны рэжым для сайта з вялікай колькасцю зарэгістраваных карыстальнікаў. Калі ж сайт мала наведваем, то ў такім выпадку добрым выбарам стане «агрэсіўны рэжым».

    Раю звярнуць увагу на групу налад «Аптымізацыя прапускной здольнасці». Яна дазваляе актываваць аб'яднанне CSS і JavaScript у адзіныя файлы. Навошта? Справа ў тым, што многія дадатковыя модуля цягнуць з сабой css / js файлы. Пры загрузцы чарговы старонкі, адбываецца зварот да некалькіх файлаў на сэрвэры. А гэта ў сваю чаргу лішнія злучэння. Каб мінімізаваць выдаткі, можна выканаць аб'яднанне. У гэтым выпадку Drupal будзе ствараць адзіны файл з css / js, які і будзе загружацца браўзэрам карыстальніка.

    Савет # 9: Серверныя кампаненты

    З самага пачатку важна зразумець, то хуткадзейнасць Drupal напрамую залежыць ад налады кампанентаў навакольнага асяроддзя. Да такіх адносяцца: web-сервер (гл. Савет 14), СКБД, PHP. Калі хто-то адзін з іх працуе неэфектыўна, то ні пра якую добрай прадукцыйнасці не можа быць і гаворкі. Наладжваць ўсе гэтыя кампаненты можна доўга, але я хацеў бы звярнуць тваю ўвагу на самыя важныя налады.

  • PHP. Увесь Drupal напісаны асабліва на php, таму вельмі важна паклапаціцца пра наладу гэтага інтэрпрэтатара. У канфігурацыйным файле php ёсць куча дырэктыў, але для drupal асабліва важнай будзе php_value memory_limit. Як відаць з назвы, дырэктыва адказвае за аб'ём памяці вылучаемай для выканання сцэнара. Зразумелая справа, чым яе больш, тым лепш. Калі казаць канкрэтна ў лічбах, то вельмі пажадана ўсталяваць значэнне больш 32M (г.зн. больш 32-х мегабайт). Акрамя ўстаноўкі аб'ёму памяці, не менш важнай опцыяй з'яўляецца max_excecution_time (максімальны час выканання сцэнарыя). Звычайна тут выставляеят значэнне ад 30 і вышэй. Чым больш будзе час выканання сцэнару, тым менш ты будзеш бачыць белы экран смерці.
  • Акселератар для PHP. Як бы там ні хвалілі PHP за прастату і хуткадзейнасць, гэты інтэрпрэтатар ўсё роўна павольны і з гэтым цяжка не пагодзіцца. Для выканання кожнага сцэнара, інтэрпрэтатара неабходна спачатку лічыць і разабраць увесь код сцэнара, затым выканаць яго і вярнуць вынікі. Гэта аперацыя праводзіцца пастаянна і на яе траціцца самы каштоўны рэсурс - час. Для вырашэння гэтай праблемы былі прыдуманы так званыя PHP акселератары - праграмы, якія паскараюць выкананне PHP-сцэнарыяў. Паскарэнне дасягаецца за кошт кэшавання байткод кожнага сцэнара. Для дасягнення максімальнай прадукцыйнасці пажадана ўсталяваць які-небудзь акселератар. Адзін з найбольш удалых прадстаўнікоў гэтай галіне - eAccelerator . Ён просты ва ўсталёўцы і наладзе і істотна павялічвае рэакцыю інтэрпрэтатара.
  • СКБД. Часцей за ўсё ў якасці СКБД для web-праектаў выступае MySQL. Ён хуткі, бясплатны, крос-платформавы і валодае ўсімі неабходнымі функцыямі. Па наладзе і аптымізацыі MySQL пішуць цэлыя кнігі. Я не буду лезці ў нетры, а адразу параю ўключыць кэшаванне (у mysql).
  • Савет # 10: Альтэрнатыўнае кэшаванне

    У аптымізацыі не існуе межаў. Заўсёды знойдзецца вузенькую месца прыдатнае для аптымізацыі. Да няшчасця (а можа наадварот) у Drupal такіх месцаў больш, чым дастаткова. Адным словам - працаваць ёсць над чым. Адным з такіх тормозков - убудаваная сістэма кэшавання. Яна працуе добра, але для вялікіх праектаў яе не хапае. Менавіта таму, членамі супольнасці Drupal была распрацавана альтэрнатыўная сістэма кэшавання. Рашэнняў падобнага роду некалькі, але лепш за ўсіх вылучаецца cacherouter (http://drupal.org/project/cacherouter). Праект CR ўяўляе сабой модуль для Drupal і рэалізуе захоўванне кэша ў памяці, з дапамогай магчымасцяў дэмана memcached або акселераторов (APC, eAccelerator, XCache). Вердыкт - рэкамендавана для вялікіх праектаў.

    Савет # 11: Views замест сваіх запытаў

    Як-то раз мне трапіўся сайт на базе Drupal. У ім, у многіх месцах былі панатыркана sql запыты. Распрацоўшчык выкарыстаў іх для высновы ў блокі рознай інфармацыі: апошнія артыкулы, апошнія навіны і г.д. Спосаб мае права на існаванне, але карыстацца ім усё ж не рэкамендуецца. Правільней будзе скарыстацца модулем Views . Ён дазваляе ствараць розныя ўяўленні, і самае галоўнае робіць іх эфектыўна. Табе не трэба разбірацца ў структуры БД. Нават складаныя выбаркі рэальна зрабіць шляхам прымянення візуальнага канструктара. Акрамя таго, пры стварэнні чарговай імпрэзы даступная магчымасць кіраваць кэшаваннем. Пры стварэнні люхт для рэдка змянянай інфармацыі, гэтая магчымасць будзе дарэчы.

    Совет # 12: Drupal.API

    Існуе памылковае меркаванне, Што можна грэбаваць ужываннем API, а выкарыстоўваць старыя дзедаўскі спосаб - прам выкананне SQL запытаў. Вядома, ёсць шэраг задач, вырашаць якія, лепш менавіта такім спосабам. Праўда, такія задачы хутчэй выключэнне. Ва ўсіх астатніх сітуацыях, правільней будзе карыстацца Drupal API. Выклікаючы дакументаваныя функцыі, распрацоўшчык можа быць упэўнены, што яго дзеянні не пацягнуць за сабой негатыўныя наступствы. Да прыкладу, калі для дадання новага карыстальніка існуе спецыяльная функцыя, то ні ў якім разе не трэба паказваць панты і рабіць гэта запытам. У выпадках, калі функцыі мала, то пажадана паглядзець яе зыходнік і ўжо на падставе кода паглядзець выконваюцца запыты, і толькі затым на іх аснове складаць ўласныя.

    Савет # 13: нагрузачнага тэставання

    Ізноў створаны праект лепш адразу падвергнуць жорсткага тэставання. Хоць тройчы закруціць усе балты і гайкі, а шанец, што сайт не вытрымае шквалу наведвальнікаў - ёсць заўсёды. Пажадана адразу выдаткаваць час на нагрузачнай тэставанне і на ранніх этапах выключыць магчымыя правалы. Для правядзення падобных тэстаў добра сябе зарэкамендаваў сэрвіс http://loadimpact.com . Ён прапануе розныя тэсты для праверкі web-праекта на ўстойлівасць да нагрузак. Тэсты ёсць на любы густ і кашалёк. Для сур'ёзнага аналізу маецца pro версія. Яна вядома каштуе грошай, але тэстаў у ёй больш, а такім чынам і карысці ад яе больш адчувальнай. Не палохайся толькі, калі праект падымаецца на грамадскіх пачатках, то хопіць і бясплатнага варыянту. Ва ўсякім разе, ты будзеш пэўны, што твой сайт будзе ўпэўнена сябе адчуваць пры заходзе на яго пяцідзесяці чалавек.

    Савет # 14: Добры індзеец - мёртвы індзеец

    Ні для каго не сакрэт, што алімп web-сервераў ужо шмат гадоў узначальвае Apache. Гэта сапраўды добрае і якаснае праграмнае забеспячэнне, праўда, не занадта хуткае. У звязку з Drupal ён паказвае не зусім добрыя вынікі і пры вялікім наплыве наведвальнікаў становіцца самым вузкім месцам. Часткова перамагчы тормазы дазваляе хардкорный цюнінг, але ператварыць яго ў гепарда ўсё роўна не атрымаецца. Лепш адразу ад яго адмовіцца і забыцца як пра страшны сон. А чым тады ж карыстацца? Вядома ж nginx ! У цяперашні час, nginx мабыць самы хуткі WEB-сервер. Таго ж Apache ён абыходзіць ўжо на старце і практычна нічым яму не саступае (за выключэннем пакуль не большай колькасці модуляў). на праекце VR-Online мы вырашылі адмовіцца ад Apache і цалкам перайшлі на nginx. Прадукцыйнасць ўзрасла на вока. Пры адкрыцці старонак ствараецца ўражанне, што на генераванне патрабуецца часу. Пры выкарыстанні Apache пра гэта можна было толькі марыць.

    Савет # 15: прыручаць nginx

    Nginx цудоўна падыходзіць для Drupal'овских праектаў, але каб усё правільна і выразна працавала, трэба надаць час наладзе. Тут метадам навуковага тыка не абысціся. Прыйдзецца перасіліць сябе і прачытаць аб'ёмную дакументацыю, а таксама паўтарыць ўсе атрыманыя веды на практыцы. Каб неяк палегчыць сабе жыццё, рэкамендую спампаваць конфіг для nginx, спецыяльна створаны для Drupal. Прапанаваны канфігурацыйны файл змяшчае усё неабходнае, для таго, каб Drupal карэктна запрацаваў з nginx. Калі пералічыць магчымасці, якія адлюстраваны ў канфігурацыйным файле, то атрымаецца:

  • Чыстыя url;
  • Мультисайтинг;
  • Падвышаны час выканання fastcgi;
  • Падтрымка boost;
  • І г.д.
  • Савет # 16: Рыхтуйся да Drupal 8

    Не забывай, што распрацоўшчыкі ўжо даўнютка працуюць над стварэннем восьмай версіі гэтага выдатнага фреймворка. Восьмая версія будзе моцна адрознівацца ад папярэднікаў. Разбірацца з вантробамі новай версіі лепш пачынаць прама цяпер.

    заключэнне

    Drupal - ня тыповая cms, якую лёгка наладзіць ў некалькі клікаў мышкай. Каб выціснуць з яго максімум і падняць ня тыповы праект - прыйдзецца павазіцца. Як вынікае павазіцца і пачытаць форумы / дакументацыю. Пасля паспяховага першага праекта ён ужо не будзе здавацца такім страшным і дзіўным. Ня адступай і не здавайся! Спрабуй, эксперыментуй, і я спадзяюся, мае drupal'ные парады табе дапамогуць. Ўдачы!

    Артыкул апублікаваная ў часопісе "Хакер" (http://xakep.ru). Люты 2011 г.

    Спасылка на часопіс: http://goo.gl/lzfLnl

    Заінтрыгаваны?
    Добра, калі трэба абнавіць адзін модуль, а калі іх 10, 20?
    Як у такой нялёгкай сітуацыі карэктна выдаліць вінаваты модуль?
    Савет # 7: Shared хостынг або VPS?
    Навошта?
    А чым тады ж карыстацца?