インストールされたモジュールを /sites/all/modules/* から /sites/all/contrib/modules/* に移動する方法
-
22-10-2019 - |
質問
私はこの質問に対する答えを探してきましたが、うまくいきませんでした。データベース構造を観察したところ、モジュールの場所は「システム」テーブルで指定されています。唯一の解決策は、「filename」列を更新する SQL クエリを作成することです。
これを解決するためのより良い/よりクリーンなソリューション、たとえば contrib モジュールはありますか?
解決
モジュールを新しい場所に移動し、レジスリーを再構築するだけです。レジストリが再構築されると、モジュールへのパスが更新されます。小切手 registry_rebuild()
.
すべてのコードをモジュールまたはディレクトリを含むすべてのコードは、データベースに各インターフェイスまたはクラスの場所を保存します。
ただし、これをテストする前に、データベースをバックアップすることをお勧めします。
Drushを使用している場合は、次のコマンドを使用してレジストリを再構築することもできます。
drush cc registry
インストールすることもできます registry_rebuild
Drushのコマンド:
// install registry_rebuild
drush dl registry_rebuild
// rebuild the registry
drush rr
他のヒント
私はローカルで生産からバックアップを復元し、物を移動して管理/モジュールをヒットするか、registry_rebuild()を実行しようとしましたが、致命的なエラーが投げられないようにしませんでした。一部のモジュールはfook_init()に含まれるものまたは任意のものを使用する場合や、モジュールに依存するメニュールーターパスセット、またはdrupalがブートストラップで見つけることができないメニュールーターパスセットがあるため、これは理にかなっています。最終的に、これは私がしたことです(あなたの道は異なるかもしれません):
ステップ1:サイト/すべて/モジュールをサイト/all/modules/contribに置き換える
UPDATE system SET filename = REPLACE(filename, 'sites/all/modules', 'sites/all/modules/contrib');
UPDATE registry SET filename = REPLACE(filename, 'sites/all/modules', 'sites/all/modules/contrib');
UPDATE registry_file SET filename = REPLACE(filename, 'sites/all/modules', 'sites/all/modules/contrib');
ステップ2:サイト/all/modules/contribをサイト/all/modules/custom for custom paced modulesに置き換える
UPDATE system SET filename = REPLACE(filename, 'sites/all/modules/contrib', 'sites/all/modules/custom') WHERE name LIKE 'my_custom_namespace_%';
UPDATE registry SET filename = REPLACE(filename, 'sites/all/modules/contrib', 'sites/all/modules/custom') WHERE name LIKE 'my_custom_namespace_%';
UPDATE registry_file SET filename = REPLACE(filename, 'sites/all/modules/contrib', 'sites/all/modules/custom') WHERE filename LIKE '%my_custom_namespace_%';
ステップ3:開発モジュールをサイト/すべて/モジュール/開発に移動する
UPDATE system SET filename = REPLACE(filename, 'sites/all/modules/contrib', 'sites/all/modules/dev') WHERE name LIKE 'devel%';
UPDATE registry SET filename = REPLACE(filename, 'sites/all/modules/contrib', 'sites/all/modules/dev') WHERE name LIKE 'devel%';
UPDATE registry_file SET filename = REPLACE(filename, 'sites/all/modules/contrib', 'sites/all/modules/dev') WHERE filename LIKE '%devel%';
ステップ4:物事が適切にブートストラップするようにキャッシュをクリアします
TRUNCATE TABLE cache
TRUNCATE TABLE cache_bootstrap
TRUNCATE TABLE cache_menu
TRUNCATE TABLE cache_page
TRUNCATE TABLE cache_path
ノート: カスタムモジュールまたはlogintobogganのようなcontribを使用して403(アクセス拒否)を処理すると、このプロセス中にログアウトした場合、更新する必要がある場合があります。 include_file
の列 menu_roter
インクルードファイルに新しいパスを使用するテーブル。これはおそらくまれな出来事です。
UPDATE menu_router SET include_file = 'sites/all/modules/custom/my_custom_namespace/includes/foo.inc' WHERE path = 'access-denied'
これらのクエリが実行されると、1秒しかかかりませんが、admin/config/development/performanceをヒットし、メニューパスが再構築されるようにキャッシュをクリアします。
Mark Sonnabaumからクールなツールをお試しください: Drush Rebuild Project Paths. 。プロセスを自動化します。私にとってはうまくいきました。使用します drush, 、 もちろん。
ただし、サイトデータベースのコピーでこれを試してみるという提案を2つ目にします。
記録のために、レジストリを再構築するための素晴らしいDrushコマンドがあります。 http://drupal.org/project/registry_rebuild
プロジェクトのページにはたくさんの情報があります。
まず、 いつも データベースをバックアップするので、何かがうまくいかずバックアップしなかった場合、簡単に自分をキックするのが簡単です。
モジュールを無効にするかどうかが重要かどうかはわかりません。念のため、やりたいと思うかもしれません。次に、これを行います:
- サイトをメンテナンスモード(siteName)/admin/config/development/maintenanceに置く
- モジュールをファイルシステムに物理的に移動します。
- (sitename)/admin/config/development/performanceでキャッシュをクリアするか、モジュールページを再節約します。
すべて完了! Drupalは、すべてのインストールされたモジュールを再検索します。
試してみてはいかがでしょうか レジストリの再構築 モジュール。それは私にとって毎回うまくいきました。
これについての引用は次のとおりです (モジュールのプロジェクト ページから)。
Drupal 7 では、レジストリが絶望的にパンクし、レジストリ (PHP クラスとそれに付随するファイルのリスト) を再構築する必要がある場合があります。ただし、システムがブートストラップしようとしているときに何らかのクラスが必要になるため、この通常のキャッシュ クリア アクティビティを実行できない場合があります。
使用できます レジストリ再構築 モジュール Drush RR
指図。
基本的にあなたがすることはこれらの手順です:
- モジュールを別のディレクトリに移動します
- レジストリ再構築は、システムテーブルを再構築して、モジュールを適切な場所に取得します。
私は最初にそれを学び/発見しました Drupaleasy Podcast#133, 、このモジュール / Drush CMDを使用する方法をさらに説明します。
PS:もちろん、最初にサイトのバックアップを実行します...
アクセス/管理/ビルド/モジュールシステムテーブルのパスを再構築します。 Drupalがもうブートストラップできなくなる場合があるため、この場合はこのソリューションが機能しません。それが機能しない場合は、使用できます Drush Rebuild Project Paths 前の答えで述べたように。ただし、ブートストラップを壊す前に、新しいDrushコマンドを追加する必要があります。新しいコマンドを追加するには、をチェックしてください readme'のコマンドセクション
私はいくつかの問題を抱えていました drush dl
モジュールディレクトリの問題のために機能しません。一般的に、私は物事を機能させるために単純に貼り付けることができるスタックの答えが好きです。ここでは、既に適切なサイトディレクトリにある場合は、Drush Rebuild Registryをインストールし、サイトで実行するいくつかの行があります。
pushd ~ # good if drush on your site is broken because of moved modules
drush dl -y registry_rebuild
popd
drush rr
私は真のDrupal-Eskの答えについて100%確信していませんが、私の経験では次のとおりです。
誤ってカスタムモジュールフォルダーの1つを、サーバーにftpingするときに別のカスタムモジュールフォルダーに移動しました。彼らはまだ働いていました。 Drupalは、別のモジュールのフォルダーにある場合でも、それを別のモジュールとして認識しているように見えました。モジュールを無効にする必要はありませんでした。
**私が移動したこのモジュールには.installファイルがありませんでしたので、それが重要かどうかはわかりません。
Drupal Distributionsはこれをうまく処理しないため、最近誤ってのコピーで終了した後 エンティティAPI の sites/all/
パノポリーサイトでは、これはどれも機能しませんでした。レジストリの再構築、モジュールページのロード、およびその他すべてが致命的なエラーを引き起こしました。
パノポリーの他の大量のモジュールに必要なエンティティAPIのようなものを移動する必要がある場合、モジュールを無効にすることも簡単ではありません。
これを解決するために、エンティティAPIの場合、次のことを行います。
システムテーブルのパスを更新します。
UPDATE `system` SET `filename` = REPLACE( `filename`, 'sites/all/modules/entity', 'profiles/panopoly/modules/contrib/entity' );
次に、レジストリを再構築します。
drush rr
Drupal 7
まず、試してみてください drush rr
.
ファイルを移動した後、機能しない場合は、Drupal Root dirで次のDrushコマンドを試してください。
drush sqlq "TRUNCATE cache; TRUNCATE cache_bootstrap;"
php -r "define('DRUPAL_ROOT', getcwd()); require_once DRUPAL_ROOT . '/includes/bootstrap.inc'; drupal_bootstrap(DRUPAL_BOOTSTRAP_SESSION); registry_rebuild(); registry_update(); cache_clear_all();"
drush -y cc all
上記が機能しない場合は、次のことでパスに関する古い情報がまだあるテーブルを見つけます。
drush --ordered-dump sql-dump | grep "sites/all/modules" # Change the path to the old one.
何も見つからない場合、それはあなたの外部キャッシュであることを意味します。
もしそうなら、それらを再起動することを忘れないでください、例:
killall -HUP memcached
drush eval "function_exists('xcache_clear_cache') && xcache_clear_cache();"
続きを見る: Drupalのキャッシュをクリアするためにどのような方法が使用されますか?
または、ファイルを移動した後、次のMySQLクエリを試すこともできます。
UPDATE system SET filename = REPLACE(filename, "sites/all/modules", "sites/newplace/modules") WHERE
filename LIKE "sites/all/modules/%" AND type = "module"
AND name IN ("my", "module", "whose", "path", "changed");
UPDATE registry SET filename = REPLACE(filename, "sites/all/modules", "sites/newplace/modules") WHERE
filename LIKE "sites/all/modules/%"
AND module IN ("my", "module", "whose", "path", "changed");
モジュールをcontrib/dev/patched/customサブフォルダーに移動することをお勧めします。しかし、パフォーマンスの向上はありませんが、これは実用的で審美的な理由で行われます。これにより、将来の開発者の生活が容易になります。
ライブサイトで問題なく、ほとんどのContribモジュールをサブフォルダーに移動できます。その後、キャッシュをクリアする必要があります。 Drushを使用していないため、キャッシュクリアリングページにアクセスできなくなった場合は、 /update.phpにアクセスするか、キャッシュテーブルを手動で切り捨てる必要があります。エンティティAPIモジュールを移動するとき、私は最後にしなければならなかっただけです。
コアモジュールの移動は技術的に可能ですが、これを行うことをお勧めしません。
更新:エンティティAPIのような移動モジュールには、レジストリの再構築が必要になる場合があります。をチェックしてください registry_rebuild ページ。
サイト/ALL/MODULESのSymリンクをサイト/ALL/CONTRIBに指すように追加できます。それがあなたの問題を解決するかどうかはわかりません。インストールプロファイルやDrush Makeファイルなど、他のソリューションもあります。私はそれらについて詳細を提供するのに十分な知りませんが、少なくともあなたが見ることができる方向です。