Como mover os módulos instalados de / sites / all / modules / * para / sites / all / contrib / modules / *

Eu tenho procurado as respostas para esta pergunta sem sorte alguma. Pelo que observo na estrutura do banco de dados, a localização dos módulos é especificada na tabela 'sistema'. A única solução que tenho é escrever uma consulta SQL para atualizar a coluna 'filename'.

Existe uma solução melhor / mais limpa para resolver isso, por exemplo, um módulo de contribuição?

Você só precisa mover seus módulos para o seu novo local e reconstruir o registro. Quando o registro recriar, o caminho para os módulos será atualizado. Verifique registry_rebuild().

Recupera todo o código em módulos ou inclui diretórios, armazenando o local de cada interface ou classe no banco de dados.

Embora, eu recomendo que você faça backup do banco de dados antes de testar isso.

Se você estiver usando drush, também poderá recriar o registro usando o seguinte comando:

drush cc registry

Você também pode instalar o registry_rebuildcomando drush:

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

Eu restaurei um backup da produção localmente e tentei apenas mover as coisas e pressionar admin / modules ou executar o registry_rebuild (), mas isso não impediu que erros fatais fossem lançados. Isso faz sentido para mim, já que alguns módulos podem usar include ou o que quer que seja em seu hook_init (), ou você pode ter um caminho de roteador de menu definido que depende de um módulo ou que o Drupal não pode encontrar no bootstrap. Por fim, foi o que eu fiz (seus caminhos podem ser diferentes):

Etapa 1: Substitua sites / all / modules por 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');

Etapa 2: Substitua sites / all / modules / contrib por sites / all / modules / custom para módulos personalizados no namespace

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_%';

Etapa 3: Mova os módulos de desenvolvimento para 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%';

Etapa 4: limpe os caches para que as coisas sejam inicializadas corretamente

TRUNCATE TABLE cache
TRUNCATE TABLE cache_bootstrap
TRUNCATE TABLE cache_menu
TRUNCATE TABLE cache_page
TRUNCATE TABLE cache_path

Nota: Se você usar um módulo personalizado ou um contrib como o LoginToboggan para manipular 403 (acesso negado) e você for desconectado durante esse processo, talvez seja necessário atualizar a include_filecoluna na menu_rotertabela para usar o novo caminho para o arquivo de inclusão . Provavelmente é uma ocorrência rara.

UPDATE menu_router SET include_file = 'sites/all/modules/custom/my_custom_namespace/includes/foo.inc' WHERE path = 'access-denied'

Depois que essas consultas forem executadas - o que levará apenas uma fração de segundo -, pressione admin / config / development / performance e limpe o cache para que os caminhos do menu sejam reconstruídos.

Experimente a ferramenta legal de Mark Sonnabaum: Drush Rebuild Project Paths . Automatiza o processo; funcionou muito bem para mim. Usa Drush , é claro.

Em segundo lugar, sugerirei que você tente fazer isso em uma cópia do banco de dados do site.

Para o registro, há um ótimo comando drush para reconstruir o registro: http://drupal.org/project/registry_rebuild

Há muitas informações na página do projeto.

Em primeiro lugar, sempre faça backup do seu banco de dados, de maneira simples, você se chutará se algo der errado e você não fez o backup.

Não tenho certeza se isso importa se você desabilita os módulos ou não; você pode querer fazê-lo, apenas por precaução. Então faça o seguinte:

1. Coloque seu site no modo de manutenção em (sitename) / admin / config / development / maintenance
2. Mova fisicamente seus módulos no sistema de arquivos.
3. Limpe seus caches em (sitename) / admin / config / development / performance ou apenas salve novamente a página dos módulos.

Tudo feito! O Drupal irá procurar todos os módulos instalados.

Por que você não tenta o módulo Registry Rebuild ? Funcionou toda vez para mim.

Aqui está uma citação sobre ele (na página do projeto do módulo):

Há momentos no Drupal 7 em que o registro fica irremediavelmente manguito e você precisa reconstruí-lo (uma lista de classes PHP e os arquivos com os quais eles acompanham). Às vezes, porém, você não pode executar esta atividade regular de limpeza de cache, porque alguma classe é necessária quando o sistema está tentando inicializar.

Você pode usar o módulo Registry Rebuild , que se integra ao Drush por meio do Drush RRcomando

Basicamente, o que você faz são estas etapas:

1. Mova seus módulos para outro diretório e
2. A Reconstrução do Registro reconstruirá a tabela do sistema para colocar os módulos no lugar certo.

Eu o aprendi / descobri pela primeira vez através do DrupalEasy Podcast # 133 , que explica mais detalhadamente como esse módulo / drush cmd pode ser usado.

PS: Claro, primeiro faça um backup do seu site ...

Visite / admin / build / modules, ele reconstruirá os caminhos na tabela do sistema. Às vezes, o drupal não pode mais inicializar, então essa solução não funciona nesse caso. Se não funcionar, você pode usar o Drush Rebuild Project Paths como dito em uma resposta anterior. Você precisa adicionar o novo comando drush antes de interromper a inicialização. Para adicionar o novo comando, consulte a seção COMMANDS do readme

Eu tive alguns problemas ao drush dlnão trabalhar devido aos problemas de diretório do módulo. Geralmente eu gosto de respostas de pilha que eu posso simplesmente colar para fazer as coisas funcionarem. Aqui você encontra algumas linhas que instalam o Drush Rebuild Registry e o executam no seu site, se você já estiver no diretório do site apropriado.

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

Não tenho 100% de certeza sobre uma resposta drupal-esk verdadeira, mas na minha experiência:

Mudei acidentalmente uma das minhas pastas de módulo personalizadas para outra pasta de módulo personalizado ao enviar FTP para o servidor. Os dois ainda trabalhavam. Drupal parecia tê-lo reconhecido como um módulo separado, mesmo enquanto estava na pasta de outro módulo. Não precisei desativar o módulo.

** Este módulo que eu mudei NÃO tinha um arquivo .install, então não tenho certeza se isso importa.

As distribuições do Drupal não lidam bem com isso; recentemente, depois de terminar acidentalmente com uma cópia da API da entidade em sites/all/um site do Panopoly, nada disso funcionou. A reconstrução do registro, o carregamento da página de módulos e tudo o mais causou um erro fatal.

Desabilitar o módulo também não é simples, se você precisar mover algo como a API de entidade, exigido por muitos outros módulos no Panopoly.

Para resolver isso, para a API de entidade, você faria algo assim:

1. Atualize o caminho na tabela do sistema:

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

2. Em seguida, recrie o registro:

   drush rr

Drupal 7

Primeiro de tudo, tente drush rr.

Se não funcionar, depois de mover os arquivos, tente os seguintes comandos Drush no diretório raiz do 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

Se acima não funcionar, encontre a tabela que ainda possui as informações antigas sobre o caminho:

drush --ordered-dump sql-dump | grep "sites/all/modules" # Change the path to the old one.

Se nenhum for encontrado, isso significa que é seu cache externo.

Nesse caso, não esqueça de reiniciá-los, por exemplo:

killall -HUP memcached
drush eval "function_exists('xcache_clear_cache') && xcache_clear_cache();"

Veja mais: Qual método é usado para limpar caches no Drupal?

Como alternativa, você pode tentar as seguintes consultas MySQL após mover os arquivos:

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

É recomendável mover seus módulos para subpastas contrib / dev / patched / custom. No entanto, não há ganhos de desempenho, isso é feito por razões práticas e estéticas. Isso facilitará a vida de futuros desenvolvedores.

Você pode mover a maioria dos módulos contrib para subpastas sem problemas em um site ativo. Você deve limpar os caches posteriormente. Se você não usar drush e achar que não pode mais acessar a página de limpeza de cache, visite /update.php ou trunque manualmente as tabelas de cache. Eu só tive que fazer o último bit ao mover o módulo da API da entidade.

Mover módulos principais é tecnicamente possível, mas eu não o recomendaria nem vejo nenhuma razão válida para isso.

Atualização: A movimentação de módulos como a API da entidade pode exigir a reconstrução do registro. Confira a página registry_rebuild .

Você pode simplesmente adicionar um link sym no diretório sites / all / modules apontando para sites / all / contrib. Não tenho certeza se isso resolve o seu problema. Também existem outras soluções, incluindo o perfil de instalação ou um arquivo make drush. Não sei o suficiente para fornecer detalhes sobre eles, mas pelo menos é uma direção que você pode olhar.