Как скачать модуль с Drupal.org и не облажаться: Часть III

Как скачать модуль с Drupal.org и не облажаться: Часть III

Если после изучения страницы модуля по нашей инструкции (Часть I, Часть II) у вас возникли сомнения в его работоспособности, то стоит поискать аналоги. В этом помогают:

  • Гугл
  • Сообщество

Если вы всё же остановили свой выбор на сомнительном модуле, то вам предстоит проделать серьёзную работу, чтобы убедиться, что этот модуль не отстрелит вам ногу. Если вы не уверены в своих силах, лучше обратитесь к специалистам.

Нельзя писать в Issue queue модуля, пока не проделаны шаги 1-12.

  1. Подготовьте полигонУ вас должен быть хост с чистым друпалом для тестов или копия копии вашего боевого сайта.

Если модуль выполняет свою задачу, на экране и в журнале (admin/reports/dblog) нет сообщений (error, warning, notice), то его можно использовать.

Иначе см. п. 8.

    Перейдите на вкладку Version control на странице модуля.

Никогда не скачивайте собранные --dev архивы с Drupal.org/drupalcode.org. Они неподдерживаемые. Если вы называете себя веб-разработчиком, не поленитесь поставить git. Благодаря этой прекрасной VCS вы сможете:

  • иметь доступ к самому свежему состоянию модуля (dev-сборки могут запаздывать на 12 часов);
  • переключаться между версиями модуля или отдельными коммитами;
  • накатывать патчи, подготовленные другими участниками сообщества;
  • быстро создавать свои патчи;
  • создавать форки проектов и версионировать их;
  • спустя 3 месяца вернуться к модулю и вспомнить всё, просто написав git status.

Даже если вы (случайно) закинете папку .git на продакшн, ничего страшного не произойдёт, потому что стандартный .htaccess друпала не даст любопытным лазать по папкам, начинающимся с точки.

Внимание: нельзя писать в Issue queue модуля, пока вы не почитали Issue queue модуля.

  • По тексту ошибки
  • По одному-двум ключевым словам
  • По дате обновления заявки

Даже если вы найдете неработающий патч, это будет уже что-то. Вы будете знать куда копать в пункте 14.

Внимание: Если вы не знаете английский, пишите на php, js или другом языке программирования.

В конце сообщения напишите “Thanks!” Вас поймут.

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

  • Тема заявки должна быть до боли понятной. Попробуйте сначала написать сам текст заявки, а потом вычлените из него самое главное и заполните поле «тема».
  • Пропустите поле «приоритет». Оно не для вас.
  • Указывайте версии всего, что связано с модулем. Как минимум версии модуля и его зависимостей. Если недавно обновляли модуль, его зависимости, библиотеки или ядро, тоже укажите это.
  • Опишите шаги для воспроизведения бага. Это +100 к увеличению скорости закрытия заявки. Пример: https://drupal.org/node/1982528#comment-7541283
  • Добавьте тексты всех php-ошибок в текст сообщения. Мэйнтейнер испугается и начнёт исправлять проблему, а другие пользователи найдут вашу заявку в гугле и не будут плодить новые.
  • Если вы добавляете патч, можно поставить статус «needs review». В противном случае пропустите поле «статус».

У меня был случай, когда один сборщик сайтов 12 часов пытался исправить проблему с аяксом на commerce-сайте. Мой отладчик и я справились с задачей за 2 часа.

Я не буду учить вас программированию, но вот некоторые рекомендации:

  • Читайте код (как книгу)
  • Изучайте API
  • Используйте отладчик (например, в NetBeans или PhpStorm)
  • Изучайте новое
  • Возвращайте код в сообщество. Там его проверят и укажут вам на ошибки. Бесплатно.

Внимание: всегда используйте стандарт именования патчей [project_name]-[short-description]-[issue-number]-[comment-number].patch

Если вы будете хаотично применять какие-то патчи к проекту и хакать ядро, то ваш сайт превратится в ад уже завтра. Чтобы так не получилось, вам нужна стратегия.

Вы сами выбираете свою стратегию. Но вот несколько примеров:

  • Папка patches в корне сайта. Cм. https://github.com/shvetsgroup/drupal.ua
  • [Мой выбор] Патчи лежат в папках unstable-модулей; собирается файл PATCHES.txt (автоматически или вручную) См. http://drupalscout.com/knowledge-base/managing-patches-getting-your-drup.Я предпочитаю составлять файл о модулях из папки unstable вручную, указывая причины попадания в эту папку, ссылки на тикеты и хеш последнего официального коммита. Это очень похоже на недоделанный Drush Make. workflow: См. http://drupal.stackexchange.com/questions/33403/how-to-effectively-manag.

Выработайте дисциплину в этом вопросе, и большинство модулей у вас будут обновляемыми, а сайт, соответственно, надёжным.

«А что делать, если я так и не нашёл нужный мне модуль?» — спросите вы. Написать свой. Но это уже совсем другая история.

📎📎📎📎📎📎📎📎📎📎