«Разве нет проблем, которые можно решить только взломом ядра? Что тогда?»
Чтобы ответить на этот вопрос, да, иногда возникают проблемы, которые вы должны преодолеть, что означает, что вам нужно взломать ядро (или модуль contrib).
В этом случае я считаю, что это нормально, если вы добавите много комментариев в ваш взломанный код и задокументируете все, что вы изменили.
Например, для любого изменения ядра или вклада я создаю патч. Если он является общим и полезным для других людей, я отправляю его на drupal.org в номере, в противном случае - для собственного использования.
Затем я фиксирую файл патча в моем контроле версий вместе с изменением кода.
Это означает, что я могу видеть файлы патчей, если что-то было взломано.
В дополнение к этому, я также добавляю список хаков в документацию для разработчиков сайта (у вас действительно должна быть документация для разработчиков ради других, которые могут работать на сайте и для вас самих, когда вы неизбежно забудете что-то).
В этой хакерской документации я перечисляю каждый хак с описанием того, что делает хак и почему, затронутыми модулями / файлами, именем файла патча, содержащего код хака, и ссылкой на связанную проблему drupal.org, если она есть (почти всегда в моем случае есть).
Тогда у вас и у всех, кто еще работает на сайте в будущем, есть полный список хаков, и вам не нужно беспокоиться о том, чтобы случайно что-то сломать с обновлением.
Затем для процесса обновления я проверяю свой список хаков и быстро просматриваю файлы исправлений во всех модулях, которые я обновляю. Если есть взлом, и у него есть проблема с drupal.org, я проверяю эту проблему, чтобы увидеть, есть ли в последней версии патч, и в этом случае я удаляю хак с обновлением и удаляю его из моего списка хаков (make Посмотрев на сообщения о коммитах drupal.org, убедитесь, что то, что было зафиксировано, совпадает с версией используемого вами патча или, по крайней мере, функционально совпадает).
Если патч не был зафиксирован, все, что мне нужно сделать, это обновить модули и повторно применить патчи. Во многих случаях исправления будут по-прежнему применяться корректно, и процесс будет легким, но иногда вам придется повторно применить исправления для новой версии, а затем зафиксировать новую версию исправления в своем локальном хранилище (вместе с публикацией в соответствующем хранилище). Проблема drupal.org, где это применимо).
Еще одна вещь, которую мне нравится делать, если у меня есть более существенные исправления или исправления, которые взаимодействуют с функциональностью ядра модуля (или просто пользовательские модули, которые расширяются поверх модуля drupal.org), - это проверить примечания к выпуску обновленного модуля ( это означает всю версию между вашей текущей версией и версией, на которую вы обновляете), и убедитесь, что там нет ничего, что могло бы испортить ваш код. Примечание. Многие сопровождающие модуля в наши дни хороши тем, что дают полные заметки о выпуске, но есть еще много, которые делают пометки о выпуске. В этом случае в некоторых случаях я просматриваю все сообщения коммита начиная с моей текущей версии (обычно это происходит только в тех случаях, когда у меня сложный код, который глубоко взаимодействует с другим модулем). Замечания:
Затем, после обновления (в разрабатываемой копии сайта), тщательно протестируйте. В конце концов вы узнаете, что значит тщательно, после того, как проскочат несколько ошибок.
Затем, когда он будет достаточно протестирован, обновите работающий сайт или отправьте свои локальные обновления вверх, или каким бы ни был процесс развертывания.
Причина, по которой все говорят, не делает этого, даже если это проще: потому что у большинства людей нет системы, как я обрисовал, поэтому, когда приходит время делать обновления, или сайт передается кому-то другому для работы это становится кошмаром, и много времени (иногда огромное количество времени) приходится тратить на устранение ошибок, отслеживание взломов, выяснение их причин и т. д.
Если вы когда-нибудь унаследуете такой сайт, вы полностью поймете :)