カスタマイズしたテーマをどのようにアップグレードすればよいですか？
テーマファイルテンプレート、CSS、およびtplファイルにいくつかのカスタム変更を加えました。行ごとにテーマを更新し、新しいテーマをアップロードした後にカスタムの変更を再挿入する以外に、ベストプラクティスの方法はありますか？これに将来的に取り組むより良い方法はありますか？
「将来的にこれに取り組むより良い方法はありますか？」とあなたは尋ねました。
基本となるテーマ（私が好む）を変更する代わりにサブテーマを使用し、変更したい側面のみをオーバーライドして既存のテーマを拡張します。これにより、元のテーマをアップグレードして、コードを個別に保持できます。
- http://drupal.org/node/441088 すばやく汚いサブテーマ
- http://drupal.org/node/225125 サブテーマの構造と継承
ただし、このアプローチは、完全にメンテナンスに対する無料パスではありません。
- コアテーマに修正が適用され、（以前は壊れていた）コードをサブテーマにコピーした場合、壊れたコードをオーバーライドとして保持します。
- サブテーマが考慮しないベーステーマに変更が加えられた場合は、それを処理する必要があります。
したがって、コアテーマの更新を確認する必要がありますが、このアプローチ（私にとって）は最も意味があり、最小限のコードを維持していることを意味し、既存のテーマに基づいて構築するかなり簡単な方法を提供します= Drupalオファー。
必要がない場合は、行わないでください。
Zen 1.xの開発中に使用していました。最新のStarterkitと私のサブテーマに対して差分ツール（変更アプリ）を実行し、必要に応じて元のソースファイルと名前を変更したファイルまたは変更したファイルに対して実行しました。 。
これは大きな手間であり、テストや開発の支援以外の目的で開発モジュールを使用してはならない理由の完璧な例です。
モジュールとは異なり、テーマは通常、セキュリティリスクを十分に保持していないか、更新時に機能を備えている必要があるため、最新に更新する必要はありません。壊れていなければ...
テーマをベーステーマのサブテーマにすることでテーマを作り直すことに興味がない場合は、次の手順で段階的に進めることができます http://drupal.org/update/themes/6/7 toテーマを更新します。それはたくさんのように思えるかもしれませんが、あなたが体系的にそれを働かせるならば、あなたは成功に会うべきです。テーマの複雑さによっては、すべてのマークアップを完了するのに数時間かかる可能性があります。 CSSの更新にはさらに時間がかかる場合があります。一部のモジュールとコア関数はD7ポートでクラスとIDの名前を変更しているため、これは実際に、対象のIDとクラスの変更量に依存します。