Cómo mover los módulos instalados de / sites / all / modules / * a / sites / all / contrib / modules / *

He estado buscando las respuestas a esta pregunta sin suerte en absoluto. Por lo que observo en la estructura de la base de datos, la ubicación de los módulos se especifica en la tabla 'sistema'. La única solución que tengo es escribir una consulta SQL para actualizar la columna 'nombre de archivo'.

¿Existe una solución mejor / más limpia para resolver esto, por ejemplo, un módulo contrib?

Solo necesita mover sus módulos a su nueva ubicación y reconstruir el registro. Cuando el registro se reconstruya, la ruta a los módulos se actualizará. Compruebe registry_rebuild().

Vuelve a analizar todo el código en módulos o incluye directorios, almacenando la ubicación de cada interfaz o clase en la base de datos.

Sin embargo, le recomendaría que haga una copia de seguridad de su base de datos antes de probar esto.

Si está utilizando drush, también podría reconstruir el registro con el siguiente comando:

drush cc registry

También puede instalar el registry_rebuildcomando para drush:

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

Restablecí una copia de seguridad de la producción local e intenté simplemente mover cosas y presionar admin / modules o ejecutar register_rebuild () pero no impidió que se produjeran errores fatales. Esto tiene sentido para mí, ya que algunos módulos pueden usar incluir o lo que sea en su hook_init (), o puede tener una ruta de enrutador de menú establecida que depende de un módulo o incluir que Drupal no puede encontrar en bootstrap. En última instancia, esto es lo que hice (tus caminos pueden ser diferentes):

Paso 1: Reemplazar sitios / todos / módulos con sitios / todos / módulos / 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');

Paso 2: Reemplace sites / all / modules / contrib con sites / all / modules / custom por módulos de espacios de nombres personalizados

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

Paso 3: Mueva los módulos de desarrollo a sitios / todos / módulos / 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%';

Paso 4: borra los cachés para que las cosas arranquen correctamente

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

Nota: Si usa un módulo personalizado o una contribución como LoginToboggan para manejar 403 (acceso denegado) y ha cerrado la sesión durante este proceso, es posible que deba actualizar la include_filecolumna en la menu_rotertabla para usar la nueva ruta para el archivo de inclusión . Esto es probablemente una ocurrencia rara.

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

Una vez que se hayan ejecutado estas consultas, lo que solo tomará una fracción de segundo, presione admin / config / development / performance y borre la memoria caché para que se reconstruyan las rutas del menú.

Pruebe la herramienta genial de Mark Sonnabaum: Drush Rebuild Project Paths . Automatiza el proceso; funcionó muy bien para mí Utiliza Drush , por supuesto.

Sin embargo, haré una segunda sugerencia para que pruebes esto en una copia de la base de datos de tu sitio.

Para el registro, hay un gran comando drush para reconstruir el registro: http://drupal.org/project/registry_rebuild

Hay mucha información en la página del proyecto.

En primer lugar, siempre haga una copia de seguridad de su base de datos, por lo que es muy fácil hacerlo si algo sale mal y no hizo una copia de seguridad.

No estoy seguro si importa si deshabilita los módulos o no; es posible que desee hacerlo, por si acaso. Entonces haz esto:

1. Ponga su sitio en modo de mantenimiento en (nombre del sitio) / admin / config / development / maintenance
2. Mueva físicamente sus módulos en el sistema de archivos.
3. Borre sus cachés en (sitename) / admin / config / development / performance, o simplemente vuelva a guardar la página de módulos.

¡Todo listo! Drupal volverá a buscar todos los módulos instalados.

¿Por qué no prueba el módulo Reconstruir registro ? Funcionó todo el tiempo para mí.

Aquí hay una cita al respecto (de la página del proyecto del módulo):

Hay momentos en Drupal 7 cuando el registro se mancha irremediablemente y necesita reconstruir el registro (una lista de clases PHP y los archivos con los que van). A veces, sin embargo, no puede hacer esta actividad regular de limpieza de caché porque se requiere alguna clase cuando el sistema está intentando arrancar.

Puede usar el módulo de Reconstrucción de registro , que se integra con Drush a través del Drush RRcomando.

Básicamente lo que haces son estos pasos:

1. Mueva sus módulos a otro directorio y
2. Registry Rebuild reconstruirá la tabla del sistema para colocar los módulos en el lugar correcto.

Lo aprendí / descubrí por primera vez a través de DrupalEasy Podcast # 133 , que explica además cómo se puede usar este módulo / drush cmd.

PD: Por supuesto, primero realice una copia de seguridad de su sitio ...

Visite / admin / build / modules reconstruirá las rutas en la tabla del sistema. A veces, drupal ya no puede arrancar, por lo que esta solución no funciona en este caso. Si no funciona, puede usar Drush Rebuild Project Paths como se dijo en una respuesta anterior. Sin embargo, debe agregar el nuevo comando drush antes de romper el bootstrap. Para agregar el nuevo comando, consulte la sección COMANDOS del archivo Léame

Tuve algunos problemas para drush dlno funcionar debido a los problemas del directorio del módulo. En general, me gustan las respuestas de la pila que simplemente puedo pegar para que todo funcione. Aquí encontrará un par de líneas que instalarán Drush Rebuild Registry y lo ejecutarán en su sitio si ya está en el directorio del sitio adecuado.

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

No estoy 100% seguro de una verdadera respuesta de drupal-esk, pero en mi experiencia:

Accidentalmente moví una de mis carpetas de módulos personalizados a otra carpeta de módulos personalizados cuando envié FTP al servidor. Ambos seguían trabajando. Drupal parecía haberlo reconocido como un módulo separado incluso mientras estaba en la carpeta de otro módulo. No tuve que deshabilitar el módulo.

** Este módulo que moví NO tenía un archivo .install, así que no estoy seguro de si eso importa.

Las distribuciones de Drupal no manejan esto bien, por lo que recientemente, después de terminar accidentalmente con una copia de Entity API en sites/all/un sitio de Panopoly, nada de esto funcionó. La reconstrucción del registro, la carga de la página de módulos y todo lo demás causó un error fatal.

Deshabilitar el módulo tampoco es simple si tiene que mover algo como Entity API, que es requerido por toneladas de otros módulos en Panopoly.

Para resolver esto, para Entity API haría algo como esto:

1. Actualice la ruta en la tabla del sistema:

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

2. Luego reconstruya el registro:

   drush rr

Drupal 7

En primer lugar, inténtalo drush rr.

Si no funciona, después de mover los archivos, pruebe los siguientes comandos Drush en su directorio raíz de 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

Si lo anterior no funciona, busque la tabla que todavía tiene la información anterior sobre la ruta:

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

Si no se encuentra ninguno, eso significa que es su caché externa.

Si es así, no olvide reiniciarlos, por ejemplo:

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

Ver más: ¿Qué método se utiliza para borrar cachés en Drupal?

Alternativamente, puede probar las siguientes consultas MySQL después de mover los archivos:

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

Se recomienda mover sus módulos a subcarpetas contrib / dev / patched / custom. Sin embargo, no hay ganancias de rendimiento, esto se hace por razones prácticas y estéticas. Esto facilitará la vida de los futuros desarrolladores.

Puede mover la mayoría de los módulos contrib a subcarpetas sin problemas en un sitio en vivo. Debe limpiar los cachés después. Si no utiliza drush y descubre que ya no puede acceder a la página de limpieza de caché, deberá visitar /update.php o truncar manualmente las tablas de caché. Solo tuve que hacer el último bit al mover el módulo API de la entidad.

Mover módulos principales es técnicamente posible, pero no lo recomendaría ni veo ninguna razón válida para hacerlo.

Actualización: Mover módulos como la API de entidad puede requerir la reconstrucción del registro. Echa un vistazo a la página Registry_rebuild .

Simplemente puede agregar un enlace sym en el directorio de sites / all / modules apuntando a sites / all / contrib. No estoy seguro si resuelve tu problema. También hay otras soluciones, incluido el perfil de instalación o un archivo de creación drush. No sé lo suficiente como para proporcionar detalles sobre ellos, pero al menos es una dirección que puede mirar.