なぜコアをハックしないのですか？

このサイトでこの質問がまだ回答されていないとは信じられませんでしたが、検索しても見つけられなかったので...

なぜコアをハックするのが自然に対するそのような悪い考えの犯罪ですか？

• コアバージョンをアップグレードできるのは本当に素晴らしいことですか？私のサイトのほとんどは、とにかく恐ろしく古くなったコアを持っていることになります。
• たとえサイトの所有者にとって非常に悪いとしても、なぜコミュニティはそんなに気にかけているのでしょうか？なぜ「子猫を殺す」と呼ばれているのですか？むしろ双曲線ではありませんか？
• コアのハッキングはとても簡単です。問題を解決するための簡単なルートを取るのは好きではありませんか？
• コアをハッキングすることでしか解決できない問題はありませんか？じゃあ

一般的に、Drupalコアコードを変更しない理由は3つあります。

• 必要な手順を実行しないと、Drupalを更新するたびに変更が失われます。使用している現在のDrupalバージョンのパッチを作成する場合でも、パッチを新しいバージョンに適用できなかったため、新しいバージョンのパッチも作成する必要があります。

• セキュリティ修正は、Drupal.orgで管理されているDrupalコアに適用されますが、ハッキングされたバージョンには適用できません。つまり、バージョンがDrupalコアに対して発生したセキュリティ問題の影響を受けていないことを確認する必要があります。
  あなたのハッキングされたバージョンが異なるセキュリティ問題を導入する場合、あなたはそれを見つけることができる唯一の人です、あなたはDrupalコアコードとサードパーティに存在するセキュリティ欠陥について調査するセキュリティチームのサポートを持っていませんDrupal.orgでホストされているモジュール。

• 導入する変更は、Drupal自体と互換性がない可能性がありますが、作成できるハッキングされたバージョンではなく、Drupalコアで動作するために必要なサードパーティモジュールとも互換性がありません。
  Drupalが新機能（Drupal 7およびDrupal 6で発生しますが、頻度は少ないですが）または新しいAPIの変更を導入するたびに、ハッキングされたバージョンが最近の変更と互換性がない可能性があります。

ただし、ハッキングされたバージョンを作成することは可能ですが、Drupalが一人で保守されないのと同じように、それは一人の開発者が実行できるタスクではありません。実際、Pressflowは、パフォーマンスを考慮して作成されたDrupalのハッキングバージョンであり、Drupalサイトで発生する可能性のあるパフォーマンスの問題を解決するためのものです。

コアをハッキングすることでしか解決できない問題はありませんか？じゃあ

ほとんどの場合、Drupalコアコードを編集せずに機能/動作を変更できます。Drupalが持っている機能/動作を変更できるフックが常にあり、それが推奨される方法です。

ここに大量の答えを書くことができますが、私はこのリンクを投稿するだけです：コアをハックしないでください！

私が推測する主な理由は、あなたが必要なことをするためにコアをハックし、それを更新するなら...バンです！変更はなくなりました。失った その後、VCSからコードをロールバックできますが、Drupalコアからデータベースアップグレードをロールバックできないので、VCSからすべてのコードを復元し、バックアップからデータベースを復元することを検討しています。コードをロールバックしようとするたびに、最後の更新前のデータベースのバックアップが失敗したことに気付くでしょう。そして、あなたが以前に誓った以上のことを誓います。

また-最も重要なこと-コアをハックすると、DriesとWebchickの両方が子猫を殺します：-o

「開発者である私にとって、コアをハッキングできないことは何ですか？」

• セキュリティリリース用にサイトをアップグレードできます
• サイトをアップグレードして、コアの迷惑なバグを修正できます
• 新しいモジュールをサポートするためにサイトをアップグレードできます
• コアおよびcontribのバグレポートとサポートリクエストに対応できるようになります
• サポートされているCMSを使用する必要があるため、Drupalを選択しました。webchickの言葉でコアをハックすると、「コアをハックすればおめでとうございます！Drupalの独自のフォークを作成したので、あなたとあなただけがそれを維持する責任があります！」

「私のクライアントに対してコアをハッキングできないことは何ですか？」

• クライアントを解雇した/宝くじに当たった/バスに当たった後、他の誰かがあなたのサイトを維持することができます

「私のコミュニティにとって、コアをハッキングできないことは何ですか？」

• あなたのバグレポートは実際にコアまたはcontribモジュールのメンテナーに役立つ情報を提供します。
• コアにパッチを適用する必要がある正当なバグを見つけた場合、「ハッキングコア」と「コアコントリビューターになる」の境界線は、変更を単にdiffし、関連するdo問題にパッチとしてアップロードするだけで十分です。ビオラ！コアはあなたの努力にとって優れており、あなたの名前はコミュニティにコードを返すことに関連しています。

コアをハックしないと誰もが勝者です！

現在、ハッキングされたコアWebサイトで作業しています。フォントのように単純なものがどのように設定されているかを見つけるのに苦労しています。また、コアハックによって導入されたバグの修正にも数日費やしています。drupalコード全体で文字列を検索して見つけました。

drupalのプログラミングの標準構造に従わない場合、導入した変更を他の人がどのように見つけて編集できますか？drupalではすべてのphpファイルがフックを実装できるため、これは特に苦痛です。問題を引き起こしているものを見つけてみてください。

「コアをハッキングすることでしか解決できない問題はありませんか？

この質問に答えるために、はい、あなたは時々あなたがコア（またはcontribモジュール）をハックしなければならないことを意味する克服しなければならない問題があります。

この場合、ハッキングされたコードに多くのコメントを入れて、変更したものをすべて文書化する限り、ハッキングしても大丈夫だと思います。

たとえば、コアまたはcontribの変更については、パッチを作成します。それが一般的で他の人々にとって有用である場合、私は問題でdrupal.orgにそれを提出します。

次に、コードの変更とともに、パッチファイルをバージョン管理にコミットします。

これは、何かがハッキングされた場合にパッチファイルを探すことで確認できることを意味します。

それに加えて、ハックのリストをサイトの開発者ドキュメントに追加します（サイトで動作する可能性のある他の人のために、そして必然的に物事を忘れる場合は自分のために開発者ドキュメントを用意する必要があります）。

このハックのドキュメントでは、ハックの内容と理由、影響を受けるモジュール/ファイル、ハックコードを含むパッチファイルの名前、および関連するdrupal.orgの問題へのリンク（ほぼ常に）私の場合はあります）。

そうすれば、あなたと将来このサイトで働く他の誰もがハッキングの完全なリストを手に入れることができ、アップデートで何かを誤って壊すことを心配する必要はありません。

次に、更新プロセスのために、ハッキングのリストを確認し、更新しているすべてのモジュールのパッチファイルをすばやく確認します。ハッキングがあり、drupal.orgの問題がある場合、最新バージョンにパッチが含まれているかどうかを確認します。その場合、更新でハックを吹き飛ばし、ハッキングのリストから削除します（make drupal.orgのコミットメッセージを見て、コミットされたものが使用しているパッチのバージョンと同じであるか、少なくとも機能的には同じであるかを確認してください。

パッチがコミットされていない場合は、モジュールを更新してパッチを再適用するだけで済みます。多くの場合、パッチはきれいに適用され、プロセスは簡単ですが、時々、新しいバージョンのパッチを再ロールしてから、ローカルリポジトリにパッチの新しいバージョンをコミットする必要があります（関連するdrupal.orgの問題（該当する場合）。

モジュール（またはdrupal.orgモジュールの上に拡張するカスタムモジュール）のコア機能と相互作用するより実質的なパッチまたはパッチがある場合、私がやりたいもう1つのことは、更新されたモジュールのリリースノート（つまり、現在のバージョンと更新先のバージョンの間のすべてのバージョンを意味します）、コードを壊す可能性のあるものが何もないことを確認します。注：最近、多くのモジュールメンテナーが完全なリリースノートを提供してくれますが、まだリリースノートをゴミにする多くの人がいます。この場合、場合によっては、現在のバージョン以降のすべてのコミットメッセージを調べます（これは、通常、別のモジュールと深くやり取りする複雑なコードがある場合のみです）。注意：

次に、更新後（サイトの開発コピー上）、徹底的にテストします。いくつかのバグがすり抜けた後、最終的に何を意味するかを学習します。

その後、十分にテストされたら、ライブサイトをアップグレードするか、ローカルの更新を展開するか、展開プロセスがどうであろうと。

簡単だとしても、誰もがそれをしないと言う理由：ほとんどの人は私が概説したようなシステムを持っていないので、更新を行う時が来たとき、またはサイトが他の誰かに渡されて働くそれは悪夢になり、バグを解決し、ハックを追跡し、それらが存在する理由を解明するなど、多くの時間（場合によっては膨大な時間）を費やす必要があります。

そのようなサイトを継承した場合、完全に理解できます:)

Drupal Webサイトのインストールと作成で生計を立てている場合は、それらを最新の状態に保つ必要があります。あなたのサイトのほとんどがひどく古くなっている場合、あなたは専門家ではありません。