Что делать, если не уверен в модуле

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

• Гугл
• Сообщество
• https://groups.drupal.org/similar-module-review
• https://drupal.org/node/266179

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

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

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

   

2. Если у модуля есть стабильная версия, скачайте её на тестовый друпал из п. 1.
3. Включите его.
4. Найдите инструкции по установке (см. Часть II)
5. Включите его правильно.
6. Найдите страницу настроек модуля и ознакомьтесь с ней.
7. Поработайте с модулем. Это может занять от 5 минут до недели.

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

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

8. Деинсталлируйте стабильную версию сомнительного модуля.
9. Создайте в папке sites/all/modules каталог unstable.
10. Скачайте последнюю dev-версию модуля:
    1. Перейдите на вкладку Version control на странице модуля.
       

       

    2. Выберите свежую ветку, совместимую с используемым ядром друпала.
    3. Выберите её!
    4. Скопируйте и выполните нехитрый код git clone в папке unslable, созданной в п. 9.
       

       

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

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

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

11. Включите dev-версию и повторите пункты с 3. по 7.
    Если сохраняются проблемы или ошибки, то...

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

12. Поиск по Issue queue
    Этот пункт был одним из самых сложных для меня, привыкшей после битрикса, что в интернете не найдёшь ответов на свои вопросы.
    Однако с друпалом ситуация противоположенная — информации слишком много, поэтому её надо искать, фильтровать, сортировать.
    • По тексту ошибки
    • По одному-двум ключевым словам
    • По дате обновления заявки

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

13. Создание новой заявки в Issue queue
    

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

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

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

    • Тема заявки должна быть до боли понятной. Попробуйте сначала написать сам текст заявки, а потом вычлените из него самое главное и заполните поле «тема».
    • Пропустите поле «приоритет». Оно не для вас.
    • Указывайте версии всего, что связано с модулем. Как минимум версии модуля и его зависимостей. Если недавно обновляли модуль, его зависимости, библиотеки или ядро, тоже укажите это.
    • Опишите шаги для воспроизведения бага. Это +100 к увеличению скорости закрытия заявки.
      Пример: https://drupal.org/node/1982528#comment-7541283
    • Добавьте тексты всех php-ошибок в текст сообщения. Мэйнтейнер испугается и начнёт исправлять проблему, а другие пользователи найдут вашу заявку в гугле и не будут плодить новые.
    • Если вы добавляете патч, можно поставить статус «needs review». В противном случае пропустите поле «статус».
14. Исправьте проблему сами
    Вы уже зашли слишком далеко, и говорить теперь, что быстрее было написать свой “custom-code” в файле node--article.tpl.php, поздно.
    Не забывайте, Nobody's Going to Help You. Каждый преследует свои интересы. Вам нужно, чтобы модуль работал? Почините его.

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

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

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

    Внимание: всегда используйте стандарт именования патчей [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.
    • Drush Make workflow: См. http://drupal.stackexchange.com/questions/33403/how-to-effectively-manag...

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

16. Обновляемся до стабильной версии (и стремимся к идеалу)
    Если вы всё делаете правильно, в следующем официальном релизе модуля в Release Notes (см. Часть II, п. 11) вы найдёте закрытой свою проблему и сможете обновиться. Модуль перестанет быть проблемным и переедет в папку contrib.

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