Antecedentes

Dentro de un año, mis clientes van a portar un servicio de portal de intranet relativamente complejo (programación, seguimiento e informes reales, y más) a Drupal porque la oficina central lo dice. Se ha hecho muy poco esfuerzo para determinar si esta es la opción técnica correcta y si está fuera del control de mis clientes o incluso de sus jefes.

El portal actual es una abominación que está en proceso de refactorización y creo que el plan más rentable será incorporar una capa de modelo de dominio a través de Doctrine 2 y poner el 99.9% de toda la lógica de validación de entrada y negocio en los modelos , destripando la abominación hasta que sea una vista esquelética y una capa lógica de autenticación.

Pregunta

Para cualquier especialista de Drupal, ¿esto parece un enfoque viable? ¿Podría Doctrine2 jugar bien con Drupal o la lógica de nivel superior de Drupal necesita una integración mucho más estricta con los datos?

Hemos realizado algunos sitios en los que hemos conectado sistemas externos a Drupal donde los datos debían mantenerse en el sistema externo. Esto es con lo que paso la mayor parte del tiempo trabajando.

Cuando hacemos esto, generalmente creamos un tipo de contenido para "eliminar" el contenido en el otro sistema. El tipo de contenido solo contiene el título del nodo y un campo CCK para el identificador único en el otro sistema. Junto con esto hay muchas funciones hook_nodeapi . Por ejemplo, el loadenlace llamará al sistema remoto y agregará los datos al nodo. También debe idear un método para obtener los datos externos en los resultados de búsqueda. Hay algunos métodos para esto, pero son demasiado largos para entrar aquí.

Si bien hay algunos inconvenientes, encontramos que esto funciona bien y permite cosas normales de Drupal como comentarios, etiquetas, etc.

La única cosa sensata para hacer, dada la línea de tiempo, es construir esto en Drupal 7. Una de las características más destacadas de Drupal 7, son las entidades, DBNTG y los campos.

Un resumen rápido

• Las entidades son una forma de definir una estructura de datos. Ejemplos de entidades integradas con Drupal son, nodos (contenido principal), usuarios, términos de taxonomía.
• Los campos son algo que se puede adjuntar a una entidad, que también contiene datos. El uso de campos tiene la ventaja de tener solo un lugar para manejar los datos y pueden extenderse de varias maneras. Un ejemplo de un campo podría ser un archivo adjunto o una referencia a otra entidad.
• DBTNG (Base de datos de la próxima generación) es lo que la comunidad de Drupal había denominado en código la nueva capa de abstracción de la base de datos. Antes de esto, solíamos hacer consultas con marcadores de posición (que todavía es compatible), pero ahora la mayoría de las consultas se crean con clase. Una razón para esto también es que los campos obtienen su (s) tabla (s) de base de datos creadas en función de la configuración. Esto ayuda a crear código que funcionará, incluso si los campos se crean con diferentes configuraciones.

Estas son solo algunas de las características, pero esto significa que, a menos que desee crear una abominación de Drupal, debe comenzar a pensar en cómo funciona Drupal y usarlo en lugar de intentar que Drupal funcione de una manera para la que no fue diseñado.

Dado que Drupal es PHP, puede crear módulos personalizados y usar Doctrine2 para hacer lo que quiera. Pero supongo que terminarás con un sitio que tiene muy poco en común con la mayoría de los sitios de Drupal.

Esta es una pregunta bastante amplia, por lo que le daré una respuesta de alto nivel. Si tiene preguntas más específicas, hágalas como preguntas separadas.

Te sugiero que traces la mayor cantidad posible de la estructura del sitio actual. Qué tipo de cosas hace, qué flujos de trabajo hay. ¿Cuál es el contenido? ¿Cuáles son los usuarios?

Los tipos de contenido son una forma práctica de dividir el contenido. Incluso la abominación habría tenido tipos que creo (esperaba) que se correlacionan con URL.

Una vez que haya determinado los tipos de contenido, puede ver cómo migrar el contenido a su nuevo sitio. Luego puede ver cosas como flujos de trabajo, horarios, usuarios, etc.

Yo preferiría mudarse al por mayor. Tener contenido administrado por más de un sistema es un gran dolor de cabeza técnico. Y duplica su esfuerzo de mantenimiento.

Una cosa que diría es que puede valer la pena contratar a alguien para que lo haga. Ha habido algunas migraciones de Drupal muy exitosas con grandes conjuntos de datos. Pero si no tiene experiencia en Drupal, puede hacer varios pasos en falso y costarle mucho tiempo. (Puedo recomendar personalmente a Cyrve , no tengo afiliación actual con ellos)