Podéis actualizar directamente desde el Panel de Administración o descargar la nueva versión.

En esta versión me centraré en la sección de opciones (veréis muchos cambios a nivel de usuario y otros tantos a nivel de desarrolladores) y en un nuevo motor para los carruseles. A continuación os resumo las principales novedades.

Nuevo motor, nuevas posibilidades

Hasta ahora usaba Step Carousel para hacer funcionar los carruseles, sin embargo no veo que avance demasiado y otros scripts ya le superan en funciones útiles, como por ejemplo, el desplazamiento vertical en lugar de horizontal. Aún no he decidido cuál será el sucesor de Step Carousel, pero ya podéis dar por seguro que a partir de ahora Step Carousel no será el script que haga funcionar vuestros carruseles. Eso sí, jQuery seguirá siendo el framework que use el próximo motor.

Lamentablemente, este cambio requiere también cambio a nivel de themes, ya que el código necesario para crear los carruseles difiere en cada script. Por este motivo Step Carousel seguirá estando disponible dependiendo del theme activado. La API de themes variará bastante (lo explicaré más adelante), y una de las nuevas variables que añadiré indicará si el theme soporta o no el nuevo motor. Por defecto se supondrá que no lo soporta, así que a no ser que el theme se haya actualizado, se tomará Step Carousel como motor.

Si el theme está actualizado (todos los themes por defecto estarán actualizados) nos permitirá escoger el motor que queramos y dependiendo de lo que hayamos escogido se nos mostrarán unas opciones u otras diferentes. Un theme podrá tener versiones para Step Carousel y para el nuevo motor en un mismo paquete.

No lo voy a comentar con más profundidad, pero al tener un nuevo motor tendremos más opciones a la hora de mostrar el carrusel, que dependerán del motor que acabe decidiendo usar.

Nueva API de themes

Algo que habéis pedido muchos es poder cambiar los colores de los themes. Esta característica no me parece demasiado importante ya que cambiar los colores en el CSS es realmente simple, y hacer modificaciones más complejas requiere conocimientos básicos de programación en PHP, no un editor WYSIWYG con esteroides. Sin embargo en la nueva API de themes añadiré un sistema para que los autores de los themes puedan añadir campos de opciones en la página del carrusel, de modo que cada theme tendrá sus opciones únicas de forma más visible. Yo por mi parte añadiré un theme algo más personalizable, aunque no esperéis poder cambiarlo todo sin saber nada de código, los editores WYSIWYG se los dejo a Adobe.

Estas mejoras en la API de themes también repercutirán en la API de Extras, ya que seguramente añada la posibilidad de usar más campos en los formularios para mostrar contenido generado por Extras.

Nuevo diseño de la página de opciones

Toda la zona de opciones estará rediseñada y mejorada. La idea es aplicar lo aprendido al diseñar la interfaz Drag & Drop para crear una interfaz más cómoda, sencilla y potente para las opciones. Las únicas cosas que seguro que voy a añadir son el soporte para campos creados por los themes (a través de la nueva API) y el guardado AJAX. Todo lo demás aún está en el aire.

Mejoras en la interfaz Drag & Drop

También mejoraré algunas cosas de la interfaz Drag & Drop. La petición más popular ya está lista: la posibilidad de ocultar y mostrar contenido del carrusel está en la versión en desarrollo. Podéis ver cómo queda en la imagen de la izquierda. No tiene demasiada dificultad entender el funcionamiento y facilita bastante las cosas.

La verdad es que no sé cómo se me pasó esto durante el desarrollo de la nueva UI. Lo cierto es que hasta yo lo pasé mal a veces al añadir cierto contenido al carrusel, pero no se me ocurrió la idea hasta que me llegó la propuesta.

Otra novedad que me gustaría añadir es mostrar una miniatura de la imagen que se mostrará del artículo o del contenido personalizado (etiquetas, autores y categorías quedan fuera porque aún no he dado con una forma eficaz de mostrar las imágenes de diversos artículos en poco espacio), aún no sé las dificultades con las que me encontraré, pero me parece que esta característica de la antigua interfaz era muy interesante y se perdió (lamentablemente) con el paso al Drag & Drop.

Nuevo sistema de Backup

El sistema de Backup de WP Carousel es de lo más sencillo: copiar y pegar. Sin embargo se requiere de otro equipo donde almacenar la copia en un archivo creado manualmente por el usuario. Me ha llegado una propuesta realmente interesante para un nuevo sistema de Backup y me gustaría implementarla en la próxima versión.

El nuevo sistema crearía copias de seguridad cada X tiempo o cada cierta cantidad de cambios en el carrusel, y las almacenaría en la Base de Datos de WordPress. Dependiendo de cómo esté configurado el plugin, enviaría por email el Backup cada vez que se crease, permitiendo desde la página de Backup descargar el archivo de Backup, eliminar el Backup de la Base de Datos o restaurar el carrusel desde un Backup, aunque me gustaría seguir permitiendo copiar y pegar el código de Backup de forma manual, ya que es realmente cómodo para aquellas ocasiones en las que se presiente que el siguiente cambio va a estropear el carrusel (y realmente práctico durante el desarrollo).

Vídeos

Sí, muchos lo habéis pedido, y sí, mucho habéis esperado. Para mí no tiene demasiada utilidad, pero creo que para muchos es algo prácticamente imprescindible. WP Carousel permitirá añadir vídeos a partir de la versión 0.6. Aún no tengo decidido del todo cómo implementaré esta opción en la zona administrativa, así que se admiten propuestas. Estoy en contacto con Viper007Bond, autor de Viper’s Video Quicktags, para utilizar este plugin como intermediario entre los vídeos y WP Carousel, siendo necesario tener activado el plugin Viper’s Video Quicktags para poder mostrar vídeos.

Como veis, son muchas novedades que requerirán tiempo de desarrollo, tiempo que estará compartido con mis estudios de Objective-C que poco a poco van avanzando y ya están dando como fruto pequeñas y simples aplicaciones para el iPhone carentes de momento de utilidad alguna.

Una versión para durar

Todos estos cambios van enfocados a crear una versión estable que permanecerá sin cambios grandes durante una buena temporada. Hasta ahora cada relativamente pocos meses liberaba una nueva versión de WP Carousel, sin embargo quiero dejar esta política de lado para disponer de más tiempo para programar en Objective-C y aprender más y más.

Creo que con todas estas novedades WP Carousel se habrá convertido en un plugin digno de ser considerado versión 1.0 (a pesar de que la próxima versión será la 0.6). A lo largo de este año WP Carousel ha ido mejorando notablemente y sinceramente, me parece que he implementado todas las características que habéis ido pidiendo a lo largo del tiempo a excepción de aquellas que los medios técnicos no me permitían añadir.

Me alegra ver que ya se ha descargado más de 14000 veces y que la opinión de aquellos que lo prueban es muy buena. Cuando libere la próxima versión seguro que a muchos de los que no les acababa de gustar WP Carousel cambian de opinión, porque voy a implementar prácticamente todas las características que habéis pedido a lo largo de este año de vida del plugin. De hecho la única característica que no voy a implementar es la lista de categorías y de tags, una característica que tenía planeada para WP Carousel 0.5 pero que finalmente descarté debido a qué no encontré un modo sencillo de asignarle una imagen a una categoría o a una etiqueta.

De momento no he contestado aún a ningún email, sin embargo ya los he leído todos y la verdad es que hay bastantes reportando bugs y dando sugerencias. Por favor, evitad usar los emails para bugs y sugerencias, ya que no los voy a contestar. Hay un foro tanto en inglés como en español para estas cosas, donde es más cómodo seguir el tema, así que no hay ningún motivo para usar los emails. Además, algunos de los problemas que se han reportado por email ya estaban bien explicados en el foro y en la documentación. Antes de reportar un bug, dadle un repaso a la documentación.

Y esto es todo hasta finales de mes. ¡Nos vemos en dos semanitas!

También han mostrado el mismo problema de recepción en otros Smartphones de la competencia, aunque no me parece un buen argumento. Que la competencia tenga el mismo problema que tú no quiere decir que el problema no exista, sólo quiere decir que ambos erráis en lo mismo. Además no tienen en mente cambiar el diseño de la antena (al menos según se ha dicho en la rueda de prensa). De hecho Apple regalará uno de sus Bumpers a todos aquellos que hayan comprado un iPhone 4 (curiosamente ya había leído esta idea en los comentarios de varios blogs, ya que parece que con estos el problema se soluciona) y les devolverá el dinero a aquellos que ya lo hayan comprado (ojo, sólo si es un Bumper de Apple, no se devolverá el dinero de fundas de otras compañías), dejando siempre la opción de devolver el iPhone 4 por su importe original. Por lo que respecta a los problemas con el sensor de proximidad, parece ser que en una próxima versión de iOS (quizá la 4.1) el problema estará solucionado.

Por último, el iPhone 4 de color blanco estará a la venta a finales de mes y comenzará a venderse en España el viernes 30 de este mes.

Reutilizar código

Pongamos por caso que estamos escribiendo un blog y que tenemos hecho ya el diseño. Ahora insertamos una imagen y queremos darle un borde gris para que encaje al a perfección con nuestro diseño. ¿Qué hacemos: modificar el CSS de nuestro diseño o utilizar el atributo style? Es tarde, estamos cansados y al día siguiente tenemos que madrugar, así que tomamos la vía rápida y utilizamos style. Un par de semanas después no encontramos en la misma situación y hacemos lo mismo, y según avanza el tiempo cada vez se dan más ocasiones como ésta. Quizás aplicar un simple borde no sea nada del otro mundo, pero si en lugar de eso también aplicamos un margen, un relleno y un color de fondo, estamos duplicando un montón de código que no tendríamos por que repetir.

Separar el contenido del diseño

Supongamos que hemos hecho lo que comentaba en el punto anterior y que tenemos un montón de etiquetas con estilos heredados del atributo style. ¿Qué sucedería si cambiamos el diseño de la web? Pensemos en un blog con WordPress y en la cantidad de themes que hay disponibles. Quizá dentro de tres o cuatro meses queramos cambiar el diseño por uno nuevo, y al aplicarlo no encontraríamos con una desagradable sorpresa: los elementos que tienen estilos en la etiqueta style se ven como en el diseño anterior y quedan mal en el nuevo diseño. Ahora tendríamos que ir buscando uno a uno cada elemento que al que le hemos añadido estilos de este modo para cambiarlos por unos que queden mejor. Menuda faena, ¿no os parece?

Rediseñar de forma más rápida

Pensemos ahora que hemos sido nosotros los que hemos creado el diseño, y que lo hemos hecho utilizando el atributo style. Si nuestra web es dinámica, tan sólo tendremos que modificar algunos archivos, pero si la hemos hecho con archivos HTML sueltos, sin una Base de Datos que almacene el contenido, tendremos que modificar tantos archivos como contenido hayamos creado. Quizás 10 páginas no son muchas, pero por ejemplo este blog tiene ya más de 650 artículos, que serían más de 650 archivos a modificar… no quiero ni imaginármelo.

Tener un código limpio

Algunas de las cosas que nos pueden parecer extrañas al entrar en el mundo del código (sea el que sea) es que se tabula con muchísima frecuencia el código. ¿A qué se debe? A mejorar la legibilidad del mismo. Puede que tras hacer un diseño o crear un programa recordemos a la perfección en qué línea estaba cada cosa y dónde comenzaba y acababa cada etiqueta (o condición, o bucle o…). ¿Nos acordaremos dentro de dos meses? ¿Y dentro de dos años? ¿Y aquellos que sólo miren el código para aprender podrán entender algo? Tener un código limpio es muy importante para poder mantener un proyecto, sea código CSS, PHP, C++… Tabular el código es una forma de mantenerlo limpio, y añadir estilos con el atributo style es una forma de ensuciarlo.

Mirad el siguiente código:

<div class="nota"><p>Hola mundo</p></div>

Y ahora mirad este otro:

<div style="background:#000 url(img/fondo_nota.png) top left no-repeat; border:1px solid #CCC; padding: 10px 5px 7px 3px; margin:2px 5px 6px 1px; float right; display:block; position:relative; top: -20px; left:50px;"><p>Hola mundo</p></div>

En ambos el contenido que se muestra es el mismo. ¿En cuál os ha costado más encontrar la frase que verá el visitante? Este es un ejemplo de a lo que me refiero con limpieza de código.

Selectores más avanzados

Hasta ahora todo lo que habíamos visto que nos permitía hacer CSS también podíamos hacerlo con el atributo style, pero no es así, CSS nos permite hacer más cosas. Pensemos por ejemplo en que queremos que un link cambie de color al pasar el cursor sobre él. Con CSS lo tenemos realmente fácil:

a:hover { color:#CCC; }

Sin embargo hacer esto con el atributo style no es posible. Puede que cambiar el color de un enlace no os parezca demasiado útil, pero imaginad ahora que queréis hacer un menú desplegable sin usar Javascript. Con CSS es realmente fácil de hacer, pero ¿y con el atributo style? Simplemente no se puede hacer.

Selectores “a secas”

Ahora pongamos el caso de que queremos usar Javascript para añadir algún efecto o para hacer que al hacer clic sobre cierto elemento se muestre otro elemento oculto. Usando el atributo ID o class de cualquier etiqueta HTML podemos detectar con Javascript no intrusivo cuándo se hace clic, sin embargo si no usamos estos atributos no podemos detectar cuándo se pulsa cierto elemento sin recurrir a métodos no recomendados para la accesbilida del sitio web. Además, tanto al atributo ID como el atributo class se pueden usar para darles estilos a los elementos de la web, así que ganamos en Javascript no intrusivo y en CSS.

Carga más rápida

Toda esta limpieza y reutilización de código contribuyen a que la página cargue más rápido, ya que hay un total de menos código, los archivos tienen un menor tamaño y la descarga de los mismos dura menos tiempo. Además al reducir el tamaño también reducimos el ancho de banda que consume cada visita, con lo cual también podemos ahorrar algo más en temas de alojamiento y servidor.

Un diseño para cada ocasión

Otra ventaja del CSS es que podemos cambiar el archivo por otro y modificar totalmente el aspecto de la web sin tocar el contenido. El mejor ejemplo de esto mismo es CSS Zen Garden, una página que tiene siempre el mismo código HTML y que sólo cambia el archvo CSS que se carga. Quizá parezca una tontería, pero en muchas ocasiones es necesario cargar un archivo CSS específico para cierto navegador o un archivos CSS diferente para dispositivos móbiles o para una versión para imprimir.

Las tablas para tabular

Y aquí es donde entran las tablas. Sin duda es muy fácil convertir una tabla en un rectángulo con esquinas curvas o un diseño a tres columnas, pero ¿se crearon para eso? No, el objetivo de las tablas es mostrar contenido tabulado, tarea que desempeñan la mar de bien. Pensemos que usamos tablas para el diseño de un blog en tres columnas. Ponemos una sidebar a cada lado y el contenido del blog en la columna central. Ahora imaginemos que queremos las dos sidebars a la derecha o ambas a la izquierda. Habría que modificar sí o sí el código HTML ya que no hay forma de alterar la posición de las columnas mediante CSS. Sin embargo usando capas (div) y CSS se podrían hacer las tres columnas sin problemas y más adelante cambiar su disposición modificando sólo el código CSS. Pensemos de nuevo en CSS Zen Garden. Si usara tablas, sería imposible que cambiase tanto la disposición del contenido al modificar el CSS.

Y a todo esto, ¿qué pasa con los estándares?

No es mi intención hablar de los estándares en este artículo, pero algo comentaré. Actualmente seguir los estándares y comprobar que el código es válido tiene algunas ventajas. La primera es que te ahorras posibles problemas al dejar etiquetas sin cerrar o al olvidar alguna comillas (“) o similares. Algunos navegadores pueden mostrar correctamente un diseño con este tipo de errores mientras que otros no. Siguiendo los estándares te ahorras estos problemas. Además los estándares te ofrecen un buen punto de partida para que el diseño se vea correctamente en cualquier navegador. Está claro que todo acaba dependiendo del motor de renderizado del navegador, pero si el navegador en cuestión utiliza un buen motor de renderizado, la página se verá perfectamente, mientras que si se recurre a código no estándar y que sólo funciona en determinado navegador, el página no se verá correctamente en todos lo demás. Los estándares no limitan lo que podemos hacer, simplemente nos proponen (ya que no es obligatorio, sino recomendable) un modo de hacerlo para que todos lo hagamos igual y los navegadores sean capaces de mostrar correctamente todo el contenido. Siempre debe haber un estándar, sino, cada navegador interpretaría el código de una forma diferente (algo que lamentablemente, a pesar de los estándares, sucede). ¿A que a nadie se le ocurriría utilizar la etiqueta <span> como <div> o como <p>? ¿Entonces por qué aún hay quién utiliza la etiqueta <table> como <div>? ¿Qué debe interpretar el navegador: esa tabla es sólo para estructura del contenido o es (como dice el estándar) para mostrar contenido tabulado?

En cuanto a los títulos, les he cambiado la tipografía para que destaquen algo más, y he actualizado las páginas de archivo y de resultados de búsqueda para solucionar algunos problemas que tenían, como por ejemplo, algunos descuadres con la etiqueta que contiene la fecha o la falta de la barra de permalinks y comentarios.

Por último he modificado también las galerías para que en lugar de enlazar a la imagen en tamaño reducido ahora enlacen a la imagen en tamaño completo. Tampoco son grandes cambios, y como podéis comprobar, están pensados princpalmente para mejorar la legibilidad de los artículos del blog.

$wp_query es un objeto que contiene diversos métodos (funciones) y atributos (variables) acerca de las consultas a la Base de Datos (realmente contiene mucha información). Entre estos atributos hay dos que son los que utilizaremos y que nos facilitan mucho la tarea, se trata de: current_post y post_count. El primero indica cuál es la iteración (repetición) actual del bucle, mientras que el segundo indica el total de artículos que se mostrarán. Es decir, el primero nos dice cuántos artículos se han mostrado ya y el segundo nos indica el total de veces que se ejecutará el bucle.

Con ambos datos tenemos suficiente como para saber cuándo se está mostrando el primer y el último artículo. Lo único que tenemos que tener en cuenta es que current_post comienza en 0, mientras que post_count es el total de artículos que se mostrarán (partiendo de 1). Esto quiere decir que si vamos a mostrar 10 artículos en el bucle, al mostrarse el último artículo el atributo current_post valdrá 9, mientras que el atributo post_count valdrá 10.

A continuación os dejo un bucle de ejemplo para que entendáis mejor lo que quiero decir:

if (have_posts()): while (have_posts()): the_post();

if ($wp_query->current_post == 0)
{
echo 'Este es el primer artículo del bucle';
}

if (($wp_query->current_post + 1) == $wp_query->post_count)
{
echo 'Este es el último artículo del bucle';
}

if ($wp_query->current_post > 0)
{
echo 'Este no es el primer artículo del bucle';
}

if (($wp_query->current_post + 1)  < $wp_query->post_count)
{
echo 'Este no es el último artículo del bucle';
}

if (($wp_query->current_post > 0) && (($wp_query->current_post + 1)  < $wp_query->post_count))
{
echo 'Este no es ni el primer artículo del bucle ni el último';
}

endwhile; endif;

Realmente no tiene mucha complicación y facilita bastante el detectar cuándo se muestra el primer o el último artículo.

Haz clic aquí para ver el vídeo

Por lo que respecta a las demás novedades de esta versión, tenemos cambios en las barras que indican la cobertura del iPhone, se ha rediseñado por completo el Game Center,  se han añadido algunas opciones como deshabilitar FaceTime y el modo multijugador de Game Center para los menores de edad y la posiblidad de desactivar el corrector ortográfico. También parece que se ha mejorado la velocidad en el iPhone 3G, aunque todo esto son recopilatorios de novedades publicadas en foros y blogs, así que no he podido comprobarlo realmente.

Este nuevo filtro está definido en el archivo wp-includes/default-filters.php (sobre la línea 90):

// Format WordPress
foreach ( array( 'the_content', 'the_title', 'comment_text' ) as $filter )
	add_filter( $filter, 'capital_P_dangit' );

La función capital_P_dangit() en cuestión está en el archivo  wp-includes/formatting.php (sobre la línea 2828):

/**
 * Forever eliminate "Wordpress" from the planet (or at least the little bit we can influence).
 *
 * Violating our coding standards for a good function name.
 *
 * @since 3.0.0
 */
function capital_P_dangit( $text ) {
       return str_replace( 'Wordpress', 'WordPress', $text );
}

Como podéis ver, la función reemplaza cualquier aparición de “Wordpress” por “WordPress“, dando igual que esté en la URL de una imagen o de un enlace, en una cita, en parte de un código (en PHP la variable $Wordpress y $WordPress son variables distintas), lo que puede hacer que algunos ejemplos de código estén mal.

Eliminar el filtro es muy sencillo, basta con añadir al archivo functions.php de nuestro theme (o crear un plugin con el siguiente código):

foreach ( array( 'the_content', 'the_title', 'comment_text' ) as $filter )
	remove_filter( $filter, 'capital_P_dangit' );

Con esto el filtro queda eliminado y volvemos a tener la libertad de escribir WordPress como nos plazca. Yo por mi parte ya he eliminado el filtro en Sumolari.com.