Разработка сайтов на Drupal - простые, но важные истины

Категория: Drupal
Дата публикации: 24 ноября, 2014 - 14:30
Последнее изменение: 23 февраля, 2015 - 22:12

Всегда использовать только последние стабильные версии ядра и модулей (исключением могут быть те случае, когда в dev версии модуля исправлена какая-то проблема).

НИКОГДА, НИКОГДА не патчить, не хакать ядро, дефолтные модули, темы.

При необходимости не лениться и оставлять в корне ридми файл, который может в будущем помочь другому разработчику, занимающемуся этим сайтом. В файл желательно поместить важные детали, которые сходу могут показаться неочевидными. Например, если какой-то модуль пропатчен, стоит указать название, причину, ссылку на патч.

Модули и темы класть только в /sites/all/modules и /sites/all/themes соответствнно.

Если в скачанную с drupal.org тему вносятся изменения - создавать субтему, или клонировать оригинальную тему с другим названием, или отключать проверку обновлений. И всегда читайте ридми для тем! Они содержат важную информацию. Особенно базовые темы - Zen, Omega, AdaptiveTheme.
Пример из жизни - попадал ко мне сайт, первый разработчик использовал тему "AdaptiveTheme". Основной темой от сделал встроенную at_subtheme, куда и вносил изменения (хотя нужно было делать свою субтему, чтобы сам адаптив можно было обновлять). Более того создатель сайта работал с темплейтами в папке at_core, само собой, это тоже делает невозможным обновление.

Удалять из корня сайта все лишние TXT, PHP файлы.
Для примера в дистрибутиве Drupal 7 аж 14 лишних файлов! Удалять их нужно уже после установки.

Включать логирование (dblog) системных событий и отключать вывод сообщений об ошибках. Рекомендуемое количество хранимых записей в журнале 10 000 - 100 000
.
Включенное логирование помогает оценить общее состояние сайта, увидеть наличие ошибок, уведомлений. Так же по нему иногда удается определить причину "внезапно" возникшей проблемы.

Прибирать за собой - удалять не используемые модули или темы.
Очень часто после окончания работ создатели не удаляют темы, которые скачали, но они не подошли, модули для разработки (например, Devel). Кроме того, что это все занимает лишнее место, все это обычно не обновляется, что в свою очередь создает проблему безопасности.

Разумно выбирать подход к решению той или иной задачи. Не нужно лишний раз лазить в темплейт, что-то там править, добавлять, если тоже самое можно сделать через админку. Так же не стоит слишком усердствовать с API.
Видел однажды сайт, в котором самое обычное меню выводилось самописным модулем. Все это круто, разработчик показал, что умеет писать модули, но что будет, если потом в это меню нужно будет внести какое-то изменение, а новый работник будет плохо знать API? Ему придется или много часов потратить на попытки понять, как работает самописный модуль, или заново переделывать меню по-правильному. Все это выливается в огромные временные и денежные затраты. Поэтому, давайте рационально и трезво оценивать задачу, а в первую очередь использовать более постые и надежные средства (views, модули с оф. сайта), прежде чем городить костыли.

Информировать заказчика (владельца) сайта о необходимости обновлений и к чему может привести их отсутствие.

Использовать системные адреса.
Например, когда нужно в настройках видимости блока указать страницы, то указывать:

node/50
node/51

,но не

sobaki.html
koshki.html

ЧПУ'шные адреса страниц могут поменяться, тогда блоки придется перенастравивать, а системные - уже не изменятся.

Делать бекап базы (через Backup and Migrate) перед отключением модулей.

Список будет дополняться.

Добавить комментарий