Когда разрабатывать новый модуль drupal против работы с тем, что существует?

Question

Возможно, это применимо к другим расширяемым системам управления контентом, но я работаю с Drupal. В частности, я создал веб-приложение для обмена изображениями, функциональность которого основывалась на более оригинальном коде, чем код ядра Drupal. Я использовал модуль WebForm и направил его формы на пользовательские страницы с жестко запрограммированным php, чтобы узлы создавались программно, а также другим странным вуду.

Непосредственно перед тем, как я закончил, я понял, что, возможно, мне следовало просто сделать свой собственный модуль или я должен был это сделать? Даже в ретроспективе трудно сказать.

Что вы используете, чтобы решить, когда нужно написать новый модуль, и когда нужную вам функциональность можно просто объединить из того, что доступно?

Answer 1

У меня есть твердое мнение по этому поводу, что все пользовательское кодирование должно выполняться в пользовательских модулях , только с одним возможным исключением (см. Ниже):

Я различаю три случая:

1. Абсолютно новая функциональность - это, очевидно, требует специального модуля, который инкапсулирует новую функциональность. Он делает его многоразовым и даже может превратиться в «официальный» модуль Drupal, если функциональность соответствует популярному спросу.
2. Настройка существующего функционала - для каждого сайта я сразу настраиваю пустой, настраиваемый модуль (названный в честь сайта). Весь пользовательский код, используемый для настройки существующих функций (будь то из базовых или дополнительных модулей), происходит внутри этого модуля. Таким образом, все мои настройки четко разделены, что значительно упрощает обновление ядра или других модулей без необходимости постоянного повторного применения моих настроек к обновленному коду (конечно, необходимо проверить, работают ли настройки после обновления, и настроить или удалите их при необходимости).
3. Исправление ошибок / добавление отсутствующих функций - это возможное исключение, упомянутое выше. Если мои изменения - просто исправление ошибки или добавление очевидной, но отсутствующей функции, я мог бы просто сделать это в исходном коде, отправив свои изменения в виде патча в исходный модуль, надеясь, что они будут включены в будущий выпуск что делает мои изменения устаревшими.

По моему опыту, «накладные расходы» на отделение настроек от исходного кода на самом деле не являются «накладными», так как «одноразовые» твики и исправления обычно сохраняются гораздо дольше, чем ожидалось, и имеют тенденцию расти в течение жизни сайта. Отделение их от начала избавляет от неприятностей в процессе обслуживания, так как применение обновлений и исправлений безопасности, а также расширение настроек будет намного проще.

Answer 2

Что я предпочитаю делать, так это полноценный поиск на drupal.org любых / всех модулей, обладающих необходимой мне функциональностью. Я ищу drupal.org & groups.drupal.org (и, возможно, даже форумы) по названию этого модуля, чтобы узнать, что об этом говорят другие. Наконец, я всегда проверяю drupalmodules.com, чтобы узнать, что об этом говорят другие в сообществе.

Если я не могу найти именно то, что мне нужно, я выкатываю свой собственный модуль. Plynx также прав, если вы планируете повторно использовать функциональность, создайте новый модуль, ЕСЛИ он достаточно уникален, чтобы его еще не существовало.

Answer 3

Создайте новый модуль, если вы хотите легко поделиться или повторно использовать функциональность. В этом есть накладные расходы, поэтому, если это одноразовый, это того не стоит.