Философия Drupal

Официального документа, отражающего принципы сообщества 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'у уже второй десяток лет, он появился не вчера, а это значит, что у сообщества скопилось огроменное количество решений и готового функционала. Если вы нашли модуль, который решает вашу задачу — не нужно писать ещё один такой же. Исключением может быть лишь только вариант, когда вы хотите сделать модуль, решающий аналогичную задачу, но другим способом, или же если модуль заброшен автором, а он не передает права на проект (хотя даже в этом случае есть процессы, позволяющие получить права над проектом без участия автора).

Ссылки

💝 Помогите нам сделать документацию лучше!

Вся документация Druki с отрытым исходным кодом. Нашли ошибку или неточность? Создайте pull request.

Редактировать текущий документ Обсудить улучшение

Или узнайте как контрибутить.

🤔 По-прежнему нужна помощь?

Не нашли ответа на свой вопрос? Попросите помощи у сообщества!

Задайте вопрос на GitHub Смотрите другие ресурсы сообщества