Come spostare i moduli installati da / sites / all / modules / * a / sites / all / contrib / modules / *

Ho cercato le risposte a questa domanda senza fortuna. Da ciò che osservo nella struttura del database, la posizione dei moduli è specificata nella tabella "sistema". L'unica soluzione che ho è scrivere una query SQL per aggiornare la colonna "nome file".

Esiste una soluzione migliore / più pulita per risolvere questo problema, ad esempio un modulo contrib?

Hai solo bisogno di spostare i moduli nella nuova posizione e ricostruire la registrazione. Quando il registro viene ricostruito, il percorso dei moduli verrà aggiornato. Controllare registry_rebuild().

Riesegue la scansione di tutto il codice nei moduli o include le directory, memorizzando la posizione di ciascuna interfaccia o classe nel database.

Tuttavia, ti consiglio di eseguire il backup del database prima di testarlo.

Se stai usando drush puoi anche ricostruire il registro usando il seguente comando:

drush cc registry

Puoi anche installare il registry_rebuildcomando per drush:

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

Ho ripristinato un backup dalla produzione localmente e ho provato a spostare le cose e colpire admin / module o eseguire register_rebuild () ma non ha impedito il lancio di errori fatali. Questo ha senso per me dato che alcuni moduli possono usare include o qualunque cosa nel loro hook_init (), oppure potresti avere un set di percorsi del router del menu che dipende da un modulo o includere che Drupal non riesce a trovare su bootstrap. In definitiva, questo è quello che ho fatto (i tuoi percorsi potrebbero essere diversi):

Passaggio 1: sostituire siti / tutti / moduli con siti / tutti / moduli / 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');

Passaggio 2: Sostituisci siti / tutti / moduli / contrib con siti / tutti / moduli / personalizzati per moduli personalizzati con spazio dei nomi

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

Passaggio 3: spostare i moduli dev in siti / 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%';

Passaggio 4: svuota le cache in modo che le cose si avviino correttamente

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

Nota: se si utilizza un modulo personalizzato o un contributo come LoginToboggan per gestire 403 (accesso negato) e si è disconnessi durante questo processo, potrebbe essere necessario aggiornare la include_filecolonna nella menu_rotertabella per utilizzare il nuovo percorso per il file include . Questo è probabilmente un evento raro.

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

Una volta eseguite queste query, che richiederanno solo una frazione di secondo, accedete a admin / config / development / performance e svuotano la cache in modo da ricostruire i percorsi dei menu.

Prova il fantastico strumento di Mark Sonnabaum: Drush Rebuild Project Paths . Automatizza il processo; ha funzionato alla grande per me. Usa Drush , ovviamente.

Tuttavia, suggerirò di provare questo su una copia del database del sito.

Per la cronaca, c'è un ottimo comando drush per ricostruire il registro: http://drupal.org/project/registry_rebuild

Ci sono molte informazioni nella pagina del progetto.

In primo luogo, esegui sempre il backup del database, così semplice da fare che ti prenderai a calci se qualcosa va storto e non hai eseguito il backup.

Non sono sicuro che sia importante disabilitare o meno i moduli; potresti volerlo fare, per ogni evenienza. Quindi fai questo:

1. Metti il ​​tuo sito in modalità manutenzione su (sitename) / admin / config / development / maintenance
2. Sposta fisicamente i tuoi moduli nel file system.
3. Svuota la cache in (sitename) / admin / config / development / performance o salva nuovamente la pagina dei moduli.

Tutto fatto! Drupal ricercherà tutti i moduli installati.

Perché non provi il modulo di ricostruzione del registro . Ha funzionato ogni volta per me.

Ecco una citazione al riguardo (dalla pagina del progetto del modulo):

Ci sono momenti in Drupal 7 in cui il registro viene irrimediabilmente cancellato ed è necessario ricostruire il registro (un elenco di classi PHP e i file con cui vanno). A volte, tuttavia, non è possibile svolgere questa normale attività di svuotamento della cache perché è necessaria una classe quando il sistema sta tentando di avviarsi.

È possibile utilizzare il modulo Registry Rebuild , che si integra con Drush tramite il Drush RRcomando.

Fondamentalmente ciò che fai sono questi passaggi:

1. Spostare i moduli in un'altra directory e
2. Registry Rebuild ricostruirà quindi la tabella di sistema per ottenere i moduli nel posto giusto.

L'ho imparato / scoperto per la prima volta tramite DrupalEasy Podcast # 133 , che spiega ulteriormente come utilizzare questo modulo / drush cmd.

PS: certo, prima esegui un backup del tuo sito ...

Visita / admin / build / modules ricostruirà i percorsi nella tabella di sistema. A volte drupal non può più bootstrap, quindi questa soluzione non funziona in questo caso. Se non funziona, è possibile utilizzare Drush Rebuild Project Paths come indicato in una risposta precedente. Tuttavia, devi aggiungere il nuovo comando drush prima di interrompere il bootstrap. Per aggiungere il nuovo comando, controlla la sezione COMANDI del readme

Ho avuto qualche problema a drush dlnon funzionare a causa dei problemi di directory del modulo. In genere mi piacciono le risposte in pila che posso semplicemente incollare per far funzionare le cose. Qui trovi un paio di righe che installeranno Drush Rebuild Registry ed eseguiranno il tuo sito se sei già nella directory del sito corretta.

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

Non sono sicuro al 100% su una vera risposta drupal-esk ma nella mia esperienza:

Ho accidentalmente spostato una delle mie cartelle del modulo personalizzato in un'altra cartella del modulo personalizzato durante l'FTPing sul server. Entrambi hanno ancora funzionato. Drupal sembrava averlo riconosciuto come un modulo separato anche mentre si trovava nella cartella di un altro modulo. Non ho dovuto disabilitare il modulo.

** Questo modulo che ho spostato NON aveva un file .install, quindi non sono sicuro che sia importante.

Distribuzioni Drupal non gestiscono questo bene, quindi di recente dopo aver accidentalmente finire con una copia di entità API in sites/all/su un sito Panopoly, niente di tutto questo ha funzionato. La ricostruzione del registro, il caricamento della pagina dei moduli e tutto il resto ha causato un errore fatale.

Disabilitare il modulo non è semplice neanche se devi spostare qualcosa come Entity API che è richiesto da tonnellate di altri moduli in Panopoly.

Per risolvere questo, per Entity API faresti qualcosa del genere:

1. Aggiorna il percorso nella tabella di sistema:

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

2. Quindi ricostruire il registro:

   drush rr

Drupal 7

Prima di tutto prova drush rr.

Se non funziona, dopo aver spostato i file, prova i seguenti comandi Drush nella directory principale di 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 sopra non funziona, trova la tabella che contiene ancora le vecchie informazioni sul percorso:

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

Se non viene trovato nessuno, significa che è la cache esterna.

In tal caso, non dimenticare di riavviarli, ad esempio:

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

Vedi di più: Quale metodo viene utilizzato per cancellare le cache in Drupal?

In alternativa, puoi provare le seguenti query MySQL dopo aver spostato i file:

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

Si consiglia di spostare i moduli in sottocartelle contrib / dev / patched / custom. Non ci sono miglioramenti delle prestazioni, tuttavia questo è fatto per motivi pratici ed estetici. Ciò renderà più facile la vita dei futuri sviluppatori.

Puoi spostare la maggior parte dei moduli contrib nelle sottocartelle senza problemi su un sito live. In seguito dovresti cancellare le cache. Se non usi drush e scopri che non puoi più accedere alla pagina di svuotamento della cache, dovrai visitare /update.php o troncare manualmente le tabelle della cache. Ho sempre dovuto fare l'ultimo bit quando ho spostato il modulo API entità.

Lo spostamento di moduli core è tecnicamente possibile, ma non lo consiglierei né vedo alcun motivo valido per farlo.

Aggiornamento: lo spostamento di moduli come l'API di entità potrebbe richiedere la ricostruzione del registro. Dai un'occhiata alla pagina register_rebuild .

Puoi semplicemente aggiungere un link sym nella directory siti / all / modules che punta a siti / all / contrib. Non sono sicuro che risolva il tuo problema. Esistono anche altre soluzioni, incluso il profilo di installazione o un file drush make. Non ne so abbastanza per fornire dettagli su di essi, ma almeno è una direzione che puoi guardare.