autotitle - drupal 7 module token

Actualización de Drupal 6 a Drupal 7: ¿las mejores prácticas para programadores? (1)

Buenas preguntas, así que veamos:

(cuando empezar a portar)
Esto ciertamente depende de la complejidad de los módulos a puerto. Si hay realmente complejos / grandes, puede ser útil comenzar temprano para encontrar puntos difíciles sin estar bajo presión. Para los más pequeños / estándar, trataría de encontrar un espacio de tiempo mayor más adelante en el que pueda portar muchos de ellos en una fila para poder memorizar rápidamente las cosas de la rutina (y beneficiarme de la documentación probablemente mejorada).
(cobertura de prueba)
Normalmente diría que sería recomendable tener una buena cobertura de prueba antes de comenzar la refactorización / transferencia. Pero dado que Drupal-7 introduce un cambio importante con respecto al marco de pruebas al moverlo al núcleo, esperaría la necesidad de volver a escribir una cantidad significativa de pruebas de todos modos. Entonces, si no hay necesidad de mantener las versiones de Drupal-6 después de la migración, ahorraría tiempo / problemas y buscaría una mayor cobertura después de la migración.
(adoptador temprano vs. esperar y ver)
Usando Drupal desde la versión 4.7, siempre hemos esperado al menos el primer lanzamiento oficial de una nueva versión principal antes de siquiera pensar en portar. Con Drupal 6, esperamos el módulo de vistas antes de portar nuestro primer sitio, y todavía tenemos algunos proyectos más pequeños en Drupal-5, ya que están funcionando bien y sería difícil justificar la factura adicional para nuestros clientes siempre y cuando Todavía hay reparaciones de mantenimiento / seguridad para ello. Solo hay tanto tiempo en un día y siempre hay una acumulación de errores para corregir, características para agregar, etc., por lo que no sirve de nada jugar con tecnología inacabada, mientras que hay cosas más inminentes que hacer que beneficiarán de inmediato a nuestros clientes. Ahora, esto ciertamente sería diferente si tuviéramos que mantener uno o más módulos contribuidos "oficiales", ya que ofrecer un puerto temprano sería bueno.
Estoy un poco atado aquí: ser uno de los primeros en adoptar sin duda beneficia a la comunidad, ya que alguien tiene que encontrar esos errores antes de que puedan solucionarse, pero por otro lado, tiene poco sentido comercial luchar hora tras hora con los errores. otros podrían haber encontrado / arreglado si hubieras esperado un poco más. Mientras tenga que hacer esto para ganarme la vida, debo cuidar mis recursos, tratando de encontrar un equilibrio aceptable entre servir a la comunidad y beneficiarme de ella: - /
(normas de calidad)
"Si funciona, estoy feliz" simplemente no lo corta, ya que no quiero ser feliz solo un momento, sino también mañana. Así que uno de mis estándares de calidad es que necesito estar (algo) seguro de que "asimilé" los nuevos conceptos lo suficientemente bien como para no solo hacer que las cosas funcionen, sino también para que funcionen como deberían. Ahora, esto es difícil de definir con mayor precisión, ya que obviamente es imposible saber si uno lo ''entendió'' antes de ''hacerlo'', por lo que se reduce a una sensación / distinción viscerales de ''sí, algo funciona'' vs. ''sí , se ve bien '', y uno tiene que aceptar que con bastante frecuencia se equivocará al respecto.
Dicho esto, un punto en particular que estoy buscando es "intervenir lo antes posible". Como principiante, a menudo modifiqué las cosas "después del hecho" durante la etapa de creación de temas, mientras que hubiera sido mucho más fácil aplicar el "arreglo" anteriormente en la cadena de procesamiento por medio de un gancho u otro. Así que ahora, cuando estoy a punto de "ajustar" algo en la capa de tema, deliberadamente tomo un pequeño tiempo de espera para comprobar si esto no se puede hacer de forma más limpia / compatible dentro de un gancho anteriormente. Como espero que Drupal-7 agregue aún más opciones de enganche, esto es algo a lo que le prestaré más atención, ya que generalmente reduce los conflictos y las "interrupciones repentinas" al agregar nuevos módulos.
(errores comunes)
Bueno, principalmente a la hora de comenzar, descubrir después / entre uno o más módulos necesarios no estaban disponibles para la nueva versión, o solo en el estado dev / alpha / beta inicial. Así que me aseguro de compilar una lista completa de módulos usados / necesarios primero, enumerando su estado de transferencia, junto con una rápida inspección de las colas de problemas.
Además de eso, hasta ahora siempre he estado muy satisfecho con las nuevas versiones y sus mejoras, y estoy esperando a Drupal-7 de nuevo.
(refactorizando mientras portando)
Se podría decir que portar es una refactorización bastante grande en sí misma, por lo que no es necesario aumentar la complejidad mediante la reestructuración de cosas no relacionadas con la portabilidad. Por otro lado, si ya tiene que destruir sus módulos de todos modos, ¿por qué no aprovechar la oportunidad para hacer una revisión importante? Intentaría dibujar una línea basada en la complejidad: para los módulos grandes / complejos, haría el puerto lo más recto posible, y refactorizaría más adelante, si es necesario. Para módulos más pequeños, no debería importar, ya que la probabilidad de introducir errores sutiles debería ser bastante pequeña.
(otras cosas)
... necesito pensarlo ...

Ok, otras cosas

Necesidades de recursos: dados algunos de los subprocesos de Drupal-7, parece que es probable que aumenten, por lo que esto debe evaluarse antes de portar sitios más pequeños que se encuentran en una cuenta de alojamiento compartida / restringida.
Las últimas versiones primero: esta es bastante obvia y siempre se destaca en las guías de actualización, pero, sin embargo, vale la pena mencionar: Actualice el núcleo y todos los módulos a su última versión actual antes de realizar una actualización importante, ya que es muy probable que el código de actualización dependa de la Últimas tablas / estructuras de datos para trabajar correctamente. Dado que Drupals fue ''poco a poco'', una estrategia de actualización paso a paso, sería muy difícil implementar un código de actualización que detectara diferentes estados previos a la actualización y actuara en consecuencia.

Aunque estoy usando Drupal desde la serie D4, solo comencé a desarrollarlo profesionalmente con D6, así que, a pesar de que realicé varias actualizaciones del sitio, nunca tuve la tarea de tener que portar mi propio código a una nueva versión.

Sé que la comunidad de Drupal proporcionará gran cantidad de soporte técnico sobre cambios de API y arquitectura (consulte el módulo de deadwood para D5-D6 o incluso estos talones de D6-D7 para módulos y temas ).

Sin embargo, lo que busco con mi pregunta es más en la línea de pensamiento estratégico , o en otras palabras, estoy buscando aportes y consejos sobre cómo planificar / implementar / revisar el proceso de portar mi propio código , a la luz de Lo que los desarrolladores colega aprendieron por experiencia previa. Algunos ejemplos:

¿Le aconsejaría comenzar a migrar mis módulos tan pronto como tenga tiempo para hacerlo y mantener un D7 concurrente durante un tiempo (de modo que esté "preparado" para el día D) o le aconsejaría que esperara el ¿Día en el que el puerto será realmente inminente y luego actualizar los módulos a D7 y soltar la versión D6?
Solo algunos de mis módulos tienen cobertura de prueba completa. ¿Recomendaría completar la cobertura de prueba para la versión D6 para que todas las pruebas funcionen para verificar el puerto D7, o recomendaría escribir mi dirección de prueba en el momento de transferencia para probar la versión D7?
¿Encontró que ser un adoptador temprano le da una ventaja en términos de nuevas características y mejores API o prefirió demorar la conversión para aprovechar la mayor cantidad de módulos de contribución disponibles?
¿Estableciste para ti mismo estándares de calidad / criterios de evaluación o simplemente estableciste la barra a "si funciona, estoy feliz"? ¿Por qué? Si establece ciertos estándares u objetivos, ¿cuáles fueron dónde / cuáles serán? ¿Cómo te ayudaron?
¿Hay dificultades comunes que experimentó en el pasado y que cree que son aplicables al proceso de adaptación D6-D7?
¿Es un buen momento para hacer un poco de refactorización o simplemente va a hacer que todo sea más complejo para volver a armarse?
...

Estas preguntas no son una lista exhaustiva, pero espero que den una idea del tipo de información que estoy buscando. Preferiría decir: cualquier cosa que creas que sea relevante y no mencioné arriba, ¡obtendré un "plus"! :)

Si no pude expresarme con la suficiente claridad, publique un comentario con la información que cree que debería agregar en la pregunta. ¡Gracias de antemano por su tiempo!

PD: Sí, lo sé ... D7 aún no está disponible y pasarán meses antes de que se actualicen los módulos de contribución importantes ... ¡pero nunca es demasiado pronto para empezar a pensar! :)