Почему бы нам не взломать ядро?

Я не мог поверить, что этот вопрос еще не был дан ответ на этом сайте, но я не нашел его, когда я искал, так что ...

Почему взломать ядро ​​так плохо, преступление против природы?

• Разве это так здорово - иметь возможность обновить версию ядра? Большинство моих сайтов в конечном итоге имеют ужасно устаревшие ядра, так зачем беспокоиться?
• Даже если это так плохо для владельцев сайтов, почему сообщество так заботится? Почему это называется "убийство котят"? Разве это не гиперболично?
• Взломать ядро ​​так просто, разве нам не нравится идти по более простому пути к решению проблем?
• Разве не там проблемы , которые могут только быть решены путем взлома ядра? Что тогда?

Вообще говоря, есть три причины не изменять основной код Drupal:

• Ваши изменения будут потеряны при каждом обновлении Drupal, если вы не предпримете никаких необходимых шагов. Даже в том случае, если вы создаете патч для текущей используемой вами версии Drupal, патч не может применяться к более новой версии, и вам также потребуется создать патч для новой версии.

• Исправления безопасности применяются к ядру Drupal, как поддерживается на Drupal.org, но не могут применяться к вашей взломанной версии. Это означает, что вы должны убедиться, что ваша версия не затронута проблемой безопасности, возникающей в ядре Drupal.
  В случае, если ваша взломанная версия представляет другую проблему безопасности, вы единственный, кто может ее найти, поскольку у вас нет поддержки группы безопасности, которая занимается исследованием недостатков безопасности, присутствующих в коде ядра Drupal и сторонних разработчиков. модули, размещенные на Drupal.org.

• Внесенные вами изменения могут быть несовместимы как с самим Drupal, так и со сторонними модулями, которые необходимы для работы с ядром Drupal, а не с любой взломанной версией, которую можно создать.
  Каждый раз, когда Drupal вводит новую функцию (которая все еще происходит в Drupal 7 и в Drupal 6, хотя и с меньшей частотой) или новое изменение API, существует вероятность того, что взломанная версия несовместима с последними изменениями.

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

Нет ли проблем, которые можно решить только взломом ядра? Что тогда?

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

Я мог бы написать масштабный ответ здесь, но я просто опубликую эту ссылку: Никогда не взламывайте ядро !

Основная причина, я думаю, заключается в том, что если вы взломаете ядро, чтобы сделать то, что вам нужно, а затем обновить его ... БАХ! Ваши изменения ушли. Потерянный. Затем вы можете попытаться откатить код из вашей VCS, но, видя, что вы не можете откатить обновления баз из ядра Drupal - вы смотрите на восстановление всего кода из VCS, а затем восстановление баз данных из ваших резервных копий. Все время, когда вы пытаетесь откатить свой код, вы, вероятно, заметите, что ваша последняя резервная копия базы данных перед обновлением не удалась, и вы поклянетесь больше, чем когда-либо.

Кроме того, что наиболее важно, если вы взломаете ядро, Dries и Webchick убьют котенка: -o

«Что не может взломать ядро ​​для меня, разработчика?»

• Ваш сайт может быть обновлен до релизов безопасности
• Ваш сайт может быть обновлен, чтобы исправить надоедливые ошибки в ядре
• Ваш сайт может быть обновлен для поддержки новых модулей
• Ваши сообщения об ошибках и запросы поддержки на ядро ​​и вклад смогут ответить на
• Вы хотите использовать поддерживаемую CMS, поэтому вы выбрали Drupal. Когда вы взламываете ядро, словами вебчика : «Если вы взломали ядро, поздравляю! Вы создали свой собственный форк Drupal, и теперь вы и только вы один несете ответственность за его поддержку!»

«Что не может взломать ядро ​​для моего клиента?»

• Ваш сайт может обслуживаться кем-то другим после того, как вы уволите своего клиента / выиграете в лотерею / попадете в автобус

«Что не может взломать ядро ​​для моего сообщества?»

• Ваши сообщения об ошибках на самом деле предоставят полезную информацию для сопровождающего ядра или модулей contrib.
• Если вы обнаружите допустимую ошибку в ядре, которая должна быть исправлена, грань между «взломом ядра» и «становлением основным участником» так же хороша, как простое внесение изменений и загрузка их в виде патча в соответствующую проблему do. Виола! Ядро лучше для ваших усилий, а ваше имя связано с возвращением кода сообществу.

Каждый выигрывает, если не взламывать ядро!

В настоящее время я работаю над взломанным основным сайтом. У меня возникают трудности с поиском простых настроек шрифта. Я также провожу несколько дней, исправляя ошибку, внесенную основным хаком. Я нашел это, ища строку во всем друпальском коде.

Если вы не следуете стандартной структуре программирования в drupal, то как кто-то другой может найти и отредактировать внесенные вами изменения? Это особенно болезненно, потому что в drupal каждый отдельный php-файл может реализовать хук. Попробуйте выяснить, какой из них вызывает проблемы.

«Разве нет проблем, которые можно решить только взломом ядра? Что тогда?»

Чтобы ответить на этот вопрос, да, иногда возникают проблемы, которые вы должны преодолеть, что означает, что вам нужно взломать ядро ​​(или модуль contrib).

В этом случае я считаю, что это нормально, если вы добавите много комментариев в ваш взломанный код и задокументируете все, что вы изменили.

Например, для любого изменения ядра или вклада я создаю патч. Если он является общим и полезным для других людей, я отправляю его на drupal.org в номере, в противном случае - для собственного использования.

Затем я фиксирую файл патча в моем контроле версий вместе с изменением кода.

Это означает, что я могу видеть файлы патчей, если что-то было взломано.

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

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

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

Затем для процесса обновления я проверяю свой список хаков и быстро просматриваю файлы исправлений во всех модулях, которые я обновляю. Если есть взлом, и у него есть проблема с drupal.org, я проверяю эту проблему, чтобы увидеть, есть ли в последней версии патч, и в этом случае я удаляю хак с обновлением и удаляю его из моего списка хаков (make Посмотрев на сообщения о коммитах drupal.org, убедитесь, что то, что было зафиксировано, совпадает с версией используемого вами патча или, по крайней мере, функционально совпадает).

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

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

Затем, после обновления (в разрабатываемой копии сайта), тщательно протестируйте. В конце концов вы узнаете, что значит тщательно, после того, как проскочат несколько ошибок.

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

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

Если вы когда-нибудь унаследуете такой сайт, вы полностью поймете :)

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