Herramientas y consejos para cambiar CMS

Question

Trabajo para una universidad, y el año pasado finalmente nos separamos de nuestro sitio HTML estático de varios miles de páginas y nos mudamos a un sitio de Drupal. Esto obviamente implica cantidades masivas de entrada de datos.

¿Qué sucede si ya está utilizando un CMS y está cambiando a otro que mejor se adapte a sus necesidades? ¿Cómo se minimiza la montaña de entrada de datos durante un cambio tan grande? ¿Hay herramientas creadas para esto o algunas mejores prácticas que uno debería seguir?

Answer 1

• Esperar a tener tanto pre-proceso y post-proceso de los datos manualmente, pase lo que pase. Acepte desde el principio que es probable que sus datos estén peor de lo que cree: los campos serán mal utilizados; las referencias de registro a registro (claves externas) pueden no implementarse correctamente, o no implementarse; Es probable que el contenido necesite desherbar y ocasionalmente sea malo o incorrecto.

• Compruebe la codificación de su base de datos. Las bases de datos antiguas no estarán codificadas en Unicode, y se pondrán de mal humor si tiene que exportar volcados de datos e importarlos en otro lugar. Incluso entonces, suponga que habrá algunos extraños caracteres no imprimibles en sus datos: los programas como Word parecen inyectarlos de alguna manera en todas partes, y he visto ... puntos de código ... que la gente no creería. Considere barrer sus datos incluso antes de comenzar (o incluso barrer un volcado de base de datos) para estos caracteres. Decida si desea o no juntarlos o intentar convertirlos en el caso de, p. Palabra "inteligente" caracteres de puntuación.

• Es muy difícil crear estructuras de datos explícitas a partir del implícito.Si sus datos entrantes tienen un campo de fecha separado, puede asignarlos a un campo de fecha; si tiene una fecha como parte de un gran bloque de HTML, incluso si esa fecha está en una etiqueta con un atributo de id, las secuencias de comandos simples no funcionarán. Podría usar secuencias de comandos sin conexión con BeautifulSoup o (si su HTML es un poco mejor) el lxml más rápido para preprocesar su conjunto de datos, extraer esos campos implícitos y guardarlos en un formato implícito. Considere crear una base de datos intermedia donde irán estas revisiones.

• El módulo Migrate es excelente, pero para obtener una fidelidad de datos realmente buena y jugar trucos más inteligentes es posible que necesite aprender sobre su sistema de enlace (terminología de Drupal para funciones siguiendo un esquema de nombres particular) y los principios básicos de escribir un módulo para poner estos ganchos (un módulo es simplemente un archivo PHP donde todas las funciones comienzan con el mismo texto, el nombre del archivo del módulo.)

• Todo el contenido importado debe marcarse para al menos una verificación superficial. Puede hacerlo importándolo con el estado = 0, es decir, sin publicar, y luego crear una vista con el módulo Vistas para revisar el contenido y abrirlo en otras pestañas para verificar. Las operaciones a granel de Views le permiten tener un conjunto de casillas junto con sus elementos de vista, por lo que podría aprobar muchos nodos a la vez.

• Espere ejecutar, volver a ejecutar y volver a ejecutar la importación, arreglando cosas nuevas todo el tiempo. Verifique diez o veinte artículos lo antes posible. Si hay algún problema, verifique diez o veinte más. Arregle y repita la importación.

• Calcule cuánto tiempo tardará una única ejecución de importación. Sea pesimista: tuvimos una importación que esperábamos que llevara diez horas enfrentar una ralentización exponencial cuando presentamos el conjunto completo de datos; hasta que finalmente arreglemos algunas consultas lentas, se proyectó que tomaría dos semanas.

• En caso de duda, o si cree que los aspectos técnicos de lo anterior solo tomarán más tiempo que el trabajo en sí, entonces simplemente contrate temporeros para hacer los datos. Pero aún necesita controles de calidad decentes, tan pronto como sea posible durante su trabajo. Los desarrolladores de Drupal también se pueden contratar: pruebe el canal IRC relevante de su país o publique una nota en un grupo relevante de groups.drupal.org. ¡Son más caros que las temporadas pero usualmente escriben mejor PHP ...! Considere también contratar una agencia: es un complemento descarado, ya que trabajo para uno, pero a veces lo mejor es conseguir expertos para estos trabajos específicos.

• Las importaciones realmente buenas siempre son difíciles, más difíciles de lo que esperaba. No dejes que te deprima!

Answer 2

El módulo Migrate para Drupal proporcionaría una gran ayuda. El Economist.com data migration to Drupal le dará una visión general del proceso.

La video de la presentación Migration: not just for the birds en Drupalcon DC 2009 es probablemente algo desactualizada, pero también da una buena introducción.

Answer 3

Migrate + asistente de tabla (y esquema + vistas) es el camino a seguir. Con el asistente de tablas puede exponer cualquier tabla a Drupal y asignar los campos en consecuencia utilizando migrar.

Mire aquí para una walktrough detallada: http://www.lullabot.com/articles/drupal-data-imports-migrate-and-table-wizard

Answer 4

1. usted querrá tener un acceso a los datos existentes de Django. Esto me ayuda mucho con la migración: http://docs.djangoproject.com/en/1.2/howto/legacy-databases/. Con las definiciones correctas de modelos, tendrá plena potencia django, incluido el administrador. De hecho, estoy usando django como back-end de administración para varios proyectos heredados de php: el administrador de django puede fácilmente obtener una gran cantidad de scripts de administración personalizados escritos a mano.

2. La autorización debe seguir siendo la misma. Los usuarios deben poder iniciar sesión con sus credenciales, pero es difícil escribir un script de migración para datos de autenticación porque los esquemas de hash de contraseña pueden ser diferentes y no hay forma de convertirlos sin conocer las contraseñas simples. Django proporciona una forma de admitir diferentes fuentes de autenticación para que pueda escribir el backend de autenticación de Drupal: http://docs.djangoproject.com/en/1.2/topics/auth/#writing-an-authentication-backend

3. No es necesario realizar la reescritura completa. Si algunas partes funcionan bien, todavía pueden ser alimentadas por Drupal. El nuevo código se puede escribir usando Django con la misma interfaz de usuario. El enrutamiento entre partes antiguas y nuevas se puede realizar mediante la reescritura de la URL del servidor web. Ambas partes django y drupal pueden ser alimentadas por el mismo DB.