Problemas conocidos al actualizar de Drupal 6 o 7 a Drupal 8

Drupal 6 a 8

Categorías de agregadores

En Drupal 8 ya no existe el concepto de categorías de agregadores, por lo que no se migran a Drupal 8.

Protocolos permitidos

Drupal 8 ahora almacena los protocolos en el parámetro del contenedor «filter_protocols», por lo que si cambió la variable «filter_allowed_protocols», debe incluirla en el archivo services.yml.

Vocabularios permitidos para campo de referencia taxonómica

En Drupal 6, la lista de tipos de contenido aplicables a un vocabulario se define en la configuración del vocabulario. En Drupal 8, los vocabularios permitidos se definen en la configuración del campo de referencia de términos taxonómicos. Este parámetro actualmente no se migra, por lo que permite hacer referencia a todos los vocabularios en Drupal 8. Puede editar manualmente la configuración del campo de referencia de términos taxonómicos en Drupal 8 tras la actualización para seleccionar los vocabularios permitidos.

[Corregido] Formatos de fecha

Solo se migran los formatos predeterminados: corto, medio y largo. Todos los demás formatos predeterminados tienen un formato de respaldo y deben configurarse nuevamente después de la migración.

Campos ausentes en el formulario de edición o página de visualización

Otra cosa que puede causar confusión es cuando ejecuta una migración que parece exitosa pero luego no ve sus campos en el formulario de edición. Visite la página de administración de tipos de contenido y abra la pestaña «Administrar visualización del formulario» para cada tipo de contenido. Los campos agregados por la actualización pueden estar ocultos en el formulario de edición. Si es así, muévalos hacia arriba para que sean visibles. Asimismo, si no aparecen en la vista del nodo, es posible que los campos agregados por Migrate estén ocultos en la pestaña «Administrar visualización» y tenga que hacerlos visibles allí. Para migraciones de campos personalizados, el módulo Migrate Plus puede ser útil.

La página principal carga y el tema no funciona

Durante la migración, a veces la página es blanca y carga solo algunos elementos, parecido a un tema roto. Visitar /user y luego volver a la página principal usualmente resuelve esto.

Interfaz de usuario del menú

Las variables menu_primary_links_source y menu_secondary_links_source no se migran porque no tienen equivalentes en Drupal 8.

Módulos y temas

Antes de iniciar la migración, debe habilitar los nuevos módulos y temas, y configurar el tema administrador (si existe).

Tipos de contenido de nodo

La configuración predeterminada en Drupal 6 incluye los tipos de contenido Story y Page. Los tipos predeterminados en Drupal 8 son Article y Basic Page (que tiene el nombre máquina 'page', como en Drupal 6).

• La migración mapeará el tipo de contenido Drupal 6 Page al tipo Drupal 8 Page, ya que los nombres máquina coinciden.
• La migración creará el tipo de contenido Story para Drupal 8. Probablemente desee eliminar el tipo de contenido Article de Drupal 8 si no lo necesita. Para más detalles, consulte #2236289: Migración de nodos "story" de D6 crea un nuevo tipo de contenido en D8.

Traducciones de nodos

En Drupal 6 y 7 las traducciones de nodos estaban en nodos separados, mientras que en Drupal 8 se combinan con sus nodos originales. El sistema de migración realizará esta combinación, pero algunos enlaces pueden apuntar ahora a nodos que ya no existen. Consulte #2746527: [META] Procesar datos relacionados con traducciones de nodos Drupal 6 y 7 con diferentes IDs.

Tenga en cuenta que las revisiones de nodos traducidos aún no se migran. Consulte #2746541: [backport] Migración de revisiones de D6 y D7 a D8.

Resumen de actualización multilingüe de Drupal 6 a Drupal 8.

Categorías de perfil

Los campos agrupados por el módulo perfil en Drupal 6 no se agrupan en Drupal 8.

Campo de perfil (lista de selección)

La configuración de "valores permitidos" para el campo resultante en Drupal 8 será una combinación de todos los valores personalizados seleccionados y los valores permitidos actuales en Drupal 6, no solo los permitidos en Drupal 6.

Estadísticas

Las configuraciones de registro de acceso y estadísticas no i18n se migran. La consolidación de estadísticas i18n se migró a partir de Drupal 8.5.2. Consulte #2930101: i18n / statistics - contador de nodos no actualizado para traducciones.

Texto / formatos de entrada

Los formatos de filtro no reconocidos por Drupal 8 se migrarán como filter_null, un filtro que simplemente devuelve una cadena vacía. Esto significa que cualquier formato de entrada que use un filtro desconocido no mostrará contenido aunque esté en la base de datos. Esto puede ser confuso. Consulte #2618332: Mejor manejo de reemplazo de filtros faltantes con filter_null y #2630578: Formatos duplicados en actualización D6.

Los formatos de filtro no reconocidos incluyen el infame filtro de código PHP y cualquier filtro provisto por un módulo contrib que no esté habilitado en su instalación Drupal 8.

El filtro PHP no está soportado en el núcleo de Drupal 8 — es muy mala práctica, pero puede usar el módulo PHP si realmente lo necesita.

Para solucionar esto, tiene varias opciones:

• Verifique si los módulos que proveen filtros tienen versión Drupal 8 y habilítelos.
• Edite y guarde los formatos afectados. Esto eliminará la referencia a format_null y el contenido empezará a mostrarse. Tenga en cuenta que, como el filtro original no existe, el contenido no se filtrará y pueden mostrarse tokens sin reemplazo, o incluso el sitio puede estar expuesto a problemas de seguridad.
• Edite el contenido y cambie a otro formato de entrada. Esto traslada los mismos problemas del punto anterior.

Zonas horarias y fechas

Drupal 6 usa desplazamientos horarios para calcular la hora local. Drupal 7 y 8 usan nombres de zonas horarias. Desafortunadamente, la función PHP timezone_name_from_abbr() que convierte desplazamientos en nombres de zonas horarias genera diferentes nombres según si el horario de verano está activado o no en su servidor. Por ejemplo, el desplazamiento 3600 se convierte en Europe/Paris si el horario de verano está desactivado y Europe/London si está activado. La migración ignora el horario de verano. Según la configuración de su servidor, la zona horaria en Drupal 8 puede ser incorrecta después de la migración (#2353679: variable faltante en migración D6->D8: date_default_timezone).

En zonas horarias con horario de verano, Drupal 8 puede interpretar fechas de forma diferente que Drupal 6. Por ejemplo, fechas cerca de la medianoche pueden verse como otro día. Esto causa problemas, especialmente si usa tokens de fecha para construir rutas (por ejemplo, alias URL, rutas de archivos). Dos posibles soluciones están en #2926421: Manejo de discrepancias de fechas entre D6 y D8.

Alias URL

Cuando migra alias URL para un idioma que no está habilitado en el nuevo sitio Drupal 8, ningún alias funcionará hasta que habilite ese idioma en el nuevo sitio Drupal 8.

Views

Views aún no se migran; deberá recrear las vistas manualmente en Drupal 8. Para más información, consulte #2500547: Ruta de actualización para Views de Drupal 6 y 7 y el módulo Views Migration.

Configuración del bloque de actividad de usuario

La configuración de actividad de usuario no se migra. Debe editarla manualmente en la vista correspondiente en filtros / acceso (#2169327: migrar configuración del bloque de actividad de usuario).

Drupal 7 a 8

[Corregido] Vocabularios permitidos para campo de referencia taxonómica

En Drupal 7, el vocabulario permitido para un campo de referencia a término taxonómico se define en la configuración del campo. Este parámetro actualmente no se migra, por lo que permite referencia a todos los vocabularios en Drupal 8. (véase #2763637: Campos de términos taxonómicos D7 no migran con vocabularios permitidos). Puede editar manualmente la configuración del campo de referencia a término taxonómico en Drupal 8 después de actualizar y seleccionar los vocabularios permitidos.

Direcciones IP bloqueadas

La columna id de la tabla ban_ip en Drupal 7 no se migra.

Tipos de comentarios

Drupal 7 permite que los comentarios tengan diferentes campos para distintos tipos de contenido. Usualmente los comentarios tienen campos Autor, Título y Comentario. Como distintos comentarios D7 pueden tener diferentes campos, la migración creará tipos de comentarios D8 separados para cada tipo de contenido:

• El tipo de contenido Foo tendrá un tipo de comentario comment_node_foo.
• El tipo de contenido Bar tendrá un tipo de comentario comment_node_bar.

La única excepción es para los comentarios en foros. Cuando el módulo Forum D8 está habilitado, se crea automáticamente un tipo de comentario comment_forum. Los comentarios del foro D7 se migran a este tipo.

Nota importante: perfil de instalación estándar de Drupal 8 y tipo de contenido Article
Si su sitio Drupal 8 fue instalado usando el perfil estándar, tendrá un tipo de contenido llamado Article.

• Este tipo de contenido incluirá un campo de comentarios llamado comment.
• El sistema de migración no puede asumir que el sitio D8 fue instalado con el perfil estándar, por lo que creará un tipo de comentario comment_node_article, y los comentarios de tipo Article D7 se migrarán a este tipo.

Como resultado, su tipo de contenido Article tendrá dos campos de comentarios:

• comment, proveniente del perfil estándar D8 y sin uso
• comment_node_article, creado por el sistema de migración

Probablemente no desee tener dos campos de comentarios para el tipo Article, por lo que deberá eliminar manualmente el campo comment del tipo Article (admin/structure/types/manage/article/fields). Luego podrá eliminar el tipo de comentario comment si no lo utiliza en ningún lugar (admin/structure/comment).

Se recomienda eliminar el campo de comentario no deseado del tipo de contenido Article antes de ejecutar migraciones, ya que actualmente Drupal 8 core tiene un error relacionado con la eliminación del campo de comentario, vea #2906470: Comentarios y entradas en comment_entity_statistics perdidos tras eliminar instancia del campo comentario.

Código PHP

Los formatos de filtro no reconocidos por Drupal 8 se migrarán como filter_null, un filtro que simplemente devuelve cadena vacía. Esto significa que cualquier formato de entrada que use un filtro desconocido no mostrará contenido, aunque el contenido esté en la base de datos.

Los formatos no reconocidos incluyen el infame filtro de código PHP y cualquier filtro proporcionado por un módulo contrib que no esté habilitado en su instalación Drupal 8.

El filtro PHP no está soportado en el núcleo Drupal 8 — es mala práctica, pero puede usar el módulo PHP si realmente lo necesita.

Para resolver esta situación, tiene varias alternativas:

• Verifique si los módulos que proveen filtros tienen versión para Drupal 8 e instálelos.
• Edite y guarde los formatos de entrada afectados. Esto eliminará la referencia a format_null y el contenido empezará a mostrarse. Tenga en cuenta que, como el filtro original no existe, el contenido no será filtrado y pueden mostrarse tokens sin reemplazo, o incluso el sitio puede estar expuesto a vulnerabilidades de seguridad.
• Edite el contenido y cambie a otro formato de entrada. Esto traslada los mismos problemas mencionados anteriormente.

Campos de texto simple

Configuraciones contradictorias de procesamiento de texto en Drupal 7
En Drupal 7, los parámetros de procesamiento de texto se definen en la configuración de la instancia del campo. En otras palabras, un mismo campo puede usarse en dos (o más) tipos de contenido, y el procesamiento de texto puede ser “Texto plano” para uno y “Texto filtrado” para otro.

Drupal 8 tiene tipos separados para almacenamiento de campo Text (plain) y Text (formatted). También hay Text (plain, long) y Text (formatted, long). Lo importante es que esta elección se hace a nivel de almacenamiento del campo. En otras palabras, la opción plain/formatted no puede variar por tipo de contenido.

El sistema de migración no asume nada. Si detecta configuraciones conflictivas de procesamiento de texto, estos campos se omiten con un mensaje en el registro. El creador del sitio tiene dos opciones:

1. Cambiar la configuración de procesamiento de texto en Drupal 7 para que todos los tipos de contenido que usan el campo de texto tengan la misma configuración.

• Tenga cuidado con esta unificación para evitar posibles problemas de seguridad XSS.
• Si en Drupal 7 su campo estaba configurado como “Texto plano” y usuarios no confiables podían publicar contenido en ese campo, puede que haya contenido malicioso que no provocó XSS porque estaba configurado como Texto plano. Si ahora cambia a Texto filtrado, asegúrese de que el formato no permita HTML completo o contenido malicioso.

2. Si necesita tener dos configuraciones de formato distintas en Drupal 8, debe crear su propia migración que separe el campo Drupal 7 en dos campos Drupal 8. Más información en Configurar migraciones al actualizar a Drupal 8.

Texto con resumen + configuración de formato de texto plano en Drupal 7
Drupal 7 tiene un tipo de campo Long text y resumen. El tipo correspondiente en Drupal 8 es Text (formatted, long, with summary). En Drupal 7 se puede configurar en la instancia del campo que el procesamiento sea texto plano. Los campos Text (formatted, long, with summary) en Drupal 8 siempre son texto filtrado.

El sistema de migración no asume nada. Si detecta un campo “Long text” con resumen con configuración de texto plano, el campo se omite con un mensaje en el registro. El creador del sitio tiene las mismas dos opciones que arriba:

1. Cambiar la configuración del formato de campo de Texto plano a Texto filtrado en Drupal 7.

• La advertencia sobre XSS antes mencionada también aplica aquí.

2. Crear su propio camino de migración y lógica para cómo quiere migrar estos campos a Drupal 8. Más información en Configurar migraciones al actualizar a Drupal 8.

Estadísticas

Las configuraciones de registro de acceso y estadísticas no i18n se migran. La consolidación de estadísticas i18n se migró desde Drupal 8.5.2. Consulte #2930101: i18n / statistics - contador de nodos no actualizado para traducciones.

Views

Views aún no se migran; deberá recrear las vistas manualmente en Drupal 8. Para más información, consulte #2500547: Ruta de actualización para Views de Drupal 6 y 7 y el módulo Views Migration.

Conflictos potenciales de ID (de D6 o D7 a Drupal 8)

Problema

Como se describe en la página de preparación para la actualización, el sitio Drupal 8 debe estar completamente vacío al ejecutar el proceso de actualización. El proceso de migración conserva los identificadores del sitio original al importarlos al sitio Drupal 8. Si se creó contenido en el sitio Drupal 8 antes de la actualización (por ejemplo, un nodo con nid 1), es probable que haya conflictos de identificadores.

Actualmente se trabaja en detectar automáticamente posibles conflictos de identificadores y advertir al usuario, vea #2876085: Verificar posibles conflictos de ID antes de la actualización. Por ahora, los administradores deben considerar cuidadosamente posibles conflictos. Si no se manejan con cuidado, el contenido u otros elementos de entidad, como términos y archivos de taxonomía, podrían sobrescribirse y causar pérdida de datos. También puede que los objetos referenciados queden corruptos, por ejemplo, contenido vinculado al término taxonómico incorrecto.

Escenarios que pueden causar conflictos de ID

• El sitio Drupal 8 destino ya fue usado antes de la actualización y ya contiene contenido.
• La migración inicial se completó. Tras la migración inicial, contenido u otros objetos fueron creados tanto en el sitio origen como en el destino. Cuando se migra contenido actualizado/nuevo, los identificadores pueden entrar en conflicto con el contenido creado en Drupal 8.
• El sitio destino Drupal 8 estaba limpio, pero los módulos añadidos o personalizados añadieron datos propios al habilitarse en Drupal 8. Por ejemplo, el módulo principal de foros de Drupal 8 crea un término de taxonomía para su categoría de discusión general, que usualmente recibe el ID #1 en una instalación nueva. Si los datos origen contienen un término con ID 1, sobrescribirá el nombre de la categoría del foro.
• El origen puede tener datos sin identificador, pero el destino requiere uno. Por ejemplo, Drupal 6 trata imágenes personalizadas como archivos no gestionados sin ID, pero Drupal 8 requiere IDs para archivos gestionados. Durante la migración se crean campos de archivos gestionados con IDs que pueden entrar en conflicto con archivos aún por migrar.
• Los posibles conflictos de ID con traducciones no se detectan automáticamente.

                            - Si realiza una actualización completa directamente a un sitio Drupal 8 vacío, todo debería estar bien.
                            - Si realiza una migración parcial tras la actualización inicial y ha añadido traducciones al sitio Drupal 8 antes de migrar contenido actualizado/nuevo, la segunda migración puede sobrescribir traducciones hechas en Drupal 8.

Soluciones

Migración personalizada para elementos en conflicto
Puede personalizar la migración para el contenido problemático para que se creen nuevos identificadores para esos elementos. Esto afectará su ruta interna y posiblemente sus URLs públicas. Hay que prestar especial atención para corregir cualquier referencia a los objetos modificados.

Manipular valores AUTO_INCREMENT
Cuando el sitio destino Drupal 8 no tiene datos en conflicto pero el proceso de migración puede generarlos, puede manipular los valores AUTO_INCREMENT en las tablas de la base de datos Drupal 8 para que los IDs de entidades creadas no se solapen con los migrados. La migración de imágenes personalizadas mencionada es un ejemplo de esto.

Aceptar que los datos puedan ser sobrescritos
Siempre puede continuar la migración. Esto probablemente no es deseable en muchos casos porque puede provocar pérdida de datos.

Actualizar sitios multilingües (de D6 o D7 a Drupal 8)

Para todas las migraciones multilingües desde los módulos de internacionalización Drupal 6 y 7 (i18n) y el módulo Entity Translation de Drupal 7, se requiere que en el sitio Drupal 8 esté habilitado el módulo principal Drupal 8 Migrate Drupal Multilingual (migrate_drupal_multilingual).

Resumen de actualización multilingüe de Drupal 6 a Drupal 8.