Вольный перевод статьи The things we found in your site, написанной Hernâni Borges de Freitas, экспертом по Drupal, сотрудничающим с компанией Acquia в области технического консалтинга по архитектуре Drupal, процессам разработки, безопасности и производительности веб-сайтов на Drupal.
Часть моей работы в Acquia включает исследование некоторых из наиболее сложных по архитектуре сайтов клиентов из различных точек земного шара, построенных на Drupal, анализ и выявление известных или неизвестных проблем с ними. Иногда клиенты нанимают нас для выполнения аудита сайтов чтобы понять, что не так с их сайтами в плане поддержки, производительности, работы или безопасности. В других случаях аудит является способом убедиться, что сайт работает нормально, а его команда поддержки не растрачивает впустую время и ресурсы. Мне нравится рассматривать аудит сайта как нормальную проверку, которую необходимо периодически делать применительно к сайту, чтобы быть уверенным, что с ним все нормально и он готов для нормальной работы в будущем.
В следующих своих блог-постах я попытаюсь охватить ряд тем, в которых обычно находятся проблемы при выполнении нами аудита сайтов. Я надеюсь, что это поможет вам избежать аналогичных ошибок при развитии и эксплуатации своих сайтов. Эта статья блога резюмирует содержание семинара, который я провел в этом году во время Drupal Camps в Европе: в Porto, Portugal и в Oxford, UK.
Контент
Контент — это первая вещь, о которой вы должны думать во время планирования своего сайта на Drupal. Продуманная структура контента существенно облегчает построение элементов его отображения на сайте, помогает облегчить обучение редакторов сайта и в целом упрощает управление сайтом. Следует также помнить о важном моменте, относящимся к структуре вашего контента: увеличение количества типов контента и полей, которые вы создаете на сайте, также увеличивает объем используемой памяти на сервере и увеличивает время обработки страниц.
Некоторые наиболее общие ошибки, которые мы находили во время аудита сайтов, включали в себя:
- Создание нескольких схожих типов контента (новости и статьи, например), используемых для одних и тех же целей.
- Создание не используемых в дальнейшем типов контента.
- Создание однотипных по смыслу различных полей для различных типов контента (не использование одного однажды созданного поля в различных типах контента).
- Помещение всего контента в ноды в то время, когда когда не нужно использовать все их свойства и хуки. В некоторых случаях использование новой системы сущностей в Drupal или пользовательских таблиц имеет больше смысла.
Отображение контента
Когда вы заканчиваете моделировать ваш контент, вы начинаете думать о его наилучшем отображении. Общепринятые способы организации отображения контента на сайте, построенном на Drupal, включают в себя создание представлений для выборки нужной информации и отображения ее на сайте; создание блоков и организации их в дисплеи с продвинутыми возможностями с использованием контекста или панелей, или ручной настройкой шаблонов, или использование модулей наподобие display suite.
Вот несколько советов, которые могут пригодится при создании дисплеев (отображений) контента на Drupal-сайтах:
- Views (Представления) — это один из самых удивительных модулей в Drupal: Используйте их везде, где можно. Создание одного представления с различным дисплеями (блок, страница или RSS, например) для показа одних и тех же данных действительно отличная идея, поскольку вы можете съэкономить много времени, легко клонировав их. Используйте контекстные фильтры в одном представлении, позволяющие выводить контент в зависимости от выбранной категории, например.
- Модули Contexts/panels/display suite имеют различное назначение и могут быть использованы в различных ситуациях. На эту тему была отличная дискуссия во время последнего DrupalCon в Мюнхене (http://munich2012.drupal.org/program/sessions/different-ways-control-your-layout).
- Использование PHP кода в блоках/нодах — почти всегда плохая идея. Даже если это кажется наиболее легким и быстрым способом добавить небольшую функциональность на сайт, всегда очень сложно обнаружить и исправить проблемы, если они вызываются подобным кодом. В большинстве случаев я рекомендую своим клиентам отключать PHP-фильтр во избежание соблазна использовать PHP-код на сайте.
- Внимательно присмотритесь к конфигурации ваших блоков и поймите, какие из них отображаются на различных страницах. По возможности следует отключать блоки на тех страницах, на которых они не нужны — это сбережет ресурсы сервера, затрачиваемые на их построение и обработку.
Когда у вас возникнут сомнения в том, что вы следуете лучшим практикам во время создания или изменения дисплеев для отображения контента на вашем сайте, задайте себе простые вопросы:
- Поймите, как строятся ваши страницы. Чем меньше пользовательского кода используется для их обработки, тем меньше усилий потребуется для поддержки и обновления сайта в будущем.
- Можете ли вы повторно использовать некоторые из представлений и панелей, изменив их поведение с помощью контекстных фильтров, взамен создания новых панелей и представлений для различных ситуаций?
- Насколько легко переключить тему оформления в вашем сайте (для мобильных устройств, специальных случаев или для смены дизайна)?
Архитектура сайта
Когда вы хотите добавить больше функций на ваш сайт, то начинаете выбирать из готовых дополнительных модулей, писать собственный код или интегрировать ваш сайт с другими платформами. Это одна из тех областей, где совершается больше всего ошибок.
- Для Drupal создано невероятно большое количество дополнительных модулей (на момент написания этой статьи для моего блога, на Drupal.org доступно 18368 модулей. Прежде чем писать свой собственный модуль, поищите на drupal.org среди готовых модулей такой, который бы мог решить ваши задачи. Если вы найдете модуль, который делает что-то схожее с тем, что вам нужно, но не делает чего-то другого, более специфического, возможно, имеет смысл дописать недостающий функционал и предложить его в виде патча к имеющемуся модулю. Поиск и использование готовых дополнительных модулей почти всегда более выгодно по сравнению с написанием собственного кода, который вам придется поддерживать и обновлять в будущем. К сожалению, я могу рассказать вам не одну историю своих клиентов, которые решили разрабатывать собственные модули не зная о существовании уже готовых модулей с аналогичным функционалом.
- Постарайтесь использовать правильное количество модулей. Обычно сложные сайты используют от 100-150 модулей. Если вы в верхнем конце этого диапазона, проверьте, что действительно инсталлировали эти модули. Чем больше модулей вы устанавливаете, тем больше ресурсов будет потреблять ваш сайт.
- Ядро Drupal и его API уже делают большинство их того, что ожидается от современных веб-фреймворков. Перед тем как начать реализовывать какую-нибудь специфическую бизнес-логику, которую вы использовали до перехода на Drupal, или видели в других фреймворках, проверьте, не реализована ли она уже в ядре Drupal, его API или в дополнительных модулях.
- Не вносите свои изменения в код ядра или код дополнительных модулей. Ок, если вам действительно нужно сделать это, обязательно задокументируйте внесенные изменения! Лучший способ документирования изменений это размещение патчей в корневой директории сайта. Патчи позволяют другим разработчикам понять внесенные изменения и упростить процесс обновления модулей и повторного внесения изменений. Если вы работаете в команде разработчиков или возглавляете ее, и не уверены, был ли изменен ваш код, модуль Hacked! (http://drupal.org/project/hacked) сможет помочь вам понять это, сравнив код на Drupal.org с вашим собственным.
- При разработке собственных модулей убедитесь, что следуете стандартам кодирования для Drupal (http://drupal.org/coding-standards). Следование стандартам кодирования поможет другим разработчикам лучше понять ваш код. Если при просмотре кода модуля обнаруживается, что он был написал без учета стандартов кодирования для Drupal, это обычно первый сигнал того, что у модуля и сайта, его использующего, могут быть и более серьезные проблемы. Модуль кодера (http://drupal.org/project/coder) может помочь вам проанализировать код любого модуля и проверить, следует ли этот код стандартам кодирования для Drupal.
Вопросы построения архитектуры программного обеспечения возникают не только в начале проекта, но и в процессе его жизненного цикла. Не пренебрегайте периодическим пересмотром и анализом архитектуры вашего сайта: изменения, случающиеся на вашем сайте или в мире Drupal, иногда дают новую возможность упростить или улучшить что-нибудь на вашем сайте.
В своей следующей статье я обращусь к проблемам, связанным с безопасностью, производительностью, инфраструктурой и поддержкой. Мы также рассмотрим пару неплохих инструментов, которые могут помочь в выявлении некоторых их наиболее типичных проблем.