Por fin se ha presentado la nueva y esperada versión de Drupal, la 6.0, que tantas novedades aporta y reduce en gran medida la curva de aprendizaje del potente y versátil CMS.
Antes de crear mi weblog estuve dudando entre Wordpress y Drupal, escogí wordpress pero dentro de poco me pasaré a Drupal para probarlo y luego decidiré entre los dos
#6 Bueno, yo tengo unos 9 módulos funcionando con la rama desarrollo (-dev) sin problemas. A lo sumo he tenido que parchear algún modulo o hacer alguna modificación a mi gusto en alguno.
No veo el modulo Acidfree como critico. De todos modos tienes una rama -dev que debería funcionar sin problemas y con la que podrías migrar (evidentemente siempre realizando una batería de pruebas en local). Y su desarrollo no está parado ni muchísimo menos, la última versión es de ayer!!!!! Vamos, que este tipo de cosas son de esperar en un proyecto de este tipo... y a veces puede que no quede más remedio que remangarse y ponerse manos a la obra... de todos modos, lo que hay que hacer es tener siempre una versión en local e ir mirando la evolución de los desarrollos, a veces parece que un proyecto está parado y ni muchísimo menos... hay que echarle también un ojo los repositorios CVS...
Está clarisimo que cuando uno se mete a un CMS debe de ser consciente de donde se está metiendo. Es lógico que con módulos de terceros te arriesgues a que se pare su desarrollo, sobre todo sin son módulos poco populares. Por eso hay que elegir con cuidado los módulos que realmente necesitamos, conociendo el compromiso entre beneficio para el proyecto y riesgo de que se frene su desarrollo. Al igual que cualquier personalización que hagamos a medida lleva consigo el consiguiente mantenimiento y adaptación a cada nueva versión. Si por ejemplo desarrollamos un tema a medida, debemos ser conscientes de que puede que tengamos que rehacerlo casi por completo para la nueva versión. Lo mismo si modificamos el código de el core o algún modulo básico o tenemos módulos propios. Cuanto más nos alejemos del CMS out-of-the-box, más complejo y más tedioso será el mantenimiento. Pero esto es inherente a cualquier proyecto web y en general a cualquier proyecto software. Crees que existe algún CMS en el que esto no ocurra? pues déjame decirte que si es así, te equivocas... he trasteado con unos cuantos, y créeme que a pesar de los inconvenientes para migrar los desarrollos a las nuevas versiones en Drupal, es quizás uno de lo CMS que más cuida que los datos se migren sin problemas y de la forma más transparente entre versiones. Las migraciones, con todos los módulos actualizados, son de lo más sencillas y menos problemáticas que he visto... no puedo decir lo mismo de otros CMS que me ha tocado SUFRIR...
Yo no creo que se deba frenar el desarrollo de la API... seria perjudicial... muy perjudicial... de todos modos, aún no he tenido ningún problema para migrar versiones... y ayer mismo probé una migración en local a la nueva versión, y salvando el escollo de que no todos los módulos han sido portados a la nueva rama, todo fue sin problemas... me toca migrar algunas personalizaciones y rehacer el theme, completar la traducción al español y esperar a que todos los módulos esten portados...pero es algo que ya me esperaba... que no queda más remedio y que incluso... me divierte!!!
#8 Por supuesto que los módulos en rama de desarrollo pueden ser inestables o incompletos. Pero el trabajo del administrador de cualquier proyecto, sea web o cualquier otro de software, es testear todo en un entorno de pruebas antes de pasarlo a producción. Y créeme que no paso ni un solo modulo, ni una sola actualización, ni una sola modificación, antes de haberla testeado debidamente en un entorno de pruebas replica del de producción.
Al igual que la migración de 4.x a 5.x... no fue un dolor... fue algo compleja, porque algunos módulos habían cambiado bastante... pero ni mucho menos fue un dolor... porque antes de hacer la migración en productivo, hice la migración en local unas 4 veces para tener el método más sencillo, limpio y libre de errores. Y claro que hay que reinstalar algunos módulos, es algo que ocurre a veces sin tener que migrar de una versión a otra, simplemente porque el modulo ha cambiado mucho, porque empezó como una cosa y acabo con otra más compleja y con distinta concepción... y hasta ahora siempre para mejorar...
Pero nadie dijo que Drupal fuera sencillo... no lo és... ni mucho menos, Drupal no es para todos los públicos... instalar correctamente un TinyMCE en español, con diversos añadidos, pues requiere saber lo que se tiene entre manos, por ejemplo. Pero eso no lo convierte en malo, ni muchisimo menos.
Y si, cambian muchas cosas para mejorar la eficiencia... y bienvenidos sean los cambios!!! porque en la versión 4.7.x Drupal era muchísimo más perezoso que en la versión 6.x y eso es algo innegable... y la gestión de los themes en esta nueva versión esta muchísimo mejor diseñada y es mucho más eficiente que en la versión 4.x, no hay color, como el día y la noche... y que conste que a mi también me costo realizar los cambios, pero aprendí mucho en el camino, porque tengo un tema personalizado... pero me extraña que digas que te costó mucho cambiar el theme, cuando usas uno creado por un tercero en tu página...
Quieres que se estanque y no progrese? Quieres que los fallos de diseño y de concepto que se van descubriendo con el tiempo no se corrijan? No me hables de Debian... ni de SSOO... en Debian y en todos los Linux, el kernel (por ejemplo) se modifica cuando hace falta y sin que a nadie le tiemble el pulso... el ejemplo perfecto de no modificar la API o apenas no modificarla, es Windows, que sigue arrastrando los mismos fallos de diseño de su concepción, solo para mantener esa supuesta retrocompatibilidad que reclamas... que seria de Apple hoy en día, si no hubieran tenido los cojones suficientes para tirar con su MAC OS, rediseñarlo desde 0 partiendo de BSD y lanzar el MAC OS X, el SO que los esta devolviendo a la actualidad informática y que tantas alegrías le está dando a sus usuarios... de verdad quieres un CMS así? pues tienes decenas de ellos... casi todos los CMS comerciales y privativos de renombre son así, gigantes perezosos, mal diseñados, que no hay donde cogerlos, pero eso sí, mantienen la retrocompatibilidad...
Yo prefiero aguantar los pequeños inconvenientes de los cambios (por otro lado normales a todo proyecto software que este vivo, activo y fresco) que renunciar a que Drupal evolucione y mejore con el tiempo...
#4 Evidentemente, para hacer la migración, hay que tener primero migrados los módulos a la rama 6.x.
Pero que módulos críticos no han sido migrados a la versión 5? Yo llevo más de medio año con la versión 5.x y no he tenido problema alguno. Y empecé con una 4.6.11
Y solo hay que ver que el numero de módulos para la versión 5 es muy, pero que muy superior a los disponibles para la versión 4.7.x
#5 Acidfree (imágenes y galerías) está a medio hacer, y con el tío fuera de combate.
Y si, puedo usar image y sus módulos hermanos. ¿Problema? que en 4.x el modulo image apestaba y Acidfree era una pasada, y creo que no hay un modo sencillo de pasar todo lo de Acidfree a Image
Y por otro lado hay un huevazo de módulos que aún teniendo versión para 5.x funcional, siguen con la rama -dev sin sacar versión estable.
No habría tanto problema si los de Drupal no cambiaran la API con cada versión.
#6 También Debian usa software de terceros y no por eso deja de cuidar todos y cada uno de los paquetes que contiene. Y no por eso deja de ser también muy estable y sin apenas problemas de migraciones.
Aparte de Acidfree, la migración de 4.x a 5.x fue un dolor para un montón de gente (basta que revises los foros). Había que reinstalar módulo a módulo, y a veces ni siquiera bastaba ejecutar update.php porque había que seleccionar versiones distintas de bases de datos a mano.
El tiempo que pasa entre versiones de Drupal es demasiado pequeño. ¿Que funcionan los módulos -dev? Pues si, pero no siempre, porque para algo están en desarrollo. Es como si me sugirieras que instale Debian SID para un entorno de producción. Yo lo tengo en mi equipo personal desde hace años y puede servir, pero lo no metería a un servidor ni de coña.
Por otro lado que justifiques cambios en la API ya sangra, pero que justifiques lo que atañe a los temas, manda huevos coño. Que ya me costó horrores actualizar un tema de 4.x a 5.x ahora me mataré a pasarlo a 6.x. Y no porque hiciera virguerías, que va. Es simplemente que cambian la forma de que las plantillas interpreten los datos con la excusa de "es que ahora es mas eficiente".
¡Coño! ¿No pueden tomarse el tiempo a hacer un API lo suficientemente estable como para que cuando existan mejoras se pueda mantener la compatibilidad hacia atrás sin que casquen la mitad de las cosas?
Comentarios
Antes de crear mi weblog estuve dudando entre Wordpress y Drupal, escogí wordpress pero dentro de poco me pasaré a Drupal para probarlo y luego decidiré entre los dos
Seguro que mejor que blogspot es, por que a mi me va de pena..
#6 Bueno, yo tengo unos 9 módulos funcionando con la rama desarrollo (-dev) sin problemas. A lo sumo he tenido que parchear algún modulo o hacer alguna modificación a mi gusto en alguno.
No veo el modulo Acidfree como critico. De todos modos tienes una rama -dev que debería funcionar sin problemas y con la que podrías migrar (evidentemente siempre realizando una batería de pruebas en local). Y su desarrollo no está parado ni muchísimo menos, la última versión es de ayer!!!!! Vamos, que este tipo de cosas son de esperar en un proyecto de este tipo... y a veces puede que no quede más remedio que remangarse y ponerse manos a la obra... de todos modos, lo que hay que hacer es tener siempre una versión en local e ir mirando la evolución de los desarrollos, a veces parece que un proyecto está parado y ni muchísimo menos... hay que echarle también un ojo los repositorios CVS...
Está clarisimo que cuando uno se mete a un CMS debe de ser consciente de donde se está metiendo. Es lógico que con módulos de terceros te arriesgues a que se pare su desarrollo, sobre todo sin son módulos poco populares. Por eso hay que elegir con cuidado los módulos que realmente necesitamos, conociendo el compromiso entre beneficio para el proyecto y riesgo de que se frene su desarrollo. Al igual que cualquier personalización que hagamos a medida lleva consigo el consiguiente mantenimiento y adaptación a cada nueva versión. Si por ejemplo desarrollamos un tema a medida, debemos ser conscientes de que puede que tengamos que rehacerlo casi por completo para la nueva versión. Lo mismo si modificamos el código de el core o algún modulo básico o tenemos módulos propios. Cuanto más nos alejemos del CMS out-of-the-box, más complejo y más tedioso será el mantenimiento. Pero esto es inherente a cualquier proyecto web y en general a cualquier proyecto software. Crees que existe algún CMS en el que esto no ocurra? pues déjame decirte que si es así, te equivocas... he trasteado con unos cuantos, y créeme que a pesar de los inconvenientes para migrar los desarrollos a las nuevas versiones en Drupal, es quizás uno de lo CMS que más cuida que los datos se migren sin problemas y de la forma más transparente entre versiones. Las migraciones, con todos los módulos actualizados, son de lo más sencillas y menos problemáticas que he visto... no puedo decir lo mismo de otros CMS que me ha tocado SUFRIR...
Yo no creo que se deba frenar el desarrollo de la API... seria perjudicial... muy perjudicial... de todos modos, aún no he tenido ningún problema para migrar versiones... y ayer mismo probé una migración en local a la nueva versión, y salvando el escollo de que no todos los módulos han sido portados a la nueva rama, todo fue sin problemas... me toca migrar algunas personalizaciones y rehacer el theme, completar la traducción al español y esperar a que todos los módulos esten portados...pero es algo que ya me esperaba... que no queda más remedio y que incluso... me divierte!!!
#8 Por supuesto que los módulos en rama de desarrollo pueden ser inestables o incompletos. Pero el trabajo del administrador de cualquier proyecto, sea web o cualquier otro de software, es testear todo en un entorno de pruebas antes de pasarlo a producción. Y créeme que no paso ni un solo modulo, ni una sola actualización, ni una sola modificación, antes de haberla testeado debidamente en un entorno de pruebas replica del de producción.
Al igual que la migración de 4.x a 5.x... no fue un dolor... fue algo compleja, porque algunos módulos habían cambiado bastante... pero ni mucho menos fue un dolor... porque antes de hacer la migración en productivo, hice la migración en local unas 4 veces para tener el método más sencillo, limpio y libre de errores. Y claro que hay que reinstalar algunos módulos, es algo que ocurre a veces sin tener que migrar de una versión a otra, simplemente porque el modulo ha cambiado mucho, porque empezó como una cosa y acabo con otra más compleja y con distinta concepción... y hasta ahora siempre para mejorar...
Pero nadie dijo que Drupal fuera sencillo... no lo és... ni mucho menos, Drupal no es para todos los públicos... instalar correctamente un TinyMCE en español, con diversos añadidos, pues requiere saber lo que se tiene entre manos, por ejemplo. Pero eso no lo convierte en malo, ni muchisimo menos.
Y si, cambian muchas cosas para mejorar la eficiencia... y bienvenidos sean los cambios!!! porque en la versión 4.7.x Drupal era muchísimo más perezoso que en la versión 6.x y eso es algo innegable... y la gestión de los themes en esta nueva versión esta muchísimo mejor diseñada y es mucho más eficiente que en la versión 4.x, no hay color, como el día y la noche... y que conste que a mi también me costo realizar los cambios, pero aprendí mucho en el camino, porque tengo un tema personalizado... pero me extraña que digas que te costó mucho cambiar el theme, cuando usas uno creado por un tercero en tu página...
Quieres que se estanque y no progrese? Quieres que los fallos de diseño y de concepto que se van descubriendo con el tiempo no se corrijan? No me hables de Debian... ni de SSOO... en Debian y en todos los Linux, el kernel (por ejemplo) se modifica cuando hace falta y sin que a nadie le tiemble el pulso... el ejemplo perfecto de no modificar la API o apenas no modificarla, es Windows, que sigue arrastrando los mismos fallos de diseño de su concepción, solo para mantener esa supuesta retrocompatibilidad que reclamas... que seria de Apple hoy en día, si no hubieran tenido los cojones suficientes para tirar con su MAC OS, rediseñarlo desde 0 partiendo de BSD y lanzar el MAC OS X, el SO que los esta devolviendo a la actualidad informática y que tantas alegrías le está dando a sus usuarios... de verdad quieres un CMS así? pues tienes decenas de ellos... casi todos los CMS comerciales y privativos de renombre son así, gigantes perezosos, mal diseñados, que no hay donde cogerlos, pero eso sí, mantienen la retrocompatibilidad...
Yo prefiero aguantar los pequeños inconvenientes de los cambios (por otro lado normales a todo proyecto software que este vivo, activo y fresco) que renunciar a que Drupal evolucione y mejore con el tiempo...
Aqui se puede ver un Screencast de las novedades de esta versión, http://www.masteringdrupal.com/screencast/new-features-drupal-6 (en inglés)
Cojonudo. La mitad de módulos (algunos críticos) a medio adaptar a Drupal5 y estos sacando Drupal6 y cambiando otra vez la API.
#4 Evidentemente, para hacer la migración, hay que tener primero migrados los módulos a la rama 6.x.
Pero que módulos críticos no han sido migrados a la versión 5? Yo llevo más de medio año con la versión 5.x y no he tenido problema alguno. Y empecé con una 4.6.11
Y solo hay que ver que el numero de módulos para la versión 5 es muy, pero que muy superior a los disponibles para la versión 4.7.x
#5 Acidfree (imágenes y galerías) está a medio hacer, y con el tío fuera de combate.
Y si, puedo usar image y sus módulos hermanos. ¿Problema? que en 4.x el modulo image apestaba y Acidfree era una pasada, y creo que no hay un modo sencillo de pasar todo lo de Acidfree a Image
Y por otro lado hay un huevazo de módulos que aún teniendo versión para 5.x funcional, siguen con la rama -dev sin sacar versión estable.
No habría tanto problema si los de Drupal no cambiaran la API con cada versión.
#6 También Debian usa software de terceros y no por eso deja de cuidar todos y cada uno de los paquetes que contiene. Y no por eso deja de ser también muy estable y sin apenas problemas de migraciones.
Aparte de Acidfree, la migración de 4.x a 5.x fue un dolor para un montón de gente (basta que revises los foros). Había que reinstalar módulo a módulo, y a veces ni siquiera bastaba ejecutar update.php porque había que seleccionar versiones distintas de bases de datos a mano.
El tiempo que pasa entre versiones de Drupal es demasiado pequeño. ¿Que funcionan los módulos -dev? Pues si, pero no siempre, porque para algo están en desarrollo. Es como si me sugirieras que instale Debian SID para un entorno de producción. Yo lo tengo en mi equipo personal desde hace años y puede servir, pero lo no metería a un servidor ni de coña.
Por otro lado que justifiques cambios en la API ya sangra, pero que justifiques lo que atañe a los temas, manda huevos coño. Que ya me costó horrores actualizar un tema de 4.x a 5.x ahora me mataré a pasarlo a 6.x. Y no porque hiciera virguerías, que va. Es simplemente que cambian la forma de que las plantillas interpreten los datos con la excusa de "es que ahora es mas eficiente".
¡Coño! ¿No pueden tomarse el tiempo a hacer un API lo suficientemente estable como para que cuando existan mejoras se pueda mantener la compatibilidad hacia atrás sin que casquen la mitad de las cosas?