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

drupal.stackexchange https://drupal.stackexchange.com/questions/17657

  •  22-10-2019
  •  | 
  •  

Pregunta

He estado buscando las respuestas a esta pregunta sin suerte. De 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?

¿Fue útil?

Solución

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

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

Aunque, le recomendaría que respalde su base de datos antes de probar esto.

Si está utilizando Drush, también puede reconstruir el registro utilizando el siguiente comando:

drush cc registry

También puede instalar el registry_rebuild Comando para Drush:

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

Otros consejos

Restauré una copia de seguridad de la producción localmente e intenté simplemente mover cosas y presionar administrador/módulos o ejecutar Registry_Rebuild () pero no impidió que se arrojaran errores fatales. Esto tiene sentido para mí, ya que algunos módulos pueden usar incluyen o lo que sea en su Hook_init (), o puede tener un conjunto de ruta de enrutador de menú que depende de un módulo o incluya que Drupal no pueda encontrar en Bootstrap. En última instancia, esto es lo que hice (tus caminos pueden ser diferentes):

Paso 1: Reemplace los sitios/todos/módulos con sitios/todos/módulos/contribución

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 los sitios/All/Modules/Contrib con Sitios/All/Módulos/Personalizado para módulos personalizados de nombres

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: Clear cachés para que las cosas se arrancen 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 un contribuy como logInToboggan para manejar 403 (acceso denegado) y se ha registrado durante este proceso, es posible que deba actualizar el include_file columna en el menu_roter Tabla para usar la nueva ruta para el archivo incluir. Esto es probablemente un hecho raro.

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

Una vez que estas consultas se hayan ejecutado, que solo tomará una fracción de segundo, presione Admin/Config/Development/Performance y borre el caché para que las rutas de menú reconstruyan.

Pruebe la herramienta genial de Mark Sonnabaum: Rutas de proyecto de reconstrucción de Drush. Automatiza el proceso; funcionó muy bien para mí. Usos Cenador, por supuesto.

Sin embargo, detendré la sugerencia de que pruebe esto en una copia de la base de datos de su sitio.

Para el registro, hay un gran comando desactivado 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, tan fácil de hacer, se pateará si algo sale mal y no realizó una copia de seguridad.

No estoy seguro de si importa si deshabilitas 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 (Sitename)/Admin/config/desarrollo/mantenimiento
  2. Mueva físicamente sus módulos en el sistema de archivos.
  3. Borre sus cachés en (Sitename)/admin/config/desarrollo/rendimiento, o simplemente vuelva a ahorrar su página de módulos.

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

¿Por qué no intentas el Registro reconstruir módulo. Funcionó cada vez para mí.

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

Hay momentos en Drupal 7 en que el registro tiene una manguera irremediablemente y debe reconstruir el registro (una lista de clases de PHP y los archivos con los que van). A veces, sin embargo, no puede hacer esta actividad regular clara de caché porque se requiere alguna clase cuando el sistema intenta arranque.

Puedes usar el Registro reconstruir módulo, que se integra con Drush a través del Drush RR dominio.

Básicamente, lo que haces son estos pasos:

  1. Mueva sus módulos a otro directorio y
  2. La reconstrucción del registro reconstruirá la tabla del sistema para obtener los módulos en el lugar correcto.

Primero lo aprendí/lo descubrí a través de Drupaleasy Podcast #133, que explica además cómo se puede usar este módulo / cMD de desgarro.

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

Visitar/Admin/Build/Módulos Redilizará las rutas en la tabla del sistema. A veces, Drupal ya no puede arranque, por lo que esta solución no funciona en este caso. Si no funciona, puede usar Rutas de proyecto de reconstrucción de Drush 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 el readmeSección de comandos

Tuve algunos problemas con drush dl No funciona debido a los problemas del directorio del módulo. En general, me gustan las respuestas de pila que simplemente puedo pegar para que las cosas funcionen. Aquí encuentra un par de líneas que instalarán Registro de reconstrucción de Drush y lo ejecutarán en su sitio si ya está en el directorio de 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 Drupal-esk, pero en mi experiencia:

Accidentalmente moví una de mis carpetas de módulos personalizados a otra carpeta de módulos personalizados al pasar al servidor. Ambos todavía trabajaban. 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, así que recientemente después de terminar accidentalmente con una copia de API de entidad en sites/all/ En un sitio de Panopoly, nada de esto funcionó. Registro reconstruir, cargar la página de módulos y todo lo demás causó un error fatal.

Deshabilitar el módulo no es simple si tiene que mover algo como la API de entidad que requiere toneladas de otros módulos en el panopolio.

Para resolver esto, para la API de la entidad harías 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, intente drush rr.

Si no funciona, después de mover los archivos, intente los siguientes comandos de drush en su Dir Root 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 arriba no funciona, busque la tabla que todavía tenga la información anterior sobre la ruta por:

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é externo.

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 usa para borrar los cachés en el 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/personalizadas. No hay ganancias de rendimiento, sin embargo, 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 ningún problema en un sitio en vivo. Debes despejar los cachés después. Si no usa Drush y encuentra que ya no puede acceder a la página de compensación 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 básicos es técnicamente posible, pero no lo recomendaría ni veo ninguna razón válida para hacerlo.

ACTUALIZACIÓN: Los módulos de mudanza como la API de la entidad pueden requerir la reconstrucción del registro. Revisar la registro_rebuild página.

Simplemente puede agregar un enlace SYM en el director de Sitios/All/Módulos que apunta a Sitios/ALL/Contrib. No estoy seguro de si resuelve tu problema. También hay otras soluciones, incluido el perfil de instalación o un archivo de fabricación de desgarro. No sé lo suficiente como para proporcionarles detalles, pero al menos es una dirección que puedes ver.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a drupal.stackexchange
scroll top