A principios de enero, alguien en neosmart publicaba un artículo llamado Cómo WordPress malcría a los desarrolladores, en el que planteaban una posición que probablemente muchas personas ya habían pensado pero que quizás nunca se había expresado con tanta vehemencia. Traduzco un párrafo del artículo:
El impacto más obvio que WordPress ha tenido —sobre todos— es que realmente no hay mucho espacio para otra plataforma para bloguear. No importa qué tan bueno sea el producto competidor que alguien cree, es casi imposible para cualquier cosa superar a WordPress como la herramienta elegida para el trabajo —sin importar cuál sea éste. WordPress no es perfecto, y somos los primeros en admitirlo. Ciertamente no es la plataforma para blogs más liviana ni el CMS definitivo, pero definitivamente esto no le ha impedido conquistar el mercado.
Contundente, pero con una contradicción evidente: afirma que no existen alternativas reales a WordPress, a la vez que reconoce que si éste está en el primer lugar de las preferencias no es necesariamente porque sea la mejor opción.
Durante Enero tuvimos varias noticias sobre WordPress que, en mi opinión, han venido alterando un poco este panorama, y que quizás podrían llegar a hacer tambalear la seguridad del predominio. Vamos por partes…
El pasado reciente de WordPress
Enero del 2007 probablemente ha sido el mes con más movimiento en el blog de desarrollo de WordPress, con cuatro importantes posts:
- WordPress 2.0.6 fue anunciado el día 5, un release orientado principalmente a arreglar fallas de seguridad, pero que sin embargo produjo nuevos problemas como el llamado “FeedBurner bug” que impedía a este servicio acceder correctamente a la información de tu feed.
- El 9 se publicó Ideas and Kvetch!, una iniciativa para
enfocarse en el ingrediente secreto de WordPress… tú
, creando espacios para enviar quejas e ideas al equipo de desarrollo de :wp:… ¿alguien dijo bloatware? - Justo a mitad de mes se lanzó WordPress 2.0.7… ¿por qué una nueva versión menor tan pronto? En buena medida, para arreglar los errores con los que la anterior había sido publicada.
- Finalmente, el 22 se hizo pública WordPress 2.1 Ella, la increíblemente atrasada y esperada nueva versión mayor de WordPress, sobre la que —como era de esperar— un montón de gente expuso su opinión: algunos la alabaron y otros (creo que muchos más que nunca antes) se quejaron, ya que a pesar de la considerable demora no hay muchas novedades visibles para los usuarios como para justificar la actualización, la que por otra parte no dejó de presentar sus dificultades en algunos casos
A esto, agregaría el anuncio de un ciclo de desarrollo para WordPress que significaría plazos de actualización regulares y estructurados.
Esto bien podría ser solamente una impresión personal, pero creo que como nunca antes los usuarios de WordPress se han manifestado como “menos que contentos” con el rumbo que se está delineando. No son solamente los errores en los lanzamientos que supuestamente deberían arreglarlos, o que tras una espera demasiado prolongada la nueva versión no haya respondido a las expectativas, o que su “conexión” con la comunidad pueda resultar en un software lleno opciones poco útiles… es cada una de estas cosas y todas juntas a a vez, es en definitiva un clima algo enrarecido que huele un poco a descontento, y quizás (sólo quizás) también un poco a cambio.
… Y entonces, el 20 de enero surgió un competidor a Wordpress
¿Habari?
Habari es el nuevo proyecto para crear un sistema de gestión de contenidos de código abierto que ha producido mucha bulla en la blogósfera (sobre todo la anglófona), por la simple razón de que algunos connotados desarrolladores de WordPress son quienes están detrás de él… habría que decir ex desarrolladores de WordPress ya que han pasado a trabajar exclusivamente en Habari. Seguramente conocen a algunos de ellos:
Chris J. Davis, co-desarrollador de K2, uno de los themes de WordPress más populares.- Michael Heilleman, creador de Kubrick (el tema predeterminado de WordPress) y co-desarrollador de K2.
- Khaled Abou Alfa, diseñador de aquella soñada remodelación de la administración de WordPress llamada Shuttle.
- A estos habría que sumar el que alguna vez fuera el octavo miembro de Automattic, Bryan Veloso, quien estaría encargado de diseñar el sitio web del proyecto.
Al ver esta lista de eminentes personajes notablemente ligados al desarrollo de WordPress ponerse al servicio de un nuevo proyecto que se presenta frontalmente como un competidor, creo que es inevitable preguntarse qué razones podrían existir para este alejamiento.
Las hay. Algunas han sido brutalmente exageradas por algunas de las personas que han seguido esta teleserie y escrito sobre ella, pero no creo equivocarme al afirmar que podríamos resumirlas en una: diferencias “filosóficas” con el rumbo del desarrollo de WordPress.
Bryan Veloso vs. Matt Mullenweg
Ok, este es un encabezado sensacionalista, debo decirlo. No existe nada así como una confrontación directa o guerra declarada entre ambos. Para ser claros, es necesario indicar que Bryan Veloso ni siquiera es uno de los “padres” de Habari, pero su historia parece ser bastante representativa de lo que ha pasado, además de ser uno de los que más se ha dedicado a escribir sobre el asunto. Jamás se ha referido en malos términos a Matt ni a la gente con que trabajó en Automattic, aunque ciertamente ha sido el más abierto a mostrar el lado personal de esta historia.
A mediados del 2006 (fines de julio), Bryan Veloso fue integrado al equipo de Automattic para trabajar en el equipo de diseño y desarrollo de WordPress, bbPress y sus otros productos. El trabajo de Bryan pudo verse en la nueva barra de administración de WordPress.com, pero poco más se supo del trabajo que habría desarrollado.
Bryan es un excelente diseñador, por lo que pensar que su trabajo se abocaría al necesario rediseño de la administración de WordPress era una apuesta que podía suponerse segura, ya fuera implementando Shuttle o su propia versión, Atlantis.
Sin embargo, pasó el tiempo y las noticias al respecto escaseaban. Un par de posts en los que pedía sugerencias fueron todo lo que pudimos ver, hasta un post publicado el 7 de diciembre, Pressing for Change, en el que anunciaba que dejaba Automattic.
Sí, algo ha muerto hoy. Si es que esa muerte me afecta, o más bien, la magnitud con que esa muerte me afecta aun está sujeto a interpretación. De todas maneras, a partir de hoy, Automattic y yo recorreremos caminos distintos. Al pensar sobre eso ahora, veo que la razón ha sido una más fundamental. La forma en que trabajo simplemente no encajó a sus expectativas. Podría hablar de cómo difieren las expectativas de diseñadores y programadores, o cómo es que usar Trac para medir la producción puede no ser la mejor forma de medir mi progreso. Honestamente, eso no haría nada por la situación. Fueron unos cuatro meses espectaculares trabajando con algunas de las mentes más inteligentes en el medio. Sé que llegarán lejos.
Veloso, fuera. Matt Thomas —quien ha hecho todo el trabajo de identidad para WordPress— adentro. Shuttle entraba en pausa, a pesar de que una de las últimas solicitudes de Veloso fue completar su trabajo en el proyecto.
Pasaría poco tiempo para agregar un nuevo capítulo (¿final?) a esta historia: el 19 de enero de este año, Bryan publicó esta serie de imágenes en un post titulado Atlantis: lo que podría haber sido.
Junto a ellas, sus últimas declaraciones al respecto.
No considero a éste mi mejor trabajo, creo que por eso es que Matt [Mullenweg] me envió éste cierto libro [”Diseñando lo obvio: un acercamiento desde el sentido común al diseño de aplicaciones web”] cerca de la hora de mi partida. Pero en mi defensa, no tuve muchas oportunidades de trabajar en él. O más bien, para refinarlo. […]
Algunas personas son muy apegadas a sus ideas, tanto como para impedir que cualquier otra persona se meta con ellas. Para ser honesto, me puedo identificar con eso, y toda esta experiencia abrió mis ojos a un montón de cosas.
Y hasta ahí llegó el idilio de Bryan con WordPress, el que alguna vez llamara el único software para bloguear que usaría jamás
, pero que ahora tendría planeado reemplazar por Django (que en realidad es un framework para Python).
Bueno, ¿y? ¿Qué pasó con Habari?
Pasa que, al parecer, la gente tras Habari también se ha visto un poco frustrada en sus aportes a WordPress. Jim Whimpey ha caricaturizado algunas de estas quejas: Matt es un dictador malvado que maneja una compañía llega de sus igualmente malvados lacayos que trabajan juntos en una horrible monstruosidad llamada WordPress
. Claro, esto es una exageración, pero ¿notaron las frases que destaqué en la última cita de Veloso? Los desarrolladores de Habari han aclarado que su partida no tiene que ver con resentimiento, sino a lo más con “diferencias” y el deseo de crear algo nuevo y sorprendente.
Para Michael Heilleman, se trata de llevar a cabo el diseño de la interfaz que fue postergada junto al proyecto Shuttle, pero junto a esto se muestra preocupado por el que para él es un movimiento innegable de WordPress hacia “aguas comerciales” (lo que sea que eso signifique), el que afirma no condenar pero que sin embargo le hacen añorar tiempos pasados.
Chris Davis, por su parte, confiesa haberse sentido algo irritado con la forma en que se maneja WordPress; invoca su experiencia en las conferencias de la Fundación Apache como un punto de contraste en la forma de hacer las cosas, afirmando sentirse más cómodo con la forma en que funciona Apache.
Rich es quien, definitivamente, dibuja más claramente el panorama:
Sí, habían frustraciones de las que nos queríamos alejar. Y habían diferencias filosóficas sobre cómo debería ser gestionada una comunidad de Código Abierto. Pero no hay mala voluntad hacia WordPress, aun cuando hay diferencias de opinión sobre la Manera Correcta de hacer las cosas. En el Código Abierto, cuando las cosas se hacen bien, no es dañino tener dos proyectos saludables en el mismo espacio. Cuando las licencias son sensibles los proyectos pueden aprender el uno del otro, mejorar las ideas de cada uno, y tener una competencia sana, así como también esforzarse por ser compatibles. No veo un lado malo, si es que podemos seguir existiendo en una amistosa rivalidad.
En WordPress, los cambios más importantes al código deben ser revisados y aprobados por Matt, así como también las ideas para implementar nuevas características. Habari pretende tener un modelo más abierto de desarrollo, sin dejar de estar organizado aunque quizás sí menos centralizado. Proponen un sistema de meritocracia para obtener acceso a modificar el código de la aplicación, ésta es la inspiración fundamental que han extraído de Apache (aunque aun no se ha plasmado en un modelo estructurado).
¿Y qué va a pasar con WordPress?
Probablemente no mucho muy distinto… o sea, las líneas de su desarrollo han sido en buena medida trazadas con lo que ha pasado durante enero, y creo que ahora podemos fijarnos nuevas expectativas de lo que podríamos esperar a futuro.
¿Rediseño de la administración? Difícil. ¿Muchas características nuevas? Quizás, y probablemente varias de ellas suplanten la función que hoy tienen distintos plugins. Está la posibilidad de que se convierta en un bloatware, y no me gusta… y no soy el único al que no le gusta.
La movida “hacia aguas comerciales” es bastante indefinida. Creo que, en primer lugar, podríamos esperar más énfasis en WordPress.com que en “.org”, Akismet y el soporte pagado para instalaciones comerciales de WordPress que se anunció hace tiempo en Automattic. Está bien, después de todo, esto se ha transformado en un gran negocio, sería estúpido no tratar de obtener beneficios de él o desperdiciar estas oportunidades. No creo que Automattic comience a publicar software que no sea de código cerrado, o que WordPress (.org) se vuelva de pago.
Y sobre Habari… habrá que ver. Actualmente, hay una versión que funciona que puede ser descargada, pero está a años luz de siquiera igualar a WordPress. En serio, la acabo de probar, y está bien, pero muy incompleto; de hecho, hay mucho más trabajo por hacer que el que ya está hecho. Por otra parte, el requerimiento de PHP 5 reduce la cantidad de personas que podrían ejecutarlo, ya que todavía hay muchos hosts que utilizan PHP 4. Finalmente, no es la primera vez que sus desarrolladores se han unido para crear algo que ha recibido mucha publicidad: hace tiempo, se anunció con bombos y platillos la creación de InkSmith, pero hasta el día de hoy página de inicio reza “coming soon”.
Al día de hoy, la mayor fortaleza de WordPress es su comunidad. ¿Logrará Habari un nivel de participación no solo de programadores sino también de usuarios suficiente para convertirse en una verdadera competencia?
Fuentes
- wordpress™ wank
- Habari Wank!
- Habari
- How WordPress Spoils Developers
- Atlantis: What May Have Been. Powered By Avalonstar.
- Pressing for Change. Powered By Avalonstar.
- Habari, primeras imagenes del posible asesino de Wordpress | aNieto2K
- Time to Habari at Binary Bonsai
- Chris Davis: Why Move.
- DrBacchus’ Journal
Últimamente me paso más ratos instalando nuevas versiones de WP-Cache que buscando nuevos blogs que leer, es lo que tiene hacer de beta-testing ;).
WP-Cache 2.1 viene a corregir problemas con PHP5 (versión que cambio el comportamiento de las llamadas al buffer) y por si las dudas: sí, funciona en WordPress 2.1.
Si las anteriores versiones te han dado algún problema (principalmente a los que usan PHP5) probad esta.
webdev, wordpress, wp cacheUna de las cosas que más me gusta de DreamHost, y realmente hay muchas cosas que me gustan en este servicio de hosting, es la opción de subir archivos al servidor en formato comprimido zip, tar, tgz o gz). Es sorprendentemente rápido alojar el paquete de software de una aplicación como WordPress, acción que lleva mucho más tiempo con un cliente de FTP. Simplemente hay que comprimir el conjunto de carpetas y ficheros, subirlo al servidor y el sistema se encargará de descomprimirlo, crear los subdirectorios que no existan y distribuir los archivos en ellos. El tamaño máximo permitido del archivo a subir es de 78125 kB.
Para ello, hacer click en el botón “Upload” en el panel de control webftp del dominio correspondiente:
A continuación rellenar el campo de “Archives” o buscarlo con el botón “Examinar”:
Les recuerdo que si les interesa DreamHost, pueden ahorrarse 90 dólares con nuestro código de promoción s90.
blogpocket se publica bajo licencia Creative Commons.
Desde Blogpocket, me mandan este meme bastante interesante ya que me he hecho plantearme por que motivos dejaría lo que tengo aqui, dejar mi vida tal y como la conozco hoy en día y irme a otro pais. La verdad es que es algo que me he planteado otra veces pero nunca he plasmado, ni en papel ni en soporte digital.
- Catastrofé natural, sin duda un motivo más que fuerte para irte.
- Que lo alemanes terminen de tomar la isla… si impusieran en Alemán como lengua oficial sería sin duda un motivo más que justificado.
- Que alguien con derecho y poder pudiera coartar mi libertad de expresión y no permitirme con total libertad en cualquier campo.
El meme lo voy a dejar abierto, y que cualquiera que esté dispuesto y con ganas de seguirlo lo haga.
Muy buen plugin para Wordpress que te integra Slightbox, una nueva versión de lightbox sobre MooTools. El diseño obtenido es bastante elegante.[Demo][Descargar]
Bueno después de dos días sin postear y liadillo con los errores que me daba Wordpress 2.1, creo que ya he conseguido dejarlo todo listo.
Lo primero es dar las gracias a mi amigo JaviVicente por haberme hechado un cable con la actualización de Wordpress a 2.1. Los que estéis interesados, Javi a publicado en su blog la solución a todos los problemas que el ha encontrado al actualizar(Error en Dashboard, Crear tabla wp_link2cat).
En esta nueva versión los enlaces están organizados en categorías, y si los queréis listar por categorías al igual que yo, tendréis que hacerlo de la siguiente forma:
<?php get_links('67', ' <li> ', ' </li> '); ? >Y poniendo el ID de la categoria que queréis listar, en mi caso es la categoría 67.
Bueno, pues a parte de eso mi mayor problema ha sido con los plugins, ya que hay muchos que no funcionan, aquí os dejo la solución para alguno de los que yo utilizo.
- Pagebar: La solución es dirigirse a la pagina del plugin y bajarse la ultima versión(esto funciona con muchos).
- Category Tagging: Con este no había forma, así que tuve que buscar una alternativa, o sea otro plugin que hiciera lo mismo, y el afortunado ha sido WordPress Heat Map.
Bueno, pues estos son los que yo he considerado más importantes, porque afectaban al diseño del Blog, los otros la verdad es que me son indiferentes, ningún plugin es esencial para que funcione bien un blog. Recordad que siempre podéis ir a la pagina del creador y bajaros la ultima versión del plugin y con un poco de suerte y si el autor la va actualizando, os funcionara.
Y por ultimo a los que os guste mucho leer, y todavía dudáis si actualizar a Wordpress 2.1 o no, siempre le podéis echar un ojo al magnifico tutorial de actualización de Wordpress 2.1 que se ha currado nuestro amigo Manuel Almeida.
Dr. Web Weblog nos ofrece 80 interesantes plantillas para WP: 80 WordPress Themes. Se busca theme para blogpocket 7. Requisitos: claridad, diseño limpio, simplicidad, dos o tres columnas (si, abandono el blog de una columna que ha resultado muy restrictivo a la hora de incluir algunos elementos -como banners de publicidad-), uso de widgets en el sidebar, etc. El logo de la cabecera y el lema permanecerán.
Publicidad: blogpocket&labrujulaverde ¡qué blogs!
blogpocket se publica bajo licencia Creative Commons.
He estado leyendo mucho acerca de la nueva versión de Wordpress, y ya me estaba entrando el gusanillo. Así que esta noche he perdido 3 min y he pasado el blog a la versión 2.1. No he tenido ningún problema serio, crear una tabla que parece que es bastante común y nada más importante que reseñar. Bueno quizas el que esté todo en Inglés 
Pero no es algo prioritario.
Me ha gustado la velocidad que ha ganado, parece que el menú administrador se mueve con mayor soltura, la opción de comentarios en el menú administrador tambien me ha encantado ya que ahi se concentran todos y no hay que ir a buscarlos por las otras opciones. Aunque no me ha gustado que por sus santos coj… tenga que teneis script.aculo.us en mi directorio wp-include/js/ sin yo querer…
Aprovechando el cambio he modificado el theme y un fichero crítico de Wordpress para acabar con el SPAM, así que si teneis algún problema al enviar un comentario, por favor, hacermeló saber y miraré de solucionarlo en breve.
La idea es muy simple, he creado un md5 del nombre del blog.
$noSpamKey = md5(get_bloginfo('name'));
Y se lo añadido al principio de cada elemento del formulario de comentarios, quedando nombres similares a estos.
bda5092c5115f6535ab306efb86285b1author <-- author bda5092c5115f6535ab306efb86285b1email <-- email bda5092c5115f6535ab306efb86285b1url <-- url bda5092c5115f6535ab306efb86285b1comment <-- comment
Una vez modificado esto, Y SOLO ESTO, dejando los demás campos tal cual, ya que son necesarios para comprobaciones previas que no nos interesa llegar a comprender
Nos dirigimos al fichero wp-comments-post.php, el fichero encargado de almacenar los posts y al que los robots atacan. Y modificamos el fichero sobre la línea 20.
Es muy importante tener una cópia de seguridad del fichero por si cometemos algín error.
$noSpamKey = md5(get_bloginfo('name')); //Añadimos $comment_author = trim($_POST[$noSpamKey.'author']); //Concatenamos la clave $comment_author_email = trim($_POST[$noSpamKey.'email']); //Concatenamos la clave$comment_author_url = trim($_POST[$noSpamKey.'url']); //Concatenamos la clave$comment_content = trim($_POST[$noSpamKey.’comment’]); //Concatenamos la clave
De esta forma estamos consiguiendo que no nos ataquen los robots, aunque no es una forma muy eficiente de prevenir el SPAM, con un poco de imaginación podemos hacer cosas como estas
$noSpamKey = md5(date()); // Una clave nueva por día
$noSpamKey = md5(get_bloginfo(’name’).date()); // Una clave nueva por día, además del nombre
$noSpamKey = md5(”por que yo quiero y me da la gana”); // Una clave indescifrable para cualquier robot, ya que se trata de algo personal.Lo que está claro es que debemos tener la misma clave en el formulario de envio que en la página receptora, lo suyo sería añadirla como una llave global en wp-config.php, y así podemos usarla en cualquier parte de nuestro Wordpress. Lo que me lleva a un pregunta. ¿Por que Wordpress no lo ha puesto?
Lo prometido es deuda, y como lo prometido era elaborar un post más extenso sobre mi experiencia en la actualización de Mangas Verdes a WordPress 2.1, pues cumplo con este artículo la deuda. La intención, evidentemente, más que para aburrir al personal con cuestiones domésticas que puede que a nadie interese, está en la puesta en común de mis problemas, soluciones y conclusiones para que cualquier usuario del cms pueda extraer de ahí lo que le parezca útil.
Para despejar dudas de inmediato y centrar el post de entrada, comenzaré por la conclusión: a día de hoy no me arrepiento en absoluto de haber actualizado. El sitio corre perfectamente, ligero, llevo ya casi una semana ¡sin un sólo spam! y sin caídas, los feeds aparecen casi de inmediato en los lectores y sin cortes, parece que sigo bien indexado por los buscadores… es decir, que tengo la impresión de que todo va como la seda. Eso sí, no nos llevemos a engaños, la cosa ha sido dura y difícil, con momentos en los que llegué a maldecir a WP y todos sus desarrolladores (a quienes, no obstante, sigo achacando una deficiente información respecto a todos los cambios que suponía el lanzamiento).
Y de eso precisamente es de lo que trataremos a continuación, del ‘long and winding road’ que he tenido que recorrer hasta llegar aquí. Espero que sea de provecho para alguien. Si contribuyo a que ese tortuoso camino se convierta en atajo para alguien, entonces daré por bueno el post.
(more…)
En Dr. Web Weblog han recopilado una lista de 80 themes liberados para WordPress. Fuente del.icio.us/popular.
Publicidad: Escucha podcasts. No te arrepentirás.
Contenidos bajo licencia Creative Commons (atribución by-nc-sa).
