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. Якщо перед тобою постало завдання знайти і розгорнути подібний софт, то обов'язково придивися до цього продукту. Він швидкий, функціональний, безкоштовний і при гострій необхідності його можна допив під себе. Набір ключових функцій наводжу нижче:

Рада # 2: рулимо Drupal'ом з командного рядка

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

З усіх можливостей drush я найчастіше користуюся функцією оновлення модулів. Стандартний процес завантаження апдейтів славиться своєю занудно. Спочатку потрібно скласти список оновиться модулів, потім зайти на офіційний сайт Drupal і перейти на сторінку модуля. Потім завантажити його, перемістити в потрібну директорію, виконати скрипт оновлення і т.д. Гаразд, якщо потрібно оновити один модуль, а якщо їх 10, 20? Запросто можна збожеволіти! Куди веселіше виконувати цю процедуру за допомогою Drush. В цьому випадку достатньо скористатися командами up і upc. Видалення / відключення нових модулів виконується аналогічним чином. Наприклад, для видалення модуля передбачена команда:

Крім перерахованих смакоти, 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 не для мене". Частково їх можна зрозуміти, тому що Темізація - одна з найскладніших і незрозумілих речей. Потрібно докласти зусиль, щоб добре освоїти цей процес і застосовувати його в подальшому без сучка і задирки. Щоб процес освоєння проходив більш гладко і зрозуміло, то я б рекомендував тобі виконати кілька простих кроків.

Рада # 7: Shared хостинг або VPS?

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

Якщо сайт мало відвідуваний, то все ok. В іншому випадку, відвідувачі будуть часто бачити білий екран смерті, ніж очікуваний ресурс. Виходячи з вищесказаного, раджу не використовувати shared-хостинг для розміщення більш-менш відвідуваного ресурсу. Краще трохи витратити грошей і придбати VPS, де ти будеш головним господарем і будеш сам визначати настройки всіх серверних компонент (включаючи ОС).

Рада # 8: Початкова оптимізація

Відразу після установки Drupal потрібно приступити до базової оптимізації. Хоч Drupal і швидкий, але якщо є можливість щось прискорити, їй треба користуватися. Процес оптимізації Drupal умовно можна розділити на три групи:

Отже, спочатку подивимося на базову оптимізацію. В налаштуваннях продуктивності системи (admin / settings / performance) є кілька налаштувань, які впливають на швидкодію. Перше з чого варто почати оптимізацію - включення кеша. За замовчуванням він відключений і адміністратору доступно два варіанти кешування: нормальний і агресивний. Найбільшу продуктивність дає агресивний режим, але не варто спокушатися. Краще вибрати «Нормальний». Це оптимальний режим для сайту з великим числом зареєстрованих користувачів. Якщо ж сайт мало відвідуваний, то в такому випадку хорошим вибором стане «агресивний режим».

Раджу звернути увагу на групу налаштувань «Оптимізація пропускної спроможності». Вона дозволяє активувати об'єднання CSS і JavaScript в єдині файли. Навіщо? Справа в тому, що багато додаткові модуля тягнуть з собою css / js файли. При завантаженні чергової сторінки, відбувається звернення до декількох файлів на сервері. А це в свою чергу зайві сполуки. Щоб мінімізувати витрати, можна виконати об'єднання. В цьому випадку Drupal буде створювати єдиний файл з css / js, який і буде завантажуватися браузером користувача.

Рада # 9: Серверні компоненти

З самого початку важливо зрозуміти, то швидкодія Drupal безпосередньо залежить від налаштування компонентів зовнішнього середовища. До таких належать: web-сервер (див. Рада 14), СУБД, PHP. Якщо хтось один з них працює неефективно, то ні про яку хорошою продуктивності не може бути й мови. Налаштовувати всі ці компоненти можна довго, але я хотів би звернути твою увагу на найважливіші настройки.

Рада # 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. Якщо перерахувати можливості, які відображені в файлі конфігурації, то вийде:

Рада # 16: Готуйся до Drupal 8

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

Висновок

Drupal - не типова cms, яку легко налаштувати в кілька кліків мишкою. Щоб вичавити з нього максимум і підняти не типовий проект - доведеться повозитися. Як випливає повозитися і почитати форуми / документацію. Після успішного першого проекту він вже не буде здаватися таким страшним і дивним. Чи не відступай і не здавайся! Спробуй, експериментуй, і я сподіваюся, мої drupal'ние поради тобі допоможуть. Успіхів!

Стаття опублікована в журналі "Хакер" (http://xakep.ru). Лютий 2011 р

Посилання на журнал: http://goo.gl/lzfLnl