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


34

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

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

Ответы:


27

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

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

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

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

drush cc registry

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

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

Если я правильно понимаю, вы также можете registry_fileобрезать свою таблицу, что заставит drupal повторно сканировать все файлы и перестроить таблицу.
Циклон-код

3
Усечение таблицы звучит как плохая идея и, скорее всего, приведет к полностью сломанному сайту.
Бердир

@Berdir - согласитесь, это звучит как плохая идея. Но, только что попробовал и, кажется, работает. Сначала я сделал резервную копию и обрезал всю таблицу с помощью DELETE FROM registry_file;и добавил вызов rebuild_registry()в мой page.tpl.php.
Циклон-код

Это слишком сложно, просто делай то, что сказал Джон Лейн , это всегда работает для меня.
Джим Киркпатрик

1
@JimKirkpatrick - Вы правы, нет необходимости отключать модули.
Cyclonecode

10

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


Спасибо за это! Я попробовал шаги, упомянутые в верхних ответах, но это не помогло в моем случае. Я подозреваю, что кому-либо на сайте, размещенном в Pantheon, необходимо выполнить эти инструкции db в своем ответе, а затем выполнить «drush registry-rebuild» и «drush cc registry»
Энн Бонэм,

Да, и на Пантеоне я нигде не мог получить сайт с модулем Redis, кроме sites / all / modules - поэтому я просто сдался и оставил этот один модуль в папке корневых модулей. Ну хорошо - по крайней мере, мои другие модули хорошо организованы.
Энн Бонэм

Для тех, кто использует LoginToboggan, вот 3 команды MySQL, которые вам понадобятся:update menu_router set include_file = 'sites/all/modules/contrib/logintoboggan/logintoboggan.admin.inc' WHERE path = 'admin/config/system/logintoboggan'; update menu_router set include_file = 'sites/all/modules/contrib/logintoboggan/logintoboggan.validation.inc' WHERE path = 'toboggan/revalidate/%'; update menu_router set include_file = 'sites/all/modules/contrib/logintoboggan/logintoboggan.validation.inc' WHERE path = 'user/validate/%/%/%';
tyler.frankenstein

9

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

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


7

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

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


Это мой самый предпочтительный метод перемещения модулей. У меня было несколько модулей, sites/all/modulesкоторые должны были быть перемещены в contribподкаталог. Все, что мне нужно было,drush dl registry_rebuild; mv OLD_PATH/module NEW_PATH/module; drush rr
Sumeet Pareek

Это сработало для меня. Сначала я переместил все свои модули, затем сделал registry_rebuild
gerl

Интересно, что drush rr --fire-bazookaприводит к ошибкам, но drush rrэто хорошо.
Алексей Скрипник

5

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

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

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

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


+1 для режима сопровождения, всегда приятно сделать это до чего-то вроде этого
Cyclonecode

1
Это вызывает фатальные ошибки 100% времени для меня. Может быть, это работает, если вы перемещаете модули, которые не имеют зависимостей или что-то еще.
эргофоб

4

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

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

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


Хотя это может теоретически ответить на вопрос, было бы предпочтительным включить здесь основные части ответа и предоставить ссылку для справки. Если существует процедура перемещения модулей, включающая использование связанного с вами модуля, опишите его.
Молот

Нет теории ... это работает. Следуйте инструкциям на странице. Я использовал метод drush, и он просто работал.
ИЛЛИН

3

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

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

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

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

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


3
Я второй это. Резервное копирование сайта. Переместите все модули в новые папки. Запустите восстановление реестра в drush или просто следуйте инструкциям и перейдите к включенному файлу php, чтобы запустить его. Просто.
Коллинз

2

Посетите / admin / build / modules, он восстановит пути в системной таблице. Иногда drupal больше не может загрузиться, поэтому в этом случае это решение не работает. Если это не работает, вы можете использовать Drush Rebuild Project Paths, как сказано в предыдущем ответе. Вы должны добавить новую команду drush перед тем, как прервать загрузку. Чтобы добавить новую команду, ознакомьтесь с разделом КОМАНДЫ readme.


2

У меня были некоторые проблемы с 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

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

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

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


Файл установки предназначен только для процедур, вызываемых во время установки модуля, и не является обязательным. Это сработало, потому что вы можете иметь любую структуру папок в / sites / all / modules, drupal будет рекурсивно искать файлы .info.
gbyte.co

@ gbyte.co спасибо за разъяснения по этому поводу! Я знал об установочном файле, но не знал о рекурсивном процессе поиска файлов .info в drupal. Я подумал, что не имеет значения, в какой подпапке они находятся, но хорошо, чтобы получить твердый ответ!
Изгнано

1

В дистрибутивах 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

1

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

1

Перемещение ваших модулей в подпапки contrib / dev / patched / custom рекомендуется. Однако прироста производительности нет, это сделано по практическим и эстетическим соображениям. Это облегчит жизнь будущим разработчикам.

Вы можете без проблем переместить большинство модулей contrib во вложенные папки на реальном сайте. Вы должны очистить кеш после этого. Если вы не используете drush и обнаруживаете, что больше не можете получить доступ к странице очистки кэша, вам придется посетить /update.php или вручную обрезать таблицы кэша. Я только когда-либо должен был сделать последний бит при перемещении модуля API объекта.

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

Обновление: перемещение модулей, таких как API-интерфейс сущностей, может потребовать перестройки реестра. Проверьте страницу Registry_Rebuild .


-4

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


5
В долгосрочной перспективе это головная боль из-за обслуживания
AgA

это взломать и обойти все исправление ... не очень хорошее решение.
ИЛЛИН

да гораздо лучше использовать drush registry_rebuild теперь, когда он доступен.
Лексикант
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.