Официального документа, отражающего принципы сообщества Drupal, в природе не существует, поэтому здесь предлагается наша версия, собранная из публичных материалов и вербализованных принципов, устоявшихся внутри сообщества.
Философия Drupal — также известная, как Drupal Way — это набор основных принципов и ценностей сообщества. Если коротко, то их можно описать фразой: Stop reinventing the wheel and you'll have more time and energy to design a spaceship.
¶Мы следим за качеством кода
Drupal-разработчики очень трепетно относятся к качеству кода, который они пишут. В сообществе имеются официальные стандарты кодирования, которые должны соблюдать все, кто пишет код под Drupal. Данные требования выработаны годами, имеют под собой основания и охватывают как PHP, так и CSS, JS, HTML.
Цель данных стандартов и жестких требований очень проста: код, написанный для Drupal — как для ядра, так и сторонних модулей — должен читаться как свой собственный. Это позволяет быстро ориентироваться и понимать, что делает тот или иной файл, или функция.
¶Мы не хакаем ни ядро, ни модули
Drupal предоставляет все возможные инструменты для того, чтобы разработчики сторонних модулей могли внедряться в работу других модулей или ядра, на различных этапах выполнения, тем самым срезая на корню необходимость писать свой код напрямую в ядре или стороннем модуле.
¶Будьте открытыми и вносите свой вклад
Drupal является OpenSource системой, весь его код свободен и открыт для всех. Это же касается и модулей, которые для него разрабатываются. Взамен сообщество ожидает ответных действий от вас. Это не обязательно должен быть код: даже сообщение об ошибке, или об опечатке где-то в интерфейсе модуля — уже очень полезная информация для разработчиков.
Именно поэтому у Drupal огромное количество модулей в открытом доступе и почти отсутствуют платные решения. Разработчики делятся своими наработками, а затем — совместно с теми, кому данное решение также необходимо — дорабатывают и улучшают функционал.
Не нужно работать в одиночку: всегда найдутся другие люди, желающие помочь вам с вашими идеями и довести их до финишной прямой.
¶Пишите модули атомически
Всегда кажется, что писать весь функционал в одном модуле — это хорошая идея. На самом деле, оно того не стоит; лучше приложить небольшие усилия для разбиения кастомного кода на мелкие кусочки в виде различных модулей.
Монолитные модули — это хорошо, однако, на практике их очень сложно поддерживать, они несут с собой очень много лишнего функционала, который может оказаться ненужным на конкретном сайте, но он будет выполняться и создавать дополнительную нагрузку на сайт, тем самым замедляя его работу без необходимости.
Также следует иметь в виду, что модули-комбайны пагубно влияют на Drupal, так как новичкам присуще ставить подобные модули пачками, так как вроде бы это решает их задачи без необходимости кодить — но чаще всего им нужен лишь 1 функционал из 1000, предоставляемых каждым из этих модулей. В конечном итоге новички, как им представляется, достигают своей цели — но их сайт тормозит, а винят они в этом Drupal.
Поэтому, пожалуйста, не пишите весь код в одном модуле, дробите его на самодостаточные мини-модули, которые расширяют основной. В качестве примера посмотрите, как устроен модуль Drupal Commerce 2, который имеет огромное количество функционала, но этот функционал всегда можно включить либо выключить, под конкретные задачи.
¶Темплейты — для отображения
Мы не пишем логику и запросы в темплейтах. Это плохой тон в Drupal-сообществе и очень не приветствуется.
Темплейты созданы для формирования HTML-разметки страницы, больше ни для чего. Если вы выполняете запрос в темплейте на получение данных, пишете CSS стили, или JS код — вы используете их неправильно.
В Drupal 8 ситуацию сильно улучшили, перейдя с PHPTemplate шаблонизатора на Twig. Тем не менее, многие все равно умудряются делать серьезную логику в темплейтах, пишут фильтры и плагины для Twig, которые позволяют писать запросы в темплейте и исполнять PHP код напрямую — это плохо.
Drupal предоставляет множество инструментов, благодаря которым вы можете подготовить данные для темплейта заранее в своем модуле, а в темплейте только использовать их значения. Не допускайте таких ошибок, лучше прочитайте про то, как работает hook_theme() и его производные хуки, изучите как правильно подключать библиотеки (CSS и JS) — и только там, где это нужно. Всё это позволит вам избежать перемешивания логики с отображением.
¶Никакого PHP в базе данных
Серьезно, не нужно.
¶Используйте Drupal API
У Drupal очень большой API, даже спустя несколько лет вы все равно будете находить что-то новое для себя — и это не преувеличение. Всё изучать не стоит и не имеет смысла. Учить нужно только основные моменты, а остальное гуглить по необходимости.
Если вы не понимаете как что-то сделать, или куда-то подлезть — очень вероятно, в Drupal уже есть API в ядре, который позволит вам решить вашу задачу, нужно лишь просто поискать.
Мы не пишем костыли, когда есть официальные решения в ядре.
¶Не переизобретайте колесо
Drupal'у уже второй десяток лет, а это значит, что у сообщества скопилось огроменное количество решений и готового функционала. Если вы нашли модуль, который решает вашу задачу — не нужно писать ещё один такой же. Исключением может быть лишь только вариант, когда вы хотите сделать модуль, решающий аналогичную задачу другим способом, или же если модуль заброшен автором, а он не передает права на проект (хотя даже в этом случае есть процессы, позволяющие получить права над проектом без участия автора).
¶Ссылки
- The Drupal Way, Sharon Krossa, 2011
- The Drupal Way™, Jeff Geernling, 2013
- Implementing a Web Design the Drupal Way (not just any old way), Anthony Lindsay, 2015
- Programming The Drupal Way, Sebastian, 2013
