インストールされたモジュールを/ sites / all / modules / *から/ sites / all / contrib / modules / *に移動する方法

私はこの質問への答えを全然運よく探していました。データベース構造で観察したものから、モジュールの場所は「システム」テーブルで指定されています。私が持っている唯一の解決策は、SQLクエリを記述して 'filename'列を更新することです。

これを解決するためのより良い/よりクリーンなソリューション、例えばcontribモジュールはありますか？

モジュールを新しい場所に移動してレジストリを再構築するだけです。レジストリが再構築されると、モジュールへのパスが更新されます。確認してくださいregistry_rebuild()。

モジュール内のすべてのコードを再スキャンするか、ディレクトリを含めて、各インターフェイスまたはクラスの場所をデータベースに保存します。

ただし、これをテストする前にデータベースをバックアップすることをお勧めします。

drushを使用している場合は、次のコマンドを使用してレジストリを再構築することもできます。

drush cc registry

registry_rebuilddrush のコマンドをインストールすることもできます。

// install registry_rebuild
drush dl registry_rebuild
// rebuild the registry
drush rr

運用環境からローカルにバックアップを復元し、物事を移動してadmin / modulesを押すか、registry_rebuild（）を実行しようとしましたが、致命的なエラーがスローされるのを止めませんでした。いくつかのモジュールはhook_init（）のincludeまたは何でも使用するか、モジュールに依存するメニュールーターパスセットがあるか、Drupalがブートストラップで見つけられないことがあるため、これは理にかなっています。最終的に、これは私がやったことです（あなたのパスは異なる場合があります）：

ステップ1：sites / all / modulesをsites / 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：カスタム名前空間モジュールのsites / all / modules / contribをsites / all / modules / customに置き換えます

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：devモジュールをsites / all / modules / devに移動します

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を使用します。

ただし、サイトデータベースのコピーでこれを試すことをお勧めします。

記録のために、レジストリを再構築するための素晴らしい駆除コマンドがあります：http ://drupal.org/project/registry_rebuild

プロジェクトのページには多くの情報があります。

まず、データベースを常にバックアップします。非常に簡単なので、何かがうまくいかず、バックアップしなかった場合は自分でキックします。

モジュールを無効にするかどうかが重要かどうかはわかりません。念のため、あなたはそれをしたいと思うかもしれません。次にこれを行います：

1. サイトを（サイト名）/ admin / config / development / maintenanceのメンテナンスモードにします。
2. ファイルシステムでモジュールを物理的に移動します。
3. （サイト名）/ admin / config / development / performanceのキャッシュをクリアするか、単にモジュールページを再保存します。

出来た！Drupalは、インストールされているすべてのモジュールを再検索します。

Registry Rebuildモジュールを試してみませんか。それは私のために毎回働いた。

モジュールのプロジェクトページからの引用です：

Drupal 7には、レジストリが絶望的に​​ホースされ、レジストリ（PHPクラスとそれらが付属するファイルのリスト）を再構築する必要がある場合があります。ただし、システムがブートストラップしようとしているときに何らかのクラスが必要になるため、この通常のキャッシュクリアアクティビティを実行できない場合があります。

コマンドを介してDrushと統合するレジストリ再構築モジュールを使用できますDrush RR。

基本的には、次の手順を実行します。

1. モジュールを別のディレクトリに移動し、そして
2. その後、レジストリの再構築によりシステムテーブルが再構築され、モジュールが適切な場所に配置されます。

私は最初にDrupalEasy Podcast＃133でそれを学び/発見しました。これはこのモジュール/ drush cmdの使用方法をさらに説明しています。

PS：もちろん、最初にサイトのバックアップを実行します...

/ admin / build / modulesにアクセスすると、システムテーブルのパスが再構築されます。drupalがブートストラップできない場合があり、この場合このソリューションは機能しません。うまくいかない場合は、前の回答で述べたように、プロジェクトパスの再構築を使用できます 。ただし、ブートストラップを解除する前に、新しいdrushコマンドを追加する必要があります。新しいコマンドを追加するには、readmeのCOMMANDSセクションを確認してください。

私はいくつかの問題を抱えていました drush dlモジュールディレクトリの問題のため、動作ないという問題がありました。一般的に、私は単純に貼り付けて作業を進めることができるスタックアンサーが好きです。ここで、すでに適切なサイトディレクトリにいる場合は、Drush Rebuild Registryをインストールしてサイトで実行する2、3行を見つけます。

pushd ~  # good if drush on your site is broken because of moved modules
drush dl -y registry_rebuild
popd 
drush rr

私は本当のdrupal-eskの答えに100％確信はありませんが、私の経験では：

サーバーにFTP転送するときに、誤ってカスタムモジュールフォルダーの1つを別のカスタムモジュールフォルダーに移動しました。彼らは両方ともまだ働いた。Drupalは、別のモジュールのフォルダーにある場合でも、別のモジュールとして認識したようです。モジュールを無効にする必要はありませんでした。

**私が移動したこのモジュールには.installファイルがなかったため、それが重要かどうかはわかりません。

Drupalの分布は非常に最近の後に偶然のコピーで終わる、このうまく処理できないエンティティAPIにsites/all/Panopolyサイトで、これのどれも働きました。レジストリの再構築、モジュールページのロード、その他すべてが致命的なエラーを引き起こしました。

モジュールの無効化は、Panopolyの他の多くのモジュールが必要とするEntity APIのようなものを移動する必要がある場合にも簡単ではありません。

これを解決するには、Entity APIで次のようにします。

1. システムテーブルのパスを更新します。

   UPDATE `system` 
     SET `filename` = REPLACE(
       `filename`, 
       'sites/all/modules/entity', 
       'profiles/panopoly/modules/contrib/entity'
     );

2. 次に、レジストリを再構築します。

   drush rr

Drupal 7

まずは試してみてくださいdrush rr。

機能しない場合は、ファイルを移動した後、Drupalルートディレクトリで次の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ページを。

sites / all / contribを指すsites / all / modulesディレクトリにsymリンクを追加できます。問題が解決するかどうかはわかりません。インストールプロファイルや、drush make fileなど、他のソリューションもあります。それらの詳細を提供するのに十分な知識はありませんが、少なくともそれはあなたが見ることができる方向です。