web-dev-qa-db-ja.com

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

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

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

7installing
34
Logi

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

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

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

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

drush cc registry

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

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

ローカルで本番環境からバックアップを復元し、移動してadmin/modulesにアクセスするか、registry_rebuild（）を実行しようとしましたが、致命的なエラーがスローされるのを防ぎませんでした。一部のモジュールは、それらのhook_init（）でインクルードまたは何かを使用する可能性があるため、または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：開発モジュールを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：キャッシュがクリアされるように、bootstrap適切に

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'

これらのクエリが実行されたら（ほんの一瞬で完了します）、admin/config/development/performanceにアクセスしてキャッシュをクリアし、メニューパスを再構築します。

10
Charlie Schliesser

Mark Sonnabaumのクールなツールを試してください： Drush Rebuild Project Paths 。プロセスを自動化します。私にとってはうまくいきました。もちろん Drush を使用します。

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

9
greg_1_anderson

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

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

7
jonhattan

まず、alwaysデータベースをバックアップするので、何かがうまくいかず、バックアップしなかった場合に簡単に実行できます。

モジュールを無効にするかどうかが重要かどうかはわかりません。万が一に備えてそれを実行したいかもしれません。次にこれを行います：

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

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

5
John Laine

Registry Rebuild モジュールを試してみませんか。毎回うまくいきました。

これについての引用は次のとおりです（モジュールのプロジェクトページから）：

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

4
drupalastic

Drush RRコマンドを使用してDrushと統合する Registry Rebuild モジュールを使用できます。

基本的にあなたがすることはこれらのステップです：

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

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

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

3
Pierre.Vriens

モジュールディレクトリの問題のため、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
2
kqw

私は真のdrupal-eskの答えを100％確信していませんが、私の経験では：

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

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

2
Exziled

/ admin/build/modulesにアクセスすると、システムテーブルのパスが再構築されます。 drupalできないこともあるbootstrapなので、この場合このソリューションは機能しません。機能しない場合は Drush Rebuild Projectパス 前の回答で述べたように、中断する前に新しいdrushコマンドを追加する必要がありますbootstrapただし、新しいコマンドを追加するには readme 'を確認してくださいs COMMANDSセクション

2
Zatox

モジュールをcontrib/dev/patched/customサブフォルダーに移動することをお勧めします。パフォーマンスの向上はありませんが、これは実用的および審美的な理由で行われます。これにより、将来の開発者の生活が楽になります。

ライブサイトで問題なく、ほとんどのcontribモジュールをサブフォルダーに移動できます。後でキャッシュをクリアする必要があります。 drushを使用せず、キャッシュ消去ページにアクセスできない場合は、/ update.phpにアクセスするか、キャッシュテーブルを手動で切り捨てる必要があります。エンティティAPIモジュールを移動するときは、最後のビットを実行するだけで済みました。

コアモジュールを移動することは技術的には可能ですが、お勧めしませんし、これを行う正当な理由もわかりません。

更新：エンティティAPIのようなモジュールを移動するには、レジストリの再構築が必要になる場合があります。 registry_rebuild ページを確認してください。

1
gbyte.co

Drupalディストリビューションはこれをうまく処理しないため、Panopolyサイトのsites/all/に Entity API のコピーが誤って作成された後、最近はどれも機能しませんでした。レジストリの再構築、モジュールページの読み込み、その他すべてにより、致命的なエラーが発生しました。

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

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

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

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

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

    drush rr
1
ergophobe

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");
1
kenorb