Sobre los nuevos formatos de posts de WordPress

WordPress sigue avanzando y agregando funcionalidad. Una de las últimas cosas que fueron agregadas a WordPress fueron los formatos de posts. Un tema que prometía y dio mucho de qué hablar. Sin embargo, cada quien tenía sus propias expectativas al respecto y hubo quienes quedaron disconforme y quienes también quedaron disconformes pero por razones completamente distintas (y aquellos que nos pareció fantástico). Tanto revuelo se armó que uno de los desarrolladores de WordPress publicó el artículo que traduzco a continuación, una explicación de qué son realmente los formatos de posts y porqué son lo que son.

Notas

  • Artículo original: On Standardized Post Formats
  • Autor original: Andrew Nacin
  • No traduzco la palabra theme, estoy demasiado acostumbrado a usarla así como está
  • Todos los links dentro de la traducción llevan a artículos en inglés

La traducción

Hace unos meses, cuando la comunidad empezó a hablar de WordPress 3.1 y los nuevos “Formatos de Post”, hubo un poco de controversia sobre cómo los desarrolladores interpretaron y decidieron implementar la funcionalidad. Me pasé la mayor parte del día en Twitter haciendo un poco de control de daños.

Al final del día pude decirle a varios detractores que iba a dedicarle un tiempo a tomar lo que pienso – comunicado en pedazos de 140 caracteres o menos a lo largo del día – en un post. Nunca lo hice.

Por un tiempo, creí que no iba a ser necesario. Pero, a medida que WordPress 3.1 se acerca a ser lanzado, me doy cuenta que no comunicar el verdadero propósito de esta funcionalidad va a ser una gran responsabilidad del grupo de desarrolladores… y mía por prometer una explicación.

Acabo de comentar en un post al respecto. Tuve que decirle al autor que no él terminaba de entender el verdadero sentido de la funcionalidad – y me sentí responsable.

Así que acá está nuestra versión sobre lo que son y lo que no son los formatos de post, y porqué son lo que son.

Originalmente, toda la funcionalidad era una sola página en el Codex

No había código. Simplemente iba a definir un estándar: el nombre de una taxonomía, y un conjunto estandarizado de formatos. Cualquier theme que deseara aprovecharse de los formatos de posts tendría que registrar la taxonomía al final. Un blogger podría alternar entre themes que soportaran formatos de posts sin problemas. Parece sencillo ¿no?

Ni tanto. La estandarización en este tema sería muy complicado. Dejando de lado la forma en la que un theme lo implemente, había un problema muy serio: la disponibilidad del término o URI en una instalación particular. Porque los términos son compartidos por todas las taxonomías, una etiqueta “galería” interferiría con el formato de post gallery, haciendo que éste sea gallery-2. Esto no funciona, va en contra del propósito de crear un estándar. Decidimos que se necesita un espacio de nombre para que sea lo más portable posible: tras bambalinas, por ejemplo, se utiliza post-format-gallery.

Así que en lugar de simplemente implementar la página del Codex, nos dedicamos a escribir código – siempre lo mínimo posible. La implementación actual de los formatos de post es bastante escueta. Es una taxonomía particular, con una caja de administración propia – dos cosas que bien podría hacer y aprovechar cualquier theme por sí mismo. Utiliza APIs que han existido desde WordpPress 2.5. Con todas las cosas que agregamos en cada versión, el propósito de esta funcionalidad tiene poco que ver con el código. Literalmente no se agregó nada que un theme o plugin no pudiera hacer hace bastante tiempo.

Lo que nos vuelve al propósito de la funcionalidad

Con los nombres de los términos, nos esforzamos en asegurar que los formatos sean tan portables como fuera posible. La idea detrás de la funcionalidad es la estandarización y portabilidad para un segmento de bloggers. Muchos diseñadores de themes utilizados para microblogging querían esta habilidad para ofrecer contenido bien definido y estructurado más allá de lo que se podía hacer con etiquetas y categorías. Está diseñada para que al cambiar de theme – un tipo específico de theme hay que aclarar – el contenido no pierda su contexto más fundamental.

La funcionalidad no es para todos

No espero que todos los themes lo utilicen. Francamente, no son siempre útiles – apuntan a cubrir un rol específico. Una cantidad de themes y compañías desarrolladoras de themes van a verse muy beneficiadas por esto. Implementaciones particulares no, y esa es la idea.

Muchos sugirieron que la “forma de WordPress” establecería un estándar, pero también permitiría a los themes y plugins adherirse y agregar sus propios formatos de posts. Al final de cuentas, esta funcionalidad es una excepción a esa regla. No es que simplemente nos gustó la idea de los formatos de posts y luego se nos ocurrió que fuese estándares. No, la idea desde la que partimos – antes que siquiera tengamos un nombre para ella – fue la estandarización en sí misma. Lo único nuevo que trae esta funcionalidad es la portabilidad a través de la estandarización. Sin eso, la funcionalidad no sirve para nada.

Si necesitás, formatos propios, probablemente no deberías usar formatos de posts

Esto es lo mejor: no se pierde nada. Si querés hacer una implementación propia, entonces podés hacerlo con una taxonomía propia. Puede parecer enorme, pero no lo es. Es lo mismo que hubieses hecho en 3.0 con una implementación propia: una docena de líneas de código para registrar una taxonomía propia y una caja de administración. Luego podés utilizar las clases en los posts y los tags en el theme para darle estilo a los posts.

Así que si estás desarrollando un theme para microblogging y querés aprovechar los formatos de posts estás más que bienvenido a hacerlo. Si querés un desafío, crea tu propia caja de administración, agrega íconos a cada formato y todo lo que quieras para satisfacer ese nicho. No hay requerimientos para adherirse a nuestra interfaz; eso es sólo para comenzar. Realmente quiero impulsar algo de creatividad en este espacio.

Si vas a hacer una implementación propia o un theme especial y necesitás de algo parecido a los formatos de posts, entonces hacelo de la forma que lo hubieses hecho en WordPress 3.0: registrá una taxonomía. Si, realmente es así de simple.

Si tenés algún comentario o idea, dejá un comentario

Vamos a hacer lo posible para tenerlo en cuenta. Estoy seguro que quedan esquinas por pulir y quiero que nos entendamos, aún cuando no haya consenso.


Algunos pensamientos más y lecturas sugeridas: mi colega Otto Wood ya escribió al respecto en “Tipos de post y formatos y taxonomías, ¡oh!, que hace un gran trabajo dando el punto de vista del usuario.

También me han preguntado varias veces si los formatos de posts o los tipos de posts propios tienen sentido para un proyecto dado. Mi respuesta es bastante directa: si no estás seguro cuál te conviene, probablemente estés cambiando el propósito de alguna. El post de Otto cubre eso, y posiblemente quieras leer el post de Mark Jaquith: Formatos de Posts versus Tipos de Post Propios.

¿Hay fallas? Sí. Hay un par de factores confusos. Primero, como sugiere Mark, “tipo de post propio” es un nombre horrible para lo que realmente es. Irónicamente, el mejor nombre para los “formatos de posts” (créanme que gastamos nuestros diccionarios para esto) hubiese sido “tipos de post”. Y luego está la confusión donde algunos hubiesen utilizado “formatos de posts propios” aún cuando no están hablando de nada único – probablemente dada la confusión acerca del término similar “tipos de posts propios”.

Para finalizar, acerca del soporte de formatos de posts en Twenty Ten (el theme por defecto de WordPress): a nivel de theme, tiene perfecto sentido. Twenty Ten ya soporta estilos especiales para los apartados y las galerías, los que (juntos con el theme P2) fueron precursores naturales de los formatos de posts. En el contexto de una instalación estándar de WordPress, ahora tenés categorías, etiquetas y formatos de posts. Puede ser demasiado. Con suerte, los usuarios van a descubrir la pestaña de Ayuda (algo que deberíamos de resaltar para nuevos usuarios). I también pienso que ayuda uno de mis mejoras favoritas de 3.1: ocultar por defecto la mayoría de las cajas de administración en la pantalla de escribir post.