El comentario de Fernando en la encuesta de que versión de Drupal usas, me animo ha escribir acerca de mi experiencia actualizando una pagina de Drupal 5 a 6. La pagina es Mulpo.com y fue una de las primeras paginas Drupal que hize cuando estaba estudiando acerca de comunidades en línea para mi tesis. Como cualquier principiante en Drupal empeze a instalar todos los módulos que sonaban útiles y muy pronto mi pagina sufría de modulítis, jeje. Varios ya estarán familiarizados con esta pantalla cuando estas en un ambiente de hosting compartido ;)
A medida que la página fue creciendo los errores de memoria parecían más frecuentemente, y era claro que tenía que moverme a un host virtual. Antes de migrar la página decidí actualizarla de Drupal 5 a 6, y aunque hubo algunos problemas en el camino, valió la pena el esfuerzo y trabajo por todos los beneficios que me trajo hacer la actualización. Según mi punto de vista estos fueron los beneficios de actualizar a Drupal 6:
- Siempre es bueno tener copias de tu base de datos, si pierdes tu información por alguna razón es fácil recuperarla. Para actualizar es *muy* recomendado hacer una copia de tu base de datos y si lo haces con la línea de comando es bastante fácil y rápido.
- Drupal 6 tiene bastante mejoras en performance y caché. Mulpo es mucho mas liviano y rápido desde que corre con Drupal 6, pero eso se debe también a la menor cantidad de módulos que termine necesitando después de la actualización. Alrededor de +80% del tiempo de carga de una pagina viene desde el front-end, ósea JS, CSS, imágenes y videos. Drupal 6 tiene un agregador de JS en el núcleo así que tu página puede terminar con un solo archivo JS y un solo archivo CSS, y si usas sprites una solo imagen de css =)
- Las mejoras en usabilidad son evidentes en Drupal 6, poder ordenar bloques, campos cck, menús, etc. arrastrándolos (drag & drop) es bastante cómodo. Los encabezados de las tablas se mueven contigo cuando estas bajando por la tabla, lo cual es muy útil en la pagina de permisos.
- Actualizar de una versión de Drupal a otra te hace perder el miedo a actualizar los módulos frecuentemente, es bueno que siempre estén actualizados por seguridad. Drupal 6 viene con un módulo que chequea si tus módulos están actualizados y si no lo están te da el enlace para la ultima versión, y si ha habido una actualización de seguridad, te alerta.
- Desarrollar temas en Drupal 6 es mucho mas avanzado y no es difícil actualizar un tema a Drupal 6. En Drupal 6 por ejemplo tienes $body_classes en núcleo y ya no tienes que hacer una función en template.php para tener algo así.
- Al igual que hay varios módulos que no han sido actualizados a Drupal todavía, hay bastantes módulo inovadores que solo están disponibles para Drupal 6. Dos módulos que se me vienen a la mente: admin y vertical tabs.
- Con el code freeze de Drupal 7 anunciado para el primero de Setiembre, Drupal 7 ya estará saliendo el próximo año, y Drupal 5 ya no estará oficialmente soportado. Actualizar ahora te hace estar preparado para el futuro.
- Tener que actualizar te hace darle una mirada seria a la lista de módulos que tienes en tu pagina. Si hay módulos (funcionalidades) que los usuarios no están usando en tu pagina, es una buena idea dejar de usar esos módulos. Si tienes módulos que ni siquiera están activados, lo mejor es borrarlos de inmediato, todos los módulos van a ser cargados en tu pagina aunque no los estés usando. Yo tenia 119 módulos, y resulto que después de actualizar a Drupal 6, termine usando alrededor de un tercio.
En general las empresas que usan Drupal solo deberían actualizar si alguno de los beneficios de usar Drupal 6 (son muchos mas, yo solo hize un pequeño resumen de los que se me vinieron a la mente), les dan a un valor agregado a su pagina desde el punto de vista de los usuarios, sean administrativos o end-users. Por ejemplo si tú página es más fácil de usar, incrementara la productividad de los administradores y hará que los end-users vengan más frecuentemente. Si incrementar la productividad y tener más visitas incrementa el retorno sobre la inversión que se hizo en la página entonces recomendaría actualizarte. Si la página es una página mayormente estática y que solo es actualizada por una persona, entonces los beneficios tal vez no justifiquen el tiempo que pases actualizándola, en todo caso, puedes esperar hasta el próximo año, aunque se que hay una compañía que va a portar todos los parches de actualizaciones de seguridad de Drupal 6 a Drupal 5.
Cuando hice una presentación acerca del proceso de actualización de esta pagina hize un esquema de que módulos estaba usando en mi pagina anterior, y como fueron tratados durante el proceso de actualización. La traduje al español, pueden verla en grande apretando el enlace.
Comments
Quita necesidad de memoria?
ipwa, me gustaría saber si tienes una evaluación del uso de memoria entre un D5 y un D6 equivalente (no en número de módulos, sino en funcionalidad total). Tengo varios portales corriendo en D5, que obviamente son super pesados (según devel, usan 40MB de memoria en el servidor en una sola carga de página) y es difícil para mi de evaluar si, pasando a D6, voy a tener una gananza considerable de memoria. Por esto, si tienes algunos datos al respecto...
Yannick Warnier
Manager y Consultor e-learning - http://www.beeznest.com
Presidente - Asociación Chamilo - http://www.chamilo.org
Eso depende que módulos vas a utilizar
Eso depende que módulos vas a utilizar.
El core de Drupal de por si ahorra consumo de memoria, porque se han reestructurado algunas cosas como por ejemplo (una de las más importantes para el tema de consumo de recursos) el sistema de menús. Sin embargo dependiendo los módulos que utilices uno de ellos podría consumir más memoria que su predecesor o equivalente en la versión anterior.
Drupal 5 es más rápido
La verdad es que haciendo un poco de investigación resulta que Drupal 5 es más rapido que Drupal 6. Lo que a mi me mejoro definitivamente entonces el performance fue la reducción de modulos que fui obligado hacer para actualizarme, y no actualizar de Drupal 5 a 6. Me hizo pensar seriamente en las necesidades de mis usuarios y en averiguar si ciertas funcionalidades eran utilizadas, y sino porque tenerlas, mejor hacer el sistema lo más simple posible para el usuario. Tambien bastantes funcionalidades en Drupal 5 que requerian varios pequeños módulos fueron reemplazados por un solo módulo en Drupal 6. Lo que a mi si me redujo seriamente el numero de queries que se hacían en la página fue usando Block caché en Drupal 6, especialmente las drupal_lookup_path de los menús. Y en general el numero de queries se redujo despes de la actualización incluso antes de activar block caché, pero no encuentro los pantallazos que le tomé a la página principal con devel activado antes y despues de actualizar :/
http://2bits.com/articles/benchmarking-drupal-5x-vs-6x-which-one-faster....
http://vision-media.ca/resources/drupal/drupal-performance-benchmarks-58...
http://2bits.com/articles/measuring-memory-consumption-by-drupal-bootstr...
--
Nicolas
comparación de capacidad de lenguajes multiples
Encontre esta comparación de capacidad de lenguajes multiples entre Drupal 5 y 6:
http://www.developmentseed.org/blog/internationalization/comparison_chart
--
Nicolas
Más funcionalidades = más carga
Gracias @ipwa por estos comentarios, he promovido tu post a otros grupos de habla hispana para que también se beneficien de tu aporte y las subsecuentes discusiones.
Drupal 6 tiene muchas ventajas no solo en cuanto al core y facilidades para hacer desarrollo, sino también en cuanto a módulos contribuidos. Los clásicos cck y views, son un ejemplo, pero @ipwa cita admin y vertical_tabs, los cuales mejoran de forma espectacular la usabilidad de Drupal.
En mi experiencia conozco que el core en D6 soporta muchas más funcionalidades, por lo tanto, aunque no todas estén activas, el simple hecho de soportarlas lo hace más lento. Pero esa velocidad es en cuanto a ejecución de código, respecto del manejo de memoria es definitivamente mejor. Y resalto la palabra manejo, que implica usar menos memoria donde D5 usaba demasiada. El otro punto es que Drupal abusa del uso de cache, de tal forma que se hagan menos consultas a bases de datos. Pero esto no implica necesariamente mejoras en cuando a la eficiencia del código.
Otro aporte importante de @ipwa es que un trabajo de migración ayuda a mejorar el rendimiento. Esto tiene varias condiciones:
- La migración es en todo o en parte el desarrollo de una nueva versión del sitio en sí mismo.
- Varios módulos de D6 permiten "ahorrar" muchos otros.
- Las mejoras en cuando a flexibilidad permiten personalizar con menos hacks, en el caso de views 2 uno se ahorra mucho código php en cuanto a theming y más bien se va por el lado CSS.
- La versión JQuery en D6 permite hacer mucho más con menos hacks. Incluso mejora en performance, porque JQuery Update trae problemas de rendimiento.
Finalmente, respecto de rendimiento se puede mejorar mucho con Boost, context, spaces y features. Los dos últimos permiten apagar y prender funcionalidades (features) de acuerdo al contexto (context) y espacio (spaces). Creo que debemos empezar a desarrollar por ese camino, no tengo un método definido todavía, pero si se quieren mejoras sustanciales, lo mejor es enseñarle a los módulos a que se carguen cuando realmente es necesario, y que el core "no les de bola"(tines algún hook?) cuando no es necesario.
--
more stuff...
(3 John 1:2) Dear friend, I pray that you may enjoy good health and that all may go well with you, even as your soul is getting along well.
--
[develCuy](http://steemit.com/@develcuy) on steemit
Talibánnnnnnn
Buen comentario, pero viendo perlas como "hubieron" o "traducí", inspiras poca confianza, la verdad...
Leo666 gracias por captar mis
Leo666 gracias por captar mis errores de ortografía en mi post (la critica era a mi post, no el comentario de Develcuy como se podría entender). Habiendo dicho eso, tu post no contribuye a la discución y es un poco descortés. Cuando escribí ese post, recién había regresado a Peru de Londres, donde había estado viviendo por 6 años, y solo escribía en Español cuando tenía que mandarle un mensaje por correo a un amigo o familiar (generalmente hablo por Skype, así que esos correos no eran muy frecuentes).
Drupal es una comunidad de desarrollo web, no es una comunidad de escritores ni de gramática. Tu puedes decir que mi post te inspira poca confianza (por lo ortografía, es gracioso porque en el post y comentarios hay información que le puede ser valiosa a muchos), tal vez si miras mi perfil de usuario, te de mas confianza: http://drupal.org/user/130909
En cambio tu perfil si no me inspira nadita de confianza: http://drupal.org/user/835334
--
Nicolas
Talibán es con una 'n'
Quizás un poco de criterio no te vendría mal a la hora de comentar leo666.
Concuerdo con jsalinasd;
Concuerdo con jsalinasd; bastante inútil y tonto el comentario de leo666, la verdad.
Gracias develCuy.
Tú ganas
El comentario será tonto e inútil, pero hay ciertas cosas que, con todos los respetos, hacen daño a la vista.
Algún día os dareis cuenta de que la presentación y la ortografía son tan importantes como el contenido
develcuy: ...pero si se
Enseñarle a los módulos que se carguen cuando sea necesario? Los módulos no deciden cuándo cargarse. Y no deberían. No debería estar en la capa de controller ni debería ser responsabilidad del programador de módulos. Es responsabilidad del Core decidir cuándo cargar los módulos; al menos esa es la arquitectura de Drupal.
Sobre la preocupación porque Drupal le pregunte a todos los módulos "implementas X hook?" cada vez que tiene que hacer algo, es cierto que eso puede afectar el performance negativamente, pero eso es consecuencia inevitable (creo) del patrón arquitectónico de Drupal, y además ya D6 optimiza ésta cuestión (guardando en memoria registros de quién implementa cual hook, llamando solamente cierta familia de hooks sin cargar todos los módulos en ciertas etapas del BOOTSTRAP, etc etc.), aunque se puede mejorar.
Otra cosa es que el performance depende mucho de cómo el programador implementa su controller code. Por ejemplo implementar las versiones específicas de los hooks cuando sea posible, en vez de las generales (hook_form_FORM_ID_alter() en vez de hook_alter() con un "switch" gigante dentro, por ejemplo). Muchos sitios Drupal son lentos porque usan módulos que están implementados pobremente (no cachean sus queries, no implementan los hooks específicos, etc), no porque Drupal sea lento.
Por cierto, todas esas implementaciones de hooks que inevitablemente llevan a un horrible gigante "switch" (o muchos if) deberían cambiarse y usar esa técnica que ya usan con form_alter(). La misma idea ya está más o menos aprovechada en D6 con la familia de funciones preprocess en el theme layer (theme_preprocess(), theme_preprocess_page(), etc etc.)
No sé por qué no aplican eso universalmente con todo lo que puedan, en el Core, en el Theme y en el API, si PHP es el lenguaje más flexible del mundo para decidir durante runtime cuales funciones llamar y cómo llamarlas.
Pero bueno, ya en D7 lo llevaron un paso adelante, eliminando hook_nodeapi() y dándonos hook_nodeapi_$op(), entre otras cosas. Está bueno pero se debería explotar más.
Viste Drupal 7
Drupal 7 incluye muchas mejoras a estas deficiencias tradicionales, dale un mirada :) y sobre como hacer las mejoras, Drupal es un framework a la vez que un CMS, tienes hooks que te pueden llevar a extender el core y mejorarlo como plataforma, mira ctools por ejemplo y hay otras API como imageapi (que ya se incorporó en Drupal 7). Todo esto esta creciendo bajo un modelo de mejora continua y por eso me fascina Drupal, no solo por el software y la comunidad, sino por el proyecto que es una palabra mayor EMHO.
--
[develCuy](http://steemit.com/@develcuy) on steemit
...Qué?
...Qué?
Otra cosa es que el
Amén. En la antigua página que trabajaba tenían el hook form alter con el switch mais grande do mundo, jeje. La página tenía muchos problemas, por que es bastante popular. Trato de siempre utilizar el fid cada vez que uso hook form alter.
Esto es verdad, hay muchos módulos populares en contrib que sufren por esto. Lo bueno es que tenemos d7 a la vuelta de la esquina y cada vez vamos a poder hacer aplicaciones más complejas con core y un par de módulos personalizados, en vez de utilizar 20 0 30 modulos de contrib.
--
Nicolas