この質問がこのサイトでまだ回答されていないことは信じられませんでしたが、検索しても見つかりませんでした。
一般的に、Drupalコアコードを変更しない理由は3つあります。
必要な手順を行わないと、Drupalを更新するたびに変更が失われます。使用している現在のDrupalバージョンのパッチを作成する場合でも、パッチは新しいバージョンに適用できず、新しいバージョンのパッチも作成する必要があります。
セキュリティ修正は、Drupal.orgで維持されているDrupalコアに適用されますが、ハッキングされたバージョンには適用できませんでした。つまり、バージョンがDrupalコアに対して発生したセキュリティの問題の影響を受けていないことを確認する必要があります。
ハッキングされたバージョンが別のセキュリティ問題を引き起こす場合、あなたはそれを見つけることができる唯一の人物です。あなたはDrupalコアコード、およびDrupal.orgでホストされているサードパーティモジュール。
導入した変更は、Drupal自体と互換性がない可能性がありますが、ハッキングされたバージョンでは作成できないDrupalコアで動作するために必要なサードパーティモジュールとも互換性がない可能性があります。
毎回Drupalは新しい機能を導入します(これはDrupal 7とDrupal 6でも発生しますが、頻度は低くなります)、または新しいAPIの変更により、ハッキングされたバージョンが最近の変更と互換性がない可能性があります。
そうは言っても、ハッキングされたバージョンを作成することは可能ですが、Drupalが1人で保守されないのと同じように、1人の開発者が実行できるタスクではありません。実際、Pressflowは、パフォーマンスを考慮して作成されたDrupalの-hackedバージョンであり、Drupalサイトで発生する可能性があるいくつかのパフォーマンスの問題を解決します。
コアをハッキングすることでしか解決できない問題はありませんか?それで?
ほとんどの場合、Drupalコアコードを編集せずに機能/動作を変更できます。 Drupalが持つ機能/動作を変更できるフックが常にあり、それが推奨される方法です。
ここに大量の回答を書くことができましたが、このリンクを投稿するつもりです コアをハックしない !
私が推測する主な理由は、必要なことをするためにコアをハックし、それを更新すると... BANG!変更がなくなりました。失った。次に、VCSからコードをロールバックしてみることができますが、データベースのアップグレードをDrupalコア)からロールバックできないので、VCSからすべてのコードを復元し、バックアップからデータベースを復元します。コードをロールバックしようとしている間は常に、更新前の最後のデータベースバックアップが失敗したことに気づくでしょう。
また-最も重要なこと-コアをハックすると、DriesとWebchickの両方が子猫を殺します:-o
コアをハックしないと、誰もが勝者になります!
現在、ハッキングされたコアWebサイトに取り組んでいます。フォントのようにシンプルなものが設定されているのを見つけるのが難しい。また、コアハックによって引き起こされたバグを修正するために数日を費やしています。 drupalコード全体で文字列を検索して見つけました。
drupalのプログラミングの標準的な構造に従っていない場合、他の誰かがあなたが導入した変更を見つけて編集するにはどうすればよいですか? drupalでは、すべてのphpファイルがフックを実装できるため、これは特に痛みを伴います。問題の原因となっているものを見つけてください。
「コアをハッキングすることでしか解決できない問題はありませんか?
この質問に答えるために、はい、コア(またはcontribモジュール)をハックしなければならないという、克服しなければならない問題が時々あります。
この場合、ハッキングされたコードにたくさんのコメントを入れ、変更内容をすべて文書化する限り、ハッキングしても問題ないと思います。
たとえば、コアやコントリビューションの変更については、パッチを作成します。それが一般的で他の人に役立つ場合は、問題でdrupal.orgに送信します。それ以外の場合は、自分で使用します。
次に、コードの変更と共にパッチファイルをバージョン管理にコミットします。
これは、何かがハッキングされた場合、パッチファイルを探すことで確認できることを意味します。
それに加えて、サイトの開発者ドキュメントにハックのリストを追加します(サイトで作業する可能性のある人のために、そして必然的に物事を忘れたときのために、開発者ドキュメントが本当に必要です)。
このハックのドキュメントでは、各ハックをハックの内容と理由、モジュール/ファイルに影響を与えるもの、ハックコードを含むパッチファイルの名前、および関連するdrupal.orgの問題へのリンク(ある場合)を記載しています。私の場合はあります)。
そうすれば、あなたや他の誰もが今後サイトで作業するハックの完全なリストを入手できるので、誤ってアップデートで何かを壊してしまう心配はありません。
次に、更新プロセスのために、ハックのリストをチェックし、更新しているすべてのモジュールでパッチファイルをすばやく確認します。ハックがあり、drupal.orgの問題がある場合は、問題をチェックして、最新バージョンにパッチが含まれているかどうかを確認します。この場合、アップデートでハックを吹き飛ばし、ハックのリストから削除します(make drupal.orgのコミットメッセージを確認して、コミットされたものが使用中のパッチのバージョンと同じであるか、少なくとも機能的には同じであることを確認してください。
パッチがコミットされなかった場合は、モジュールを更新してパッチを再適用するだけで済みます。多くの場合、パッチは問題なく適用され、プロセスは簡単ですが、新しいバージョンのパッチを再ロールし、新しいバージョンのパッチをローカルリポジトリにコミットする必要がある場合があります(関連するパッチへの投稿とともに) drupal.orgの問題(該当する場合)。
モジュール(またはdrupal.orgモジュールの上に拡張されたカスタムモジュールのみ)のコア機能と相互作用するより実質的なパッチまたはパッチがある場合に実行したいもう1つのことは、更新されたモジュールのリリースノートを確認することです(つまり、現在のバージョンと更新先のバージョンの間にあるすべてのバージョン)を確認し、コードを壊す可能性のあるものがないことを確認してください。注:多くのモジュールメンテナが最近完全なリリースノートを提供していますが、まだリリースノートをごみにすることがたくさんあります。この場合、場合によっては、現在のバージョン以降のすべてのコミットメッセージを調べます(これは通常、別のモジュールと深く相互作用する複雑なコードがある場合にのみ発生します)。注:この場合、現在のバージョンと新しいバージョンを比較して、変更点を確認する方が簡単な場合があります。
次に、(サイトの開発用コピーで)更新した後、徹底的にテストします。いくつかのバグがすり抜けた後、最終的に完全に何を意味するかを学びます。
次に、十分にテストされたら、ライブサイトをアップグレードするか、ローカル更新をプッシュするか、展開プロセスを何にでもします。
簡単だとしても、誰もがそれをしないと言っている理由:ほとんどの人は私が概説したようなシステムを持っていないので、更新を行う時が来たとき、またはサイトが仕事のために誰かに手渡されたときすると、それは悪夢になり、多くの時間(時には膨大な時間)がバグの解決とハックの追跡とそれらが存在する理由の解明などに費やす必要があります。
そのようなサイトを継承したことがあれば、完全に理解できるでしょう:)
Drupal Webサイトのインストールと作成から生計を立てている場合は、それらを最新の状態に保つ必要があります。ほとんどのサイトがひどく古くなっている場合、専門家ではありません。