Как переместить установленные модули из / sites / all / modules / * в / sites / all / contrib / modules / *

Я безуспешно искал ответы на этот вопрос. Из того, что я наблюдаю в структуре базы данных, расположение модулей указано в таблице «system». Единственное решение, которое у меня есть, - написать SQL-запрос для обновления столбца «имя файла».

Есть ли лучшее / более чистое решение для решения этой проблемы, например, модуль contrib?

Вам нужно только переместить свои модули в новое место и перестроить реестр. Когда реестр перестраивает, путь к модулям будет обновлен. Проверьте registry_rebuild().

Повторно сканирует весь код в модулях или включает в себя каталоги, сохраняя расположение каждого интерфейса или класса в базе данных.

Хотя я бы порекомендовал вам сделать резервную копию базы данных перед тестированием.

Если вы используете drush, вы также можете перестроить реестр, используя следующую команду:

drush cc registry

Вы также можете установить registry_rebuildкоманду для drush:

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

Я восстановил резервную копию с производства локально и попытался просто переместить вещи и нажать admin / modules или запустить registry_rebuild (), но это не остановило появление фатальных ошибок. Это имеет смысл для меня, так как некоторые модули могут использовать include или что-либо в их hook_init (), или у вас может быть установлен путь к маршрутизатору меню, который зависит от модуля, или include, который Drupal не может найти при начальной загрузке. В конечном счете, это то, что я сделал (ваши пути могут отличаться):

Шаг 1: Заменить сайты / все / модули на сайты / все / модули / 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: Замените сайты / все / модули / вклада сайтами / всеми / модулями / на заказ для пользовательских модулей с пространством имен

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

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, для обработки 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 и очистите кэш, чтобы перестроить пути меню.

Попробуйте крутой инструмент от Марка Соннабаума: Drush Rebuild Projects Paths . Это автоматизирует процесс; отлично работал для меня. Использует Drush , конечно.

Я поддержу предположение, что вы попробуете это на копии базы данных вашего сайта.

Для записи есть отличная команда drush для перестройки реестра: http://drupal.org/project/registry_rebuild

На странице проекта много информации.

Во-первых, всегда делайте резервные копии своей базы данных, настолько просто, что вы будете бить себя, если что-то пойдет не так, и вы не сделали резервную копию.

Я не уверен, имеет ли это значение, если вы отключите модули или нет; Вы можете сделать это, на всякий случай. Тогда сделайте это:

1. Переведите ваш сайт в режим обслуживания по адресу (sitename) / admin / config / development / maintenance
2. Физически переместите свои модули в файловую систему.
3. Очистите кеши в (sitename) / admin / config / development / performance или просто заново сохраните страницу модулей.

Все сделано! Drupal проведет повторный поиск всех установленных модулей.

Почему бы вам не попробовать перестройку реестра модуль . Это работало каждый раз для меня.

Вот цитата об этом (со страницы проекта модуля):

В Drupal 7 бывают случаи, когда реестр безнадежно цепляется, и вам нужно перестроить реестр (список классов PHP и файлов, с которыми они работают). Иногда, однако, вы не можете выполнять эту обычную операцию очистки кэша, потому что какой-то класс требуется, когда система пытается загрузиться.

Вы можете использовать модуль Registry Rebuild , который интегрируется с Drush черезDrush RR команду.

В основном то, что вы делаете, это следующие шаги:

1. Переместите ваши модули в другой каталог и
2. Затем Registry Rebuild перестроит системную таблицу, чтобы расположить модули в нужном месте.

Я впервые узнал / обнаружил это с помощью подкаста DrupalEasy # 133 , который дополнительно объясняет, как можно использовать этот модуль / drush cmd.

PS: Конечно, сначала сделайте резервную копию вашего сайта ...

Посетите / admin / build / modules, он восстановит пути в системной таблице. Иногда 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

Я не уверен на 100% в правильном ответе drupal-esk, но по моему опыту:

Я случайно переместил одну из своих пользовательских папок модуля в другую пользовательскую папку модуля при FTP-соединении с сервером. Они оба все еще работали. Drupal, похоже, распознал его как отдельный модуль, даже когда он находился в папке другого модуля. Мне не пришлось отключать модуль.

** У этого модуля, который я переместил, НЕ было файла .install, поэтому я не уверен, имеет ли это значение.

В дистрибутивах Drupal это плохо обрабатывается, поэтому в последнее время после того, как случайно оказался экземпляр Entity API вsites/all/ на сайте Panopoly, ни один из этого работал. Перестройка реестра, загрузка страницы модулей и все остальное вызвало фатальную ошибку.

Отключить модуль тоже непросто, если вам нужно переместить что-то вроде Entity API, что требуется множеству других модулей в Panopoly.

Чтобы решить эту проблему, для 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.

Если это не сработает, после перемещения файлов попробуйте следующие команды Drush в корневом каталоге Drupal:

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 .

Вы можете просто добавить ссылку sym в директорию sites / all / modules, указывающую на сайты / all / contrib. Я не уверен, решит ли это вашу проблему. Есть и другие решения, в том числе установочный профиль или файл drush make. Я не знаю достаточно, чтобы предоставить подробности о них, но по крайней мере это направление, на которое вы можете посмотреть.