best_practicesx

Гид по построению сайта
Это гид по настройке "как и что" для реализации бизнес-функциональности и возможностей
в ваш сайт.
За информацией по управлению и текущим операциям на сайте Друпал, смотрите Administration
Guide. За информацией по разработке базовой информационной структуры используя меню,
таксономию, блоки и т.д., смотрите Structure Guide.







Лучшие советы
Построение функциональности сайта
Вспомогательные модули
Модули Ядра
Дистрибутивы
Как и что
Рецепты сайтов
Лучшие советы
"Не существует сайта настолько маленького, чтобы он был не важен для кого-нибудь"
Если вы собираетесь вложить время для установки CMS, тогда вы должны защитить ваше
вложение последовав нескольким простым советам. Это просто рекомендации. Решать вам - что
соответствует вашему сайту.
Следующий список содержит несколько моментов (для более детальной информации, смотрите
список статей внизу страницы):
o Спланируйте ваш сайт. Друпал предоставляет хороший инструментарий, чтобы помочь вам
построить ваш сайт, но вам все равно нужен план. Хорошее планирование каркасов
поможет избежать значительных непониманий и проблем в дальнейшем.
o Планируйте на будущее. Вы должны посещать и обновлять ваш сайт каждый раз когда
выходит новая основная версия Друпала (7, 8). Это не означает, что вы его обновите, но вы
должны оценить и спланировать апгрейд примерно каждые 12-24 месяца.
o Будьте вовлеченными в сообщество. Это поможет вам следовать за трендами разработки
и помогая другим, к вам может прийти блестящая идея, которая решит вашу собственную
задачу.
o Резервируйте ваш сайт. Сохраняйте оба: базу данных и файлы на веб сервере. Проверяйте
ваши бэкапы!
o Используйте PHP сниппеты умеренно и осторожно. Друпал дает вам хорошую
возможность в мощности и гибкости, когда используется PHP код в блоках. К сожалению,
забытая буква или точка с запятой ломает PHP. Друпал тогда делает попытки оценить этот
сломанный код на каждой запрашиваемой странице, PHP интерпретатор спотыкается на
нем и тогда ваш сайт ломается. Что еще хуже, PHP сниппет, введенный неавторизованным
пользователем может подвергнуть ваш сайт хакерской атаке. Снаружи тот, кто имеет
доступ к PHP на вашем сайте может читать и вписывать что угодно в вашу базу данных,
делать все что они захотят. Вы должны быть осторожным чтобы не дать права
пользователям использовать PHP формат никому, кроме доверенных разработчиков сайта.
Когда создается блок, который использует формат ввода PHP, вы можете избежать риск
иметь неработающий блок внутри вашего сайта, в первую очередь, тестированием кода
внутри временной записи или ноды страницы. Юзайте PHP код, пишите код, отлаживайте
от багов ваш код. Когда вы удовлетворены в том, что ваш код работает, скопируйте и
вставьте код в блок.
Резервируйте вашу базу данных и файлы
База данных и файлы настроек это важно.
Есть много постов в топиках форумов по поводу невосстановимых ошибок, WSOD, как сдохла база
данных и т.д. Бывают времена, когда вы посещаете ваш сайт криво или замечаете, что то
удаленным или испорченным, и лучшим решением будет восстановить из запасного архива.
Backup & Migrate
Модуль Backup&Migrate может делать срочное восстановление и миграцию сайта. Вы можете
настроить его на автоматическое резервирование? сохраненное в файловую систему - с самыми
частыми резервированиями во время разработки.
Вы можете также создать вручную выполнять резервирование перед какими-либо сложными
настройками. В этом случае вы имеете "точку восстановления" в случае катастрофы.
Так как могут возникнуть некоторые вопросы с безопасностью когда вы сохраняете базу данных и
контент в виде файла (вы можете исключить конкретные таблицы) преимущества наличия отката в
случае катастрофы становятся значительными.
Модуль также облегчает миграцию сайта. Я просто переношу сложный сайт с Views, APK, CiviCRM,
с более 12000 файлами. Я перемещаю файлы, созданные новой базой, с изменёнными
settings.php и civicrm.php для новой базы, экспортирую сайт из существующего сайта и
импортирую его в базу нового сайта с помощью phpMyAdmin - и сайт перенесен! (Иногда я
копирую файлы, делаю стандартную установку, включаю модуль Backup & Migrate, и импортирую
db в интерфейсе модуля - так тоже работает).
Drush archive-dump
Drush (Drupal Shell) - утилита командной строки, которая может создавать архив ваших файлов и
базы командой archive-dump также включен с модулем Backup & Migrate. Чтобы юзать Драш вам
нужно иметь доступ к терминалу (SSH) на вашем сервере и быть способным установить и
настроить Драш.
Интерфейс командной строки
Если ваш хостинг дает вам доступ, вы всегда можете выполнить сохранение базы данных с
помощью команды mysqldump.
Никогда не хакайте ядро
Эта фраза является сердцем в сообществе Друпала. Вы можете увидеть ее на футболках или
стокерах. Эта одна из самых важных советов для друпла.
Под "ядром" понимается все файлы входящие в оригинальную инсталляцию Друпала. Это все
файлы за исключением одной лишь папки "sites". Вы можете добавить профили установки в
директорию "профили", но не модифицировать что либо, что уже там есть.
Почему же мы не должны модифицировать файлы ядра
Не важно, насколько легко модифицировать файлы ядра чтобы Друпал сделал то что вам надо,
сохраните оригинал.
o Делая это, будет тяжело или даже невозможно применить к сайту обновления
безопасности и баг фиксы.
o Вы сделаете ядро сложным для тех кто придет после поддерживать сайт.
o Вы можете сделать сайт уязвимым.
Ядро Друпала спроектировано быть модульным, так что нет никаких причин взламывать его. Если
нет фичи, которую вы хотите и если невозможно реализовать внешними модулями, отправьте ваш
взлом как патч. Создайте "вопрос" и сообщите сообществу фичу, которую вы хотите реализовать.
Тогда будет тестирование и ваша фича может стать частью ядра Друпала.
Исключения
Есть ли какие-то исключения для этого правила?
Нет.
Ну ладно, может быть. Но это только для специфичных сайтов или реализаций людей, которые
экстремально знакомы с кодовой базой Друпала, экспериментов по разработке и моделей
безопасности. Те, кто надлежащим образом задокументировали их модификации и провели
надлежащую контрольную проверку с их кодом. Если у вас есть вопросы, значит скорее всего вам
нельзя.
Избегайте хардкодинга
Соблазн к хардкодингу случается с лучшими из нас - вот почему лучшие из нас всегда имеют риск
быть уничтоженным этим.
Определение хардкодинга
Хардкодинг - это практика приспособления кода, чтобы управлять очень специфичными
ситуациями. Здесь несколько примеров хардкодинга который применяется к Друпалу:
o Вставка SQL запроса в файл .tpl
o Написание скрипта, который запрашивает базу данных, чтобы сделать некоторые
изменения в нодах
o Использовать регулярные выражения на выходе функции теминга, чтобы изменить один
HTML класс в другой
Примеры выше могу работать, иногда, или даже все время. В то же время, хакинг ядра,
эффективности, все это недостаточно соответствует "Пути Друпала". Всегда когда хардкодинг
работает - и чаще всего это не работает как надо - это становится платой за счёт управления более
общим числом ситуации.
Почему вы должны избегать хардкодинг
Никто не будет хардкодить свой Друпал сайт, если это выглядит плохой идеей для них. В тоже
время, есть много выложенных исправлений на Drupal.org, которые сделаны на хардкодинге, так
или иначе. Это потому что хардкодинг часто привлекательнее кодерам, которые увлечены или
только учатся. Они видят способ сохранить много времени, и вскоре они становятся правыми.
Проблема в том что хардкодинг имеет скрытую плату и может стоить еще большего числа
времени.
Комментарии, такие как "Не вставляйте код в слой темы" или "используйте систему хуков" общие,
и представляют предостерегающее оповещение по поводу хардкодинга. В тоже время, это может
быть сложным для новых Друпаллеров, найти предписывающую информацию говорящую о том,
почему хардкодинг обычно плохая идея.
Что-ж, здесь некоторые специфичные примеры где хардкодинг может создать проблемы по пути:
o Разрабатываете тему
Вы добавляете настроенный SQL запрос, чтобы извлечь и показать информацию о числе
сохраненных единиц которые имеет юзер. Теперь вы хотите использовать эту тему на
разных установках Друпала. Что если другая инсталляция имеет другой набор имен таблиц,
или использует отличающийся модуль чтобы хранить инфу о пользователе, которая
требует другой последовательности связей? Ваш настроенный запрос как раз очень
пригодится.
o Вы спроектировали продуманную функцию по извлечению и отображению инфы юзера.
Это заканчивается тем, что очень нагружает процессор, и ваш клиент захочет закэшировать
их результаты. Что если вы не предвидите потребность в работе с существующим
механизмом кэширования Друпала?
o Вы хотите изменить тему сайта на основе того какой баннер показывать на сайте
В тоже время, ваш код выбирает случайный баннер расположенный в page.tpl сайта. Это
означает, что вы не можете узнать какой баннер будет показан, когда страница уже
отрендерена в точке, когда такая функция вызывается. Что, если HTML до этого нужно было
изменить?
o У вас есть пять вариантов тем, используя различные файлы шаблонов.
Каждый из них имеет хардкодированный запрос разработанный вами. Если этот запрос
надо изменить, вам сразу же надо будет сделать тоже в 6 местах - ой я сказал пять? Я
должно быть забыл, что мобильная тема сайта находится в совершенно разных папках. Вы
же не хотите забыть, что ни будь, вроде этого?
o Кто ни будь еще начинает работать с вашим кодом.
Если вы используете хардкоденное решение, имеют ли они какие-нибудь идеи что будет
дальше, в последующем использовании ими Друпала? Запомните, если это что-нибудь
отличное от вашего персонального блога, кто-нибудь еще может запутаться с вашим
проектом. Но если это только ваш блог, как вы можете знать, насколько хорошо вы будете
помнить ваш код через год?
Запомните, главная причина по которой хардкодинг проигрывает - это непредвиденные факторы.
Чтобы перейти по запросу от страницы к предоставленной друпалом странице, требуется чтобы
ваш сервер выполнил сотни функции. Используя существующие Друпал хуки, вы существуете
среди нормального ожидаемого процесса этих операций. Вы полностью осознали все пути по
которым эти функции взаимодействуют? Если нет, ваш выбор оперировать вне рабочего
пространства друпла, иметь какое-то неточное значение риска для вашего сайта/ вас/ ваших
животных.
Исключения
Несмотря на все вышесказанное, хардкодинг отличается от хака ядра в одном решающем случае:
Есть много легитимных вариантов использования этого, и большинство Друпал разработчиков
делают это время от времени. Иногда, вы знаете что вам нужно сделать что то вручную в
определенных случаях, и это эффективный способ сделать это. Как пример, вам нужно отобразить
Тему Haloween на конкретной ID ноды, которую вы используете один раз в год. Юзать модуль
чтобы добавить форму опции по выбору темы, может быть нежелательным, если вы знаете, что
никогда не будете использовать это.
Если вы собираетесь хардкодить, примите предупреждение, что придется постоянно спрашивать у
опытных, если конкретно не знаете, что и где сделать. Или, если вы не уверены, это станет еще
более опасным.
Объединение настроек сайта используя Features
В Друпал 7, настройки сайта и конфигурация сделаны экспортируемыми, юзая модуль CTOOLS.
Модуль Features делает по известному методу объединение этих экспортов в новый загружаемый
модуль. Drush Ctools Export Bonus делает более легким выполнение экспорта настроек сайта.
Итак, есть такая штука: если кто-нибудь спросит вас как сделать блог на Друпал сайте, вы не
говорите им активировать модуль Блога (что уже и так готово). Вы говорите им, что блог проще
сделать с помощью CCK, Views - и несколько настроек, которые могут составить 2-3 страницы
печати.
Features Module сокращает работу с настройками, предоставляя удобные значения для
"объединения", настройки импорта и экспорта для многих из самых используемых модулей
Друпала.
Посмотрите это быстрое интро. Features меняет парадигму разработки сайта от его настройки к
включению фич.
Drush CTools Bonus Export
позволяет вам экспортировать более дюжины типов настроек Друпала
в их собственные файлы. Например экспортинг меню в modulename.ctex_bonus.menus.inc.
Основные преимущества
o Новички в Друпале могут быстро построить блог, галерею картинок и кучу других фич,
будучи готовыми вставить настройки.
o Разработчики могут легко пере-использовать настройки в самых используемых модулях,
включая ССК (imagecache), Views, Panels, Context, more...
o Разработчики могут легко поставлять свои конфигурации клиентам и разрабатываемым
сайтам - и обновлять существующие. Тут интересное обсуждение по поводу "серверов
поставки фич” - Для тех из вас, кто юзает Drush: Есть несколько удобных Драш команд по
управлению Features. (Документация еще пишется). Для тех, кто не использует Драш:
попробуйте !
Далее в оригинальной документации идут подробности по использованию модуля Features.
Пока перевод оставляю до востребования.
Убедитесь в безопасности вашего сайта
Гид безопасности Друпала имеет раздел по защищенности вашего сайта с удобным списком
единиц с которыми работать.
Модуль Security Review предоставляет автоматический обзор возможных проблем безопасности.
Drupal имеет "Команду безопасности", которая работает с обращениями по вопросам
безопасности ядра Друпал и модулей.
Другие рекомендации по повышению безопасности Друпала могут быть найдены здесь:
http://www.madirish.net/?article=490
Юзайте тестовые сайты
Есть много программ (XAMPP, MAMP, Apache2Triad) которые могут помочь вам установить
локальную тестовую систему легко. Вам нужно поиграться с вашим сайтом и протестировать
резервные копии и восстановление сайта-продукта. Установите тестовый сайт, юзая копию ваших
живых данных. Вам же не хочется спрашивать на форумах, как спасти ваш сайт. Вы упорно
работали, чтобы построить его ,будет печально все это потерять.
o Никогда не делайте разработку или тестирование на вашем живом сайте - продукте.
Друпал устанавливается быстро и легко. Всегда вначале тестируйте на тестовом сайте.
o Проверьте как работает ваша резервная копия и что вы знаете, как восстановить ваш сайт.
Тестовая система может быть вашей локальной десктопной системой, если пожелаете. Вы
же не хотите познать тяжелый путь, когда вы забываете файл или не знали, как как сделать
восстановление, если ваш сайт рухнет.
o Проверьте процедуру апгрейда прежде чем подвергать риску ваш живой сайт и
задокументируйте ваши шаги, которые вы сделали. Документация поможет все повторить
если нужно. Тестирование может быт сделано с помощью Simpletest
За большей информацией по инсталляции тестовых сайтов, пожалуйста смотрите setting up a
development environment и getting started sections. Тут несколько специфичных примеров
копирования сайта-продукта на тестовый/разрабатываемый инструментарий в конкретных
случаях после инсталляции.
Становление вашего сайта вживую
Выполнив инсталляцию Друпала, остается совсем чуть-чуть финальных приготовлений, прежде
чем вы выложите его миру.
Перемещение из временного места
Например, если вы положили Друпал в субдиреторию на вашем сервере, так что оно не
пересекается с вашим существующим вебсайтом в то время как вы делаете его установку. Чтож у
вас есть www.example.com показывающий ваш старый сайт, и вы хотите показать миру ваш новый
сайт на этом же адресе. Есть два варианта по которым вы можете пойти:
Перемещение Друпала
Для новейших версий Друпала, перемещение основного каталога Друпала не должно создать
каких-либо проблем. Для версий вплоть до 5, некоторые настройки может быть надо поменять
чтобы Друпал мог найти все что надо. Смотрите этот топик за деталями:
Переназначение вашего сервера
Альтернативно, вы можете покинуть Друпал когда он находится в субдиреторию, и оставить
пустым, чтобы любой заходящий думал, что эта папка есть www.example.com
С Apache, вам надо добавить следующее в .htaccess в root папке (или создать .htaccess файл если
его там нет):
RewriteEngine on
#
# stuff to let through (ignore)
#RewriteCond %{REQUEST_URI} "/folder1/" [OR]
#RewriteCond %{REQUEST_URI} "/folder2/"
RewriteRule (.*) drupal/$1 [L]
Юзайте правила RewriteCond чтобы дать URLs без модификаций (например вы хотите, чтобы
другие субдиректории могли быть доступны и далее). Замените "друпал" именем папки Друпала.
Вам также надо модифицировать файл settings.php для вашего сайта. По стандарту, он в
sites/default/settings.php
Раскомментируйте (измените) линию, которая содержит $base_url, и назначьте его на URL
который вы хотите чтобы видели браузеры как основной вашего сайта.
$base_url = 'http://www.example.com';
Другими словами, убедитесь, что оно не включает субдиректорию Друпала. Это изменит ссылки
которые Друпал генерирует так что они прикрепятся к нужной локации.
Исключение путей из Друпала
Может быть так, что ваш сайт сделан из компонентов, отличных от Друпала, или что вы имеете
архивную версию вашего старого сайта который вы хотите видеть. Друпал в главной папке
держится поверх всех URLs, Друпал в субдиректории обманут, думая, что это главная папка.
В любом случае файл htaccess в главной папке должен быть изменен, чтобы позволить Друпалу
игнорировать пути к папкам и файлам.
В этом случае, когда Друпал в главной папке, вот что нужно сделать:
1. В файле .htaccess вашего веб-сервера, найдите раздел помеченный комментариями
"#Various rewrite rules".
2. Ниже "RewriteEngine on" но до любых других правил, добавьте строки следующих форм:
RewriteRule /folder - [L]
# a subfolder Drupal should ignore
RewriteRule /file.html - [L] # a file in root Drupal should ignore
"Эта страница в процессе разработки. Пожалуйста приведите другие примеры которые должны
быть показаны"
Доступность информации. Инструменты и советы для
сайтостроителей
Во-первых почитайте Drupal Accessibility Statement. Далее есть множество вещей, которые вы
можете сделать, чтобы ваш Друпал сайт стал более доступным:




Начните с Accessibility Checklist
Выбирайте хорошие темы или разработайте свою собственную. Старт с хорошей темой это
быстрейший путь к доступности Друпал сайта. Темы, создатели которых делают Друпал 7
залогом Доступности это хорошее место для старта.
Гид по Доступности Тем Друпала
The Eleven Most Accessible Drupal 6 Themes… evaluated with XHTML, CSS, WAVE and FAE
Evaluators (off-site link).

D-theme breaks down Drupal themes by passing: US 508, Wave, WCAG A, WCAG AA,
and WCAG AAA (off-site link).


Выбирайте доступные вспомогательные модули. Вопросы по Доступности в модулях.
Определяйте вопросы доступности, общайтесь там, отправляйте патчи, тестируйте патчи.
 Drupal Core Issues tagged with Accessibility
 Accessibility Core Improvements
Тренируйте авторов и предоставьте им хорошие авторские инструменты.
 Add author appliable styles to FCK editor
Проверяйте и тестируйте контент




Применяйте фиксы, разработанные другими.
 Accessible Date Inputs on Forms. Хорошо описанный процесс для теминга. Публика:
темеры и кодеры.
 Модули которые помогают с Доступностью
Убедитесь, что разница в цвете это не единственный путь передавать важную
информацию, например, рабочий ли пункт.
Когда вы выбираете цветовые схемы, убедитесь, что есть достаточный контраст между текст и
картинками и задним планом для людей с меньшим, чем превосходное зрением, чтобы можно
было четко видеть разницу между текстом и картинками.
Соблюдайте контраст когда смешивайте цвета
Если вы уже убеждены, что контраст важен, прочитайте Color and Contrast в руководстве по
Темингу, чтобы изучить инструменты которые вам можете использовать, чтобы оценить, и, если
надо, назначить контраст к парам цветов.
Ресурсы по Доступности Друпала




Contributed Modules to Help with Accessibility

DrupalCon Chicago 2011:Free and Open Source Tools for Integrating Web Accessibility into
the Design Process




DrupalCon Chicago 2011:Advanced Accessibility in Drupal

How to Use Drupal 7 to Meet Your Accessibility Goals (must log into Acquia site to access
webinar)
Drupal Group on Accessibility
Video and Slideshow from Drupalcon Szeged 2008
DrupalCon SF 2010: Accessibility in Drupal 6 and Drupal 7: Write accessible modules and
themes
DrupalCon Chicago 2011:Intro to Accessible Site-Building in Drupal
DrupalCon Munich 2012: Accessibility of Custom User Interface Components using WAI-ARIA
DrupalCon Sydney 2013: Creating dynamic and accessible content in Drupal 7 using WAIARIA
Замечания по доступности в Друпал 7
Есть некоторое число изменений в ядре Друпала 7, которые будут отлично помогать с
Доступностью. Друпал 7 выглядит улучшенным в формах API (FAPI), и также является
стандартизованным путем сделать описательный текст видимым для скрин-ридеров и
невидимым для зрячих людей. Чтобы реализовать это в ваших шаблонах вы можете просто
завернуть элементы в CSS class=''element-invisible”. Чтобы реализовать это в модуле вы можете
использовать этот кодовый сниппет:
<?php
l(t('Read more...<span class="element-invisible"> about %title</span>', array('%title' =>
$node->title)), 'node/' . $node->nid, array('html' => TRUE));
?>
Альтернативная реализация:
<?php
$link['title'] = '<span class="icon"></span>' . $item['link']['title'];
$link['attributes'] = array('id' => 'toolbar-link-' . $id, 'class' => array('to-overlay'));
if (!empty($item['link']['description'])) {
$link['title'] .='<span class="element-invisible">' . $item['link']['description'] .
'</span>';
$link['attributes']['title'] = $item['link']['description'];
}
?>
Про доступность веб информации:




W3C Validation (basic requirement!)
Dive Into Accessibility
Paciello Group
W4A - W3C Web Accessibility Conference - ("Web for Anyone")
Техники и советы для HTML, digital media, JavaScript






i CITA HTML Best Practices has HTML and Javascript best practices with examples categorized
by navigation, text equivalents, scripting, and style.
Accessible Digital Media by WGBH Boston has fairly concise best practices with excellent examples
categorize by images, forms, tables, digital publications, interactivity, graphs, math,
and multimedia.
iCITA ARIA Examples has examples of ARIA widgets and roles such as grids, menu bar, slider,
tooltip, and tree.
WAI-ARIA Best Practices outlines how Rich Internet Application such as drop down menus, sortable
grids, live content, etc. can be more accessible through ARIA tagging.
Research-Based Web Design and Usability Guidelines from the U.S. Department of Health and
Human Services has long and detailed best practices categorized by page layout, navigation,
scrolling and paging, headings, titles, and labels, links, text appearance, lists, widgets, graphics and
multimedia, writing, content organization and more.
Quick Reference on WCAG 2.0 Requirements is actually quite long but fairly detailed.
Standards




Illinois Information Technology Accessibility Act (IITAA) Web Accessibility Standards
Section 508 Information Technology Accessibility Standards
W3C Web Content Accessibility Guidelines (WCAG) 1.0
W3C Web Content Accessibility Guidelines (WCAG) 2.0
Tools for evaluating accessibility




http://fae.cita.uiuc.edu/ Functional Accessibility Evaluator
http://wave.webaim.org/ WAVE for evaluating accessibility
Bobby – an automated checking program for compliance with Section 508
Usablenet.com LIFT
Programming tools for accessibility


ARIA Accessible Rich Internet Applications (Making Ajax and Related Technologies Accessible)
AxsJAX - Access-Enabling AJAX
Keyboard only users
Disabling your mouse & navigating a site with your keyboard can be a very humbling experience.
Generally this isn't enabled by default but in advanced preferences you can enable keyboard only
navigation. There are articles on how to do this Macintosh and specific instructions
for Chrome, Firefox, Opera and IE8. A table of other keyboard shortcuts is available from WikiPedia
Screen readers

www.tiresias.org – a site with information on many assistive devices for vision impaired users













Wikipedia screen reader capabilities
Wikipedia list of screen readers
JAWS
Window-Eyes
computer quotes
Gnome's Orca
Hal
Narrator (free in Microsoft Windows)
ZoomText from Ai Squared
Fangs - the screen reader emulator (Firefox extension)
NVDA (NonVisual Desktop Access) - is a free and open source screen reader for the Microsoft
Windows
Guidelines for Accessible and Usable Web Sites: Observing Users Who Work With Screen Readers
Web Anywhere
Чтобы почитать про Вопросы по Доступностиинформации во Вспомогательных модулях,
перейдите по адресу: http://drupal.org/node/425494
Избегайте слишком много модулей
Всегда хорошо сначала подумать перед установкой модуля; слишком много модулей могут
замедлить ваш сайт и хитрить во время обновления особенно на общих серверах, так как их
максимально разрешенный лимит железных ресурсов намного меньше чем VPS и выделенныех
серверов. К тому же, модули, которые плохо поддерживаются и содержат баги, могут быть
вредными для безопасности и стабильности вашего сайта.
Каждому вебсайту потребность в ресурсах широко меняется так что следующие заметки служат
грубыми советами, а не строгим руководством:





Для малого вебсайта на общем хостинг-сервисе: 20 или меньше модулей должны
предоставлять множество гибкости и функциональности, сохраняя при это хорошее
выполнение сайта.
Для сайтов средней сложности: 20-50 модуле может быть более-менее адекватным.
Хороший сайтостроитель способен взять больше функциональности при меньшем
количестве модулей. Вы можете начать ощущать короткие задержки общего хостинга и
возможно рассмотрите переезд на VPS.
Если ваш сайт очень сложный и должен удовлетворять много, много разных случаев
использования: 50-100 модулей могут стать необходимостью. Общий хостинг-сервис может
держать сайт, но производительность должна быть неадекватной.
Если вы имеете 100-150 модулей включенных на вашем сайте, вы либо имеете очень
сложный вебсайт или есть более эффективные способы построить ваш сайт – рассмотрите
удаление модулей и нахождение более простых решений для ваших случаев.
Если вы имеете более 150 модулей включенных на вашем сайте – либо ваш друпал сайт
управляет NASA или вы имеете серьезную зависимость от модулей, возьмите помощь.
Важно исследовать самые поддерживаемые модули, такие как Views, Rules, Panels, и другие до
установки большого числа разных модулей на ваш сайт. Функциональность этих модулей может
часто смягчать потребность устанавливать множество других модулей на ваш Друпал сайт.