Así que se me ocurrió que no era necesario para nada escribir el código “a mano” en el post (lo cual apesta) sino que es más fácil subirlo WordPress, adjuntarlo al post y luego usar un plugin para colorear el código. Y aqui les presento éste plugin.

Bueno, lo presento despues del salto.

CodeHere funciona de esta manera:

1. Instalas el plugin.


2. Creas tu código de ejemplo en un archivo en tu editor de código favorito.


3. Lo adjuntas a tu post usando el dialogo “Upload/Insert” (el mismo que usas para adjuntar fotos) pero no insertas nada, solo copias el nombre del archivo.


4. Lo insertas en tu post mediante un sencillo shortcode: [codehere].

Así que suponiendo que subes un archivo llamado html5.html, lo insertarás en tú codigo escribiendo lo siguiente

Y el resultado será el siguiente:

[codehere html5.html lang=html]

Puedes tambien hacerlo mismo con css

Y hasta ruby

En este último caso, WordPress no permite subir archivos con extensión .rb (imagino que por cuestiones de seguridad) en este caso, el archivo tiene una extensión .rb.txt pero la parte de txt la ignoraremos en nuestro código.

El plugin está alojado en GitHub y pueden descrgarlo la última versión desde aquí.

Si les es de utilidad alguna, un enlace siempre se agradece.

Al contrario, un sitio tiene que estar siendo optimizado constantemente, ajustado a las necesidades de sus usuarios, midiendo cada vez cambio y viendo qué da mejores resultados.

¿Tu tema es lo suficientemente ágil como para adaptarse fácilmente? Aqui te propongo 5 ideas para ayudarte a que lo sea.

1. Utiliza la API de widgets de WordPress para hacer tu tema más flexible.

Aunque originalmente fueron pensados para poner cositas en la barra lateral de tu blog (¡internamente se les siguen llamando sidebars!), la API de widgets de WordPress es sumamente poderosa y permite atacar el diseño de tu sitio desde una perspectiva modular.

En un principio, a algunos les parecerá demasiado engorroso hacer 3 o 4 pasos para crear areas widgetizadas en sus temas en vez. Pero a largo plazo, esta flexibilidad otorga beneficios tangibles, como la posibilidad de iterar el diseño de un sitio de una forma ágil, cambiando y moviendo contenido de un modulo a otro sin necesidad de tocar una sola línea de código.

2. Separa el contenido de la presentación.

Este suena como un consejo tonto que se da por hecho en 2010, pero la verdad es que hay una gran cantidad de diseñadores de temas que siguen mezclando su HTML, PHP y CSS lo que crea una gran variedad de problemas a la hora de hacer cambios y actualizaciones a un sitio.

Si tu ya lo haces, te propongo llevar esta idea un poco más allá: no solo separar el contenido y la presentación, sino dividir la presentación en varias capas de una manera ordenada, por ejemplo: layout, tipografía, colores y fondos. Esto haría más simple que en un futuro alguien quisiera hacer cambios simples al CSS sin miedo a romperlo todo.

3. Organiza tu código de una forma modular.

El peor y más inmantenible código que he visto en mi vida lo he visto en temas y plugins de WordPress, donde se dan los más enredados espaghettis de código embebidos todos en un solo archivo. Para un tema simple, de un tipico blog, no existe mucho problema, pero cuando quieres hacer sitios con funcionalidades más complicadas es buena idea empezar a pensar en a modularidad.

Un ideal sería separarlo todo conforme al paradiga MVC, donde el acceso a los datos, la lógica del tema y las vistas estuviera todo separado, pero puedes empezar por crear plantillas para cada tipo de post, una cosa que WordPress permite de fábrica.

Por ejemplo, en lugar de tener solo un index.php lleno de condicionales tipo if (is_page()) { ... } crea home.php para la página de inicio, single.php para posts individuales, page.php para páginas, etc.

Si quieres saber como funciona la jerarquía de páginas en WordPress, mira este diagrama.

4. Presenta un panel de opciones.

No es cosa fácil hacer un panel de configuración en WordPress por eso casi siempre preferimos asumir algunas cosas y escribirlas directamente en el código. Sin embargo, la posibilidad de hacer pequeños cambios y medir su eficacia con solo mover opciones en un panel de la administración de WP es un alivio.

De lo que se trata no es de llenar este panel con miles de opciones, sino dejar algunas pocas opciones importantes para que el usuario pueda modificar su tema sin saber la diferencia entre PHP y HP. Por ejemplo, puedes permitirle elegir que enlaces aparecerán en su navegación, la imagen del encabezado, el ancho de las columnas y el mensaje del footer.

5. No olvides los hooks.

Junto con los widgets y el panel de opciones esta es la tercera pieza clave para que los usuarios puedan modificar su tema sin necesidad de modificar ningún código. Afortunadamente no hace falta incluir cada feature posible en tu tema puesto que lo maravilloso (y atemorizante) de WordPress reside en el enorme ecosistema de plugins gratuitos y premium disponibles.

Pero para que la mayoría de estos plugins puedan funcionar, el tema necesita incluír algunos hooks que permitirán a estos plugins engancharse y ampliar sus funcionalidades. Aquí está la lista de estos enganches, para que no olvides colocarlos en tu próximo tema.

O puedes tomar el camino fácil y usar un framework

Muchas de estas ideas fueron la base para crear DTE, el framework para programar temas avanzados—y ágiles—de WordPress de una forma simple y rápida.

Obviamente yo recomiendo DTE, pero usar algo más simple como Thematic o Hybrid puede ser una opción perfectamente válida.

Hay una cosa que odio: mezclar bloques de PHP con bloques de HTML. Será que CakePHP me ha mal acostumbrado a tener separadas las vistas de la lógica, pero de verdad me molesta código que se ve así (tomado del tema default de WordPress):

No se a ustedes, pero a mí tanto <? ?> me marea y luego se me hace muy dificil entender donde empieza y donde termina un bloque. Desgraciadamente éste tipo de programación es muy común en el mundo de WordPress, algunos pupulares temas y plugins son verdaderos spaghettis indescifrables, y esto es en cierta manera porque asi es la manera en que WP está escrito.

CakePHP, por otra parte, tiene una solución interesante para este problema (en realidad, creo que es una solución para un problema distinto, pero denme chance) en la forma del HTMLHelper, pero para tags complicados y con muchos atributos, el código se vuelve demasiado y a mi siempre me cuesta recordar el orden de los parametros.

Cuando decidí aventarme a crear temas premium para WP, una solución para éste problema fue una de las principales razones para escribir el Duperrific Theme Engine de donde finalmente extraigo lo que ahora les presento como CSML.

Ejemplo:

Como verás csml::tag() toma un selector como parametro y regresa un tag de HTML, mientras que csml::entag() toma una cadena y la envuelve con el selector designado en el segundo parametro. En el caso de csml::entag() el segundo parametro tambien puede ser un array de selectores, lo que hará que anide los selectores uno dentro de otro, empezando por el último selector del array.

Aunque la forma más facil de utilizar csml, es usando las dos funciones incluídas: t() y en() que son wrappers para csml::tag() y csml::entag() respectivamente y además imprimen el tag.

Un ejemplo más de la vida real:

Apenas estoy empezando en esto de liberar cosas que he hecho, así que espero que les resulte tan útil como a mí me ha resultado. Si la usan me avisan y si encuentran algún bug me dicen o, mejor aún, forkean el proyecto y lo arreglan.

La primera cosa que noté en los temas que se venden como premium en el mercado es al parecer su enfoque es muy estrecho. Pareciera que su único objetivo es verse muy bien y ser muy atractivo para el usuario final o lector del sitio y dejan de lado a los otros roles que intervienen en un sitio web: desarrolladores, diseñadores y editores o colaboradores, dándoles poca o ninguna importancia.

Con esto en mente me puse una serie de reglas o lineamientos que tenía que seguir a la hora de desarrollar mis temas, con la premisa de que no liberaría nada hasta que pudiera satisfacer todas ellas. Este es el Duperrific Manifesto:

1. La usabilidad es primero, la apariencia viene después. Antes de comenzar hay que tener nuestras prioridades en su lugar.


2. Ofrecer soluciones completas y en paquete. Mi cliente no tiene porque buscar entre miles de plugins para ver cual satisface sus necesidades, todo lo que necesita viene empaquetado en su descarga.


3. Ofrecer un verdadero framework de desarrollo. Donde al igual que en todos los frameworks que se respetan: “Convención sobre configuración” es la frase clave.


4. Escribir código extensible y reutilizable. ¿Por qué repetir código?


5. Programar Orientado a Objetos. Tanto como WP, que es casi completamente funcional lo permita.


6. Los temas deben ser absoloutamente flexibles. Los widgets, son una poderosa característica que WordPress trae de fábrica y que aún no se ha aprovechado cual debe ser.


7. Configurar el sitio debe ser sencillo.  El diseñador no tiene por que editar una línea de código. WP nos permite añadir nuevos paneles de control a la administración del sitio, démosle buen uso.


8. Crear contenido debe ser simple. Por lo tanto, las funcionalidades avanzadas de nuestros temas deben ser abstraídas. Los editores no tienen por que saber qué es un campo personalizado para meterle una foto a un artículo.

Estuve meditando mucho al respecto, estudiando las propuestas del mercado y comparándolas con necesidades reales que me he topado en estos 5 años que llevo desarrollando para la web y estas son mis conclusiones.

Las Necesidades de Los Diferentes Roles Usuario

Personalmente, identifiqué 4 roles que tienen parte en un sitio powered by wp y deben ser tomados en cuenta: El Programador, El Diseñador, El Editor y El Usuario Final. Nótese que hablo de roles y no de personas puesto que a menudo una sola persona desempeña más de un papel o es un equipo completo el que se dedica a cierta tarea.

El Programador es el que entiende bien –o más o menos bien– el código que hace funcionar a WordPress y realiza temas o plugins que se adapten a las necesidades de su cliente o de su usuario final.

Los mejores programadores se preocupan por un código limpio, ordenado y bien documentado y están dispuestos a seguir convenciones que refuercen la limpieza y confiabilidad, así como la reusabilidad de su código.

Por alguna razón ésta no parece ser una cultura extendida en el mundo de WordPress y una gran mayoría de los temas y plugins existentes parecen más que fueron hackeados al paso que desarrollados con los estándares arriba descritos. Quizá solo sea que despues de pasar mucho tiempo en los mundos de CakePHP, jQuery, RoR y Cappuccino me volví quisquilloso.

Al Diseñador le toca la parte que se ve y la que le da la cara al usuario final. Aunque para que un diseñador web sea más completo es bueno que sepa HTML, CSS y hasta PHP o JavaScript estas deben ser entendidas como habilidades accesorias o plus pero que no forman parte del quehacer propio de un diseñador.

Idealmente el diseñador debería estar preocupado por el branding, por la legibilidad, por comunicar y resolver problemas gráficamente y debería poder lograrlo de forma intuitiva y gráfica sin necesidad de andar desenredando loops anidados.

Desgraciadamente poco desarrolladores de temas para WP toman en cuenta al diseñador de a pie y hacen que implementar un diseño a partir de un tema sea una labor tediosa y estresante.

Para El Editor, que es la persona encargada de meterle el contenido al sitio las cosas están fáciles si el sitio se trata de un blog convencional porque, seamos sinceros, para eso fue diseñado WordPress. Si queremos algo más, así sea una modificación tan cercana como una revista electrónica en lugar de un blog entonces las cosas comienzan a ponerse feas.

Imaginate explicarle al editor que en ocasiones un post no es un post sino que puede ser un producto o una fotografía depende de en que categoría lo coloque. Que a veces el campo “excerpt” es para poner un teaser del post pero en otras ocasiones se trata del pie de página de una foto. Que por cierto la foto debes recortarla en 3 diferentes tamaños y luego subirla, copiar la url y pegarla en un custom field que debe llevar un nombre determinado.

Y para el Usuario Final o lector o cómo uno quiera llamarle, todo debe ser transparente y fácil de usar. Hace poco escuchaba una entrevista con Irene Rosenfeld, CEO de Kraft Foods donde decía que al vender comida el factor decisivo es que ésta tenga buen sabor.

Con los sitios web sucede algo parecido, el factor decisivo es que al usuario final le sea útil, sin este factor, lo demás no sirve de nada.

Resolviendo Necesidades

En los últimos dos meses he estado experimentando y probando diferentes maneras de resolver los problemas que he planteado en éste post y me siento confiado en que encontré la mejor manera de resolverlas.

En una siguiente entrefa les platicaré mi approach y como estoy resolviendo estos problemas en mi propia linea de premium themes que voy a lanzar muy, muy pronto

Si piensan que estoy completamente equivocado, ya saben “cómo decirmelo”#respond

Para quien no lo sepa, los temas premium son temas que ofrecen características adicionales a los temas tradicionales que solo modifican la apariencia de nuestro blog.

Los premium, que por lo general son de paga, casi siempre buscan transformar nuestra instalación de WP en mucho más que un simple blog. Los hay para una gran variedad de aplicaciones y en determinados proyectos podrían ser la solución perfecta para el presupuesto apretado.

En mi investigación, he visto que existen basicamente dos corrientes dentro de los temas premium: Primero están los que son súper flexibles y súper genéricos como Thesis o WPRemix que son más un framework para construír tu sitio que una solución lista para usarse. Tambien suelen ser los más caros.

Luego están los temas que son más específicos, como los que hacen los de WooThemes que bien pueden usarse tal cual, poniendo solamente el logo de nuestro cliente (Eso no significa que no puedan modificarse ad nauseam, para muestra vean el showcase de freshnews).

¿Si ustedes fueran a usar un tema de paga para algun proyecto que preferirían? ¿Un theme-framework súper flexible, uno listo-para-usarse o una mezcla entre estos dos conceptos?

Ojala me puedan ayudar contestando en los comentarios. Puede que vengan algunos temas premium marca soska en camino y sus opiniones serán invaluables.

WordPress 2.7