Cómo crear un tema de WordPress

El pasado sábado 13 de abril tuve la ocasión de dar una charla de hora y media en la WordCamp Bilbao 2017 sobre creación de temas de WordPress. Fue una charla aunque debía ser un taller. Y fue de creación de temas aunque debía ser «De PSD a WP».

El problema que tenía compartir información sobre este tema es que es tan amplio que es imposible condensar tanto sin que la gente se aburra y que todo el mundo salga contento. Con cada persona que hablaba antes de la charla me contaba una cosa diferente que esperaba («montarás una web desde cero«, «nos enseñarás cómo recortar las imágenes en Photoshop«, «hablarás sobre los logos en SVG«, «enseñarás a utilizar template-parts«, «¿hablarás de Underscores, no?«, etc…). Esto unido a que era un «taller» en el que nadie llevaba portátil con lo que iba a ser yo simplemente haciendo cosas, hizo que decidiera tirar por la calle de en medio y dar una serie de pinceladas sobre todo el proceso de diseño y desarrollo de un tema en 2017. Y prometí un post en el blog con la información más ampliada y más ejemplos… y en ello estamos.

Un clásico que se resiste a desaparecer…

La primera charla sobre cómo pasar de un diseño en un archivo de Photoshop a un tema de WordPress se debió de dar al día después de implementar los temas en el core… Pero aún hay mucha gente interesada en el tema y es que algunos, entre los que me incluyo, siguen ganándose la vida con esto.

…pero muchas cosas han cambiado

El problema es que las cosas que se hacían y se recomendaban en 2010, en 2012, en 2014… ya no valen. Si tú ves una charla de entonces, algunos de los básicos se mantienen, pero hay muchas otras cosas que han quedado obsoletas. El objetivo de este artículo es tener una visión mucho más actual de cómo se mueve el mundo del desarrollo web en esta parcela tan específica como son los temas personalizados de WordPress.

¿Cómo debe ser un diseño en 2017?

Lejos quedaron los tiempos de las páginas web con una imagen al pie que decía «Optimizado para Internet Explorer y una resolución de pantalla de 800×600«. A día de hoy tenemos que estar pendientes de 800 dispositivos diferentes y 600 resoluciones o más. Todos entendemos que para los diseñadores esto es un fastidio. Hemos pasado de que hicieran sus diseños en un archivo de Photoshop de 960 píxeles de ancho, a uno de algo más de 1000px y ahora… ahora la locura. Sobre todo para los que vienen de un mundo gráfico donde todo es perfecto al nivel de píxel y se encuentran con este panorama.

Formatos, programas y consejos

Cuando los diseños eran totalmente fijos, poca gente dudaba que el formato correcto para hacer una web era .psd. Pero al igual que los tiempos han cambiado a nivel de dispositivos, también lo están haciendo las herramientas. Ahora mismo cada agencia y cada diseñador es un mundo, los hay que siguen trabajando con Adobe Photoshop, los hay que trabajan con Adobe InDesign, con Adobe Illustrator, con los que te exportan un archivo .pdf y los hay que utilizan Sketch.

Yo, aunque me he especializado en el desarrollo de temas, aún hago diseños para pequeños proyectos o páginas personales y reconozco que me he pasado a Sketch. En primer lugar, por tema de licencias. Porque claro, a nadie se le ocurriría tener una suite de Adobe pirata, ¿verdad? ¿verdad? Por eso, para evitarnos malos mayores, hablé de Sketch como herramienta para diseñar… por eso y porque es una pasada, la verdad.

Sketch es una herramienta para Mac (pero qué diseñador no usa Mac en este mundo -aparte de la persona con la que yo trabajo normalmente-) cuya licencia vale 99 dólares. Lo instalas, lo abres, creas un nuevo documento desde la plantilla web y voilá! Tienes cuatro artboards para móvil, tablet, desktop y desktop (HD). Aparte de una fantástica explicación sobre cómo crear símbolos y estilos de texto, que permiten tener una página aparte con todas las cosas que luego vas a ir reutilizando a modo de guía de estilo.

No voy a entrar al detalle en cómo usar Sketch para crear una web, pero hay multitud de tutoriales interesantes con ejemplos para que os hagáis una idea de la potencia y la facilidad de la herramienta, por ejemplo Using Sketch to Design Beautiful Responsive WordPress Websites o Using Sketch For Responsive Web Design (A Case Study).

Además, otra de las ventajas que tiene es la cantidad de plugins interesantes que se pueden instalar al programa para hacer aún más cosas. Seguro que en este artículo encontráis algún plugin gratuito interesante: 30 free Sketch plugins to grab right now.

Como nota final a este apartado, quise saber cómo estaban trabajando ahora mismo alguna de las personas más relevantes de la comunidad de diseño de WordPress y le pregunté a Mel Choyce, diseñadora del tema por defecto de la última versión de WP, el Twenty Seventeen. Aparte de recomendarme Sketch, me comentó que había una herramienta, Zeplin, que facilitaba el trabajo una barbaridad a diseñadores y desarrolladores.

Con Zeplin puedes importar tu archivo de Sketch (y para Photoshop están en beta) y automáticamente te genera las imágenes exportadas a los tamaños necesarios, un listado de colores y tipografías que se han utilizado y te lo deja todo bien ordenadito para que el desarrollador no tenga que volverse loco recortando al píxel cada imagen del archivo.

¿Cómo debe ser el trato diseñador/desarrollador?

Lo de tener los archivos todos bien colocaditos está muy bien, ninguno lo vamos a negar, pero si luego no sabemos dónde ha decidido guardarlos el diseñador o qué demonios estaba pensando que iba a pasar cuando pulsásemos sobre cierto botón de la web, estamos perdidos. Por eso creo necesario hacer un inciso para tratar sobre la relación entre estos dos mundos.

Mi principal consejo es que intentemos aprender lo básico del trabajo del otro. Lo básico. No hace falta que un desarrollador sea capaz de diferenciar cien tipos de gris ni que un diseñador se ponga a crear funciones para modificar el loop de WordPress. Pero sí que hace falta que un desarrollador comprenda por qué los elementos de una web tienen su alineación, su espaciado y sus colores. Y que un diseñador entienda que no todo es posible con HTML, CSS y JavaScript. O que puede que sea posible pero no recomendable por otros motivos. También es importante escuchar al otro, porque es la mejor oportunidad que vas a tener para aprender.

Aparte de esto, es fundamental definir qué herramienta de comunicación se va a utilizar durante el proyecto. No queréis tener la información repartida entre dos correos electrónicos, un WhatsApp, un Trello, el Hangouts, un par de Skypes, un canal de Slack, un bot de Telegram, tres tableros de Trello y con archivos en Dropbox, Drive y WeTransfer. El tiempo es oro y definir de inicio cómo no lo vamos a perder es básico. Ya sean comunicaciones o las imágenes con los mockups, es mejor saber cómo se van a compartir de inicio.

Y, para evitar frustraciones futuras, también es importante saber cuál va a ser el proceso de modificaciones y arreglos. Muchas veces los diseños cambian al verlos en vivo y hay que irlos corrigiendo. O ciertos tamaños o alineaciones o márgenes que se nos han escapado y hay que ponerlos bien. O fotos que no hacen el efecto esperado. Y textos… Las modificaciones pueden llevar tanto tiempo como el trabajo inicial y a veces pueden ser frustrantes para las dos partes. Si de inicio sabemos cuál va a ser el canal a utilizar y el proceso (todas de golpe, página a página, una a una, por fases…) viviremos mejor.

En mi caso, después de probar muchas herramientas, suelo trabajar de la siguiente manera. Utilizo Trello (Asana o Basecamp quedaron a las puertas) para gestionar los proyectos, las fases (especificaciones, diseño, desarrollo, modificaciones, mantenimiento), utilizo Dropbox con una carpeta compartida para recibir los archivos (a veces también Drive) y estoy empezando a utilizar Invision como herramienta para los mockups. El diseñador puede ir subiendo los pantallazos, hacer comentarios sobre ellos e incluso mostrar algo de funcionalidad como con los menús.

Para la comunicación más del día a día me gusta usar Slack aunque siempre acabo en Hangouts… Todo esto lo que sí que no impedirá al final es que terminéis utilizando el email para todo, que nos conocemos, y acabéis con 9.384 mensajes sin leer en la bandeja de entrada… ¡pero yo comparto las buenas prácticas!

¿Qué tengo que saber para hacer mi propio tema?

Para crear tu propio tema lo importante es no querer empezar la casa por el tejado. Un tema de WordPress no deja de ser una página web y para crear una página web tienes que tener bastante claros los conceptos del HTML. Y del CSS. Hay infinidad de cursos online, de libros, de todo… Si realmente queréis aprender desde cero, yo siempre recomiendo los cursos de Codecademy. Ejemplos claros para aprender lo que hay que aprender y de manera práctica. HTML, CSS, SASS como preprocesador CSS…

¿Qué más hay que saber? No viene mal saber algo de PHP, más que nada porque WordPress es PHP, ¿no creéis? Ahora bien, yo no me volvería loco con este tema (desarrolladores afilando cuchillos…) y con aprender lo básico de la sintaxis y algunas órdenes básicas es más que suficiente. ¿Por qué? Porque WordPress tiene una cantidad de funciones excepcional y esas son las que vamos a ir usando en el futuro, con lo que no hace falta aprender a hacer llamadas a bases de datos ni a manejar datos de maneras que luego no van a ser las recomendadas para lo que tenemos entre manos.

Obviamente, cuanto más sepamos mejor. Si podemos añadir conocimientos de JavaScript a nuestro stack de lenguajes con los que nos manejamos, mejor que mejor, todo suma.

Una de las habilidades que más me han ayudado a lo largo de todos estos años trabajando en la web, tanto en HTML puro como ahora con WordPress, es el Copy & Paste avanzado. ¿Lo qué? Sí, sí, avanzado. Estoy seguro que muchos de vosotros habréis hecho lo siguiente, y si aún no lo habéis hecho, lo haréis en el futuro próximo: Tengo un problema con la web, estoy atascado, voy a Google, busco el problema, me sale una solución de Stack Overflow. Dicen que funciona bien. Copio el código. Lo pego en algún lugar que no tengo muy claro cuál es. Desde el editor de apariencia del admin de WordPress claro. Pulso en guardar cambios. Pantallazo blanco. Blanco. Nada. Ni un triste error. Bienvenidos a la White Screen of Death de WordPress.

¿Por qué ha pasado esto? ¿Cómo arreglarlo? Por suerte también hay tutoriales sobre esto. Pero sobre todo hay que aprender una lección. No copies y peguéis a las bravas, sin entender o al menos hacer un esfuerzo por intentar entender qué estáis provocando con el código que vais a añadir a vuestra web. Con el tiempo iréis pillando práctica, no os preocupéis. Pero que no digan que no os avisé.

Hablando de dónde y cómo copiar código que sabéis que va a funcionar… os presento a vuestra web de referencia mientras queráis crear un tema de WordPress: el Theme Handbook. EL THEME HANDBOOK. Para que si estás pasando rápido hacia abajo no se te escape. Ahí está todo lo que yo más o menos resumo a partir de aquí pero ampliado y bien. Y en inglés, claro. A ver si pronto nos lo dejan traducir.

Y ya como bola extra, por si todo lo que os he contado hasta ahora ya lo tenéis controlado, algo que cada vez es más importante en el diseño y desarrollo web es la tipografía. No, no me pienso meter en ningún jardín como en la charla sobre si son fuentes, si son tipografías o qué demonios son. Igual que no me meteré con los logotipos, isotipos o imagotipos. Nos vamos entendiendo… Nunca está de más aprender sobre ella, así que podéis echar un ojo a artículos como estos que hay por la red: Web Typography: Educational Resources, Tools and Techniques o 10 Web Typography Rules Every Designer Should Know.

¿Qué es un tema de WordPress?

Otro inciso, ya sabéis lo que tenéis que saber para hacer un tema. Pero… ¿sabéis qué es exactamente un tema? Oh, cielos. Sí, seguro que lo sabéis, pero por si acaso, un tema de WordPress es lo que nos permite cambiar la apariencia de nuestra página web. También nos permite cambiar alguna funcionalidad, pero lo principal es el aspecto visual. Es todo esto, pero claro, al final son archivos .php, .css o .js. Eso es lo que es.

Si queréis profundizar en lo que es un tema, lo que no es, lo que es una plantilla y las buenas prácticas para desarrollar temas de WordPress os recomiendo esta charla del crack Darío Balbontín en la WordCamp Madrid 2017: Anatomía de un tema WordPress. Aquí tenéis el vídeo y aquí la presentación en sí.

La evolución del desarrollador de temas de WordPress

Si eres de los que acabas de aprender los básicos de HTML que os decía hace unos párrafos, es probable que os asuste esta historia de crear un tema de WordPress. «No puede ser tan fácil pasar de cero a cien«, pensaréis alguno. Efectivamente. Que seguro que alguno sí que termine este post (no creo que nadie lo termine, pero necesito soltarlo todo) aprendiendo un montón, pero yo os voy a decir las fases de la evolución del desarrollador de temas que yo viví.

La primera vez que un diseñador te pase un diseño de una web, dedicarás dos horas a buscar en Themeforest un tema que se parezca lo máximo posible a lo que tienes entre manos. Te gastarás los 60 dólares correspondientes y después pasarás unas cuantas horas quitando historias y dejando los colores, las imágenes, las columnas, etc., lo más parecido a lo que te han enseñado.

El problema llegará cuando tengas que meter una funcionalidad absurda y no seas capaz de encontrar en qué archivo tienes que hacer la modificación. Y te desesperes porque va lento y no eres capaz de aligerarlo sin romper otra cosa que aparentemente no tenía relación con lo que acabas de hacer.

Cuando te cansas de esto, decides coger uno de los temas que vienen por defecto, como el Twenty Seventeen, o el Twenty Sixteen o incluso el Twenty Thirteen y te planteas crear un tema hijo. Has oído que los temas hijos son perfectos para ir modificando cosas y piensas que es la manera de ir aprendiendo. Y, efectivamente, así es. No voy a entrar en detalles sobre cómo hacer un tema hijo, pero os recomiendo esta charla de Carla Saiz en la WordCamp Madrid 2017 sobre el tema (patapan pshh) porque merece mucho la pena y cubre todo lo que se puede hacer y cómo hacerlo.

Claro que llega un momento que ves a tu tema hijo y a su padre y parece que es de otro. Has hecho tantas modificaciones que al final piensas, ¿no habría sido mejor empezarlo de cero? Probablemente. Pero el archivo untitled en blanco da mucho miedo. Por eso existen esqueletos, starter themes como Underscores para solventar este problema. ¿Qué es lo que hacen? Te dan una estructura de archivos básica para tu tema, sin ningún estilo -solo los básicos de reset y normalización- para que puedas modificarlo a tu gusto y crear tu propio tema.

Existe también una versión de Underscores que se llama Components, donde puedes bajarte ese mismo esqueleto pero con algún estilo de más (para montar una web tipo blog, tipo corporativa, tipo revista, tipo portfolio…) por si también te asusta el tener que maquetarlo todo desde cero. ¡Deja de asustarte!

Finalmente, cuando ya has metido tantas modificaciones a tu Underscores que lo has dejado a tu gusto y prácticamente has creado tu propio framework para empezar proyectos… ya podemos decir que estás listo para crear tus propios temas desde cero. Yo considero que hacerlo con _s ya equivale a hacerlo desde cero, pero hay puristas para todo.

Oiga, yo he venido aquí a por el código

Esto pensó más de uno en la charla, pero tampoco era plan de ponerme a meter línea a línea con todas las cosas que quería contar, ¿no?

Está bien, está bien. Para hacer un tema estaría bien tener un diseño en el que basarse, ¿no? No sé si llegaremos a conseguir el código exacto para que funcione, pero… digamos que queremos hacer la guía para disfrutar de una WordCamp como debe ser, tanto para novatos como para veteranos. Digamos que queremos que cuatro expertos WordCamperos sean los protagonistas de esta página. Digamos que tenemos un diseño tal que así:

Ahora sí que ya podemos ir trabajando…

Si habéis escuchado la charla de Darío que enlazaba más arriba, tendréis claro que un tema lo que necesita sí o sí, exclusivamente para funcionar es un index.php y un style.css. Así que con este código, técnicamente ya tenemos un tema, ¿verdad? Si supongo que tenéis instalado WordPress con una entrada de ¡Hola, mundo! y habéis activado el tema con estos dos archivos… ¡técnicamente ya lo tenéis! Así que a partir de ahora sólo es ir mejorando cosillas…

Además, podemos añadir un screenshot.png, una imagen de máximo 1200x900px que es la que sale luego como miniatura en la pantalla de Apariencia > Temas.

El loop y otros básicos de un tema

Lo que veis en el código anterior tiene fácil explicación. En el index.php tenemos el loop. El famoso loop de WordPress. Aquí podéis profundizar sobre el funcionamiento del bucle de WordPress. Hay que comprender cómo funciona un poco WordPress por dentro… por un lado tenemos los archivos que forman parte de la instalación, del core, los plugins, nuestro fantástico tema… y por otro lado hay una base de datos donde se guardan todos los contenidos. El bucle lo que hace es preguntar a la base de datos si hay contenidos que mostrar y si hay algo, lo pinta y vuelve a preguntar por si hay más cosas que pintar.

En la hoja de estilos metemos la información que tiene que estar sí o sí sobre nuestro tema, su nombre, el creador, la licencia, el textdomain para las traducciones…

Pero claro, la web tal y como está ahora no es lo que buscamos, y tampoco vamos a meterlo todo en el mismo archivo index.php, ¿verdad? Efectivamente. Hay otras plantillas básicas en un tema que tenemos que contar con ellas, como son header.php, footer.php o sidebar.php.

El concepto es sencillo, todo el código que tenga que ir en el cabecero de la página y la parte superior -el encabezado-, irá al header.php. El pie de página con su contenido y scripts correspondientes, al footer.php. ¿Hay barra lateral? Su sitio es el sidebar.php. Y el contenido puede seguir estando en el index.php o…

O utilizar cualquiera del resto de plantillas que existen para cada caso, como son page.php (para páginas), single.php (para entradas individuales), home.php (para la portada si muestra las últimas entradas), front-page.php (para la portada si es una página estática), archive.php (para los archivos de categorías, etiquetas, etc.…).

¿Cómo sabe WordPress que plantilla tiene que utilizar para cada caso cuando varias valdrían para la misma página? Aquí entra la jerarquía de plantillas, cuanto más específica sea, mayor prioridad tendrá para ser la utilizada. Aquí tenéis toda la información de la jerarquía de plantillas en el Codex, y aquí el famoso gráfico que todo desarrollador acaba consultando para saber qué manda sobre qué. Como podéis ver, si no existe ninguna, al final siempre acaba apareciendo al rescate el index.php, por eso es la única obligatoria.

¿Cómo trocear entonces un diseño?

Una vez que hemos decidido cuál va a ser la estructura de nuestra web y dónde vamos a ir colocando cada trozo de nuestro código, hay que pasar al troceado literal, ¿no? Si estáis utilizando una herramienta como Zeplin que os recomendé antes, tenéis gran parte del trabajo hecho. Si no, simplemente tendréis que exportar las imágenes de la manera más optimizada posible para web y más ajustada para que el diseño vaya cuadrando píxel a píxel.

Aquí ya podemos entrar en diversas situaciones, como querer utilizar un logo o unos iconos en formato SVG, un formato vectorial que hace que no se pierda calidad al modificar el tamaño del archivo, o si vamos a tener en cuenta las pantallas Retina que nos harán guardar todas nuestras imágenes a @2x, el doble del tamaño del esperado, para que se ajusten bien a pantallas con el doble de resolución. Esto (como casi todo en esta entrada) da para un post individual, así que no me enrollaré, pero sabed que hay que tenerlo en cuenta.

Además de las imágenes, tendremos que tener en cuenta la paleta de colores a utilizar (en formato HEX y RGB, por si necesitamos hacer transparencias con alpha), las fuentes con sus tamaños y grosores para cada apartado, y la estructura de la página, si se utiliza o no un grid, una retícula predefinida (x columnas de x píxeles con tanto margen) o si simplemente adecuaremos el contenido que tengamos al ancho máximo mediante CSS con flexbox.

Una vez que lo tenemos todo listo, las imágenes en una carpeta /img y todo bien apuntadito para ir maquetando vía CSS, podemos seguir adelante…

Mobile first y media queries

Uno de los mayores cambios de estos últimos años es el mobile first. Es algo que se tiene que tener en cuenta desde el momento del diseño, a ser posible, pero si no, es fundamental a la hora del desarrollo. ¿Qué quiere decir? Que en vez de crear la web en modo escritorio y luego ir haciendo el navegador pequeño y reorganizando todo el contenido hasta tenerlo todo en una única columna, hay que hacerlo al revés.

¿Por qué es esto? ¿No da lo mismo? Es un concepto interesante, técnicamente es similar, pero requiere algo más de pensamiento en la parte móvil, cosa que no se suele hacer. Y por eso terminamos con menús de hamburguesa que no funcionan bien, con elementos que apenas se pueden pulsar sin pinchar en varios, con sliders diminutos que no aportan nada y no se ve su contenido, con barras laterales que en el escritorio tienen un call to action fundamental para la web y en móvil lo hemos mandado debajo de todo el contenido, a kilómetros de scroll para nuestro visitante…

¿Y cómo sería? Veamos un simple ejemplo de cómo quedaría nuestra hoja de estilos si quisiéramos que en pantallas pequeñas (hasta 640px) el cuerpo de la página tuviera un padding lateral de 16px, y a partir de que crezca, ya no haga falta -porque tendremos capas contenedoras centradas con su propio padding, por ejemplo):

Organización y template-parts

Vale, ya tenemos claro cómo vamos a separarlo todo, tenemos los archivos, tenemos la motivación… Así que os voy a interrumpir para contar una anécdota sobre por qué hacen falta template-parts. Que para los que vienen del PHP o de cualquier otro lenguaje de programación, vienen a ser un include de toda la vida, pero versión WordPress.

Hace no mucho tuve que desarrollar a partir de un diseño una web de un local de conciertos. En la portada hacía falta meter al final un listado con los próximos eventos. Lo programé y lo añadí en page-portada.php. Todo correcto. Después me dijeron que había que meter esa parte también en la página de eventos. Ni corto ni perezoso, copy, paste, solucionado. Oye, también en ésta sobre el local. Paste. Estupendo. Una semana después había que hacer modificaciones en el código, porque no habíamos tenido en cuenta que no todos los conciertos tenían entrada, sino que algunos podían ser gratuitos. Modificar código. Copiar y pegar en los otros dos lados. Un mes después surgió un evento que no era sólo de un día, sino que duraba varios. Modificar código. Esto… ¿dónde estaba esto también? Creo que aquí… Pegar…

Creo que entendéis todos lo poco óptimo que esto y los problemas que conlleva cuando dejas de acordarte (porque para qué lo iba a apuntar) en qué página estaba el código. Para esto existen los template-parts. Creas un archivo aparte con el trozo de código necesario y lo invocas desde donde necesites mediante la función get_template_part(). Ahora sólo tienes que modificarlo una vez y… magia.

Functions.php y plugins

Tal vez os extrañe que aún no hayamos hablado del archivo functions.php, cuando es la solución a todos los males y el lugar donde te llevan todas las respuestas que encontréis en Google sobre cómo arreglar lo que sea.

Este archivo contiene funciones que permiten modificar funcionalidades o aspectos de nuestro tema, por eso es tan importante y hay tantos códigos que nos permiten modificarlo todo desde aquí. Ya sea mediante funciones creadas a propósito y luego enganchadas en la cabecera o pie de nuestra web, o mediante ganchos, ya sean de acciones o de filtros. Esto último es muy interesante para ir haciendo cambios, pero os recomiendo esos dos artículos de Pablo López sobre ellos muy bien explicados.

¿Y qué hay que tener en cuenta para esto? Pues que no hay que abusar del functions.php. Por norma general metemos todo ahí y funciona sin problemas, claro. Pero ¿qué pasa si el día de mañana decidimos cambiar de tema a otro más bonito o más útil que hemos creado o que hemos encontrado por ahí? Pues que perderemos toda esa funcionalidad al desactivar el tema actual. ¡Oh cielos! Por eso hay que tener en cuenta que lo que metamos en este archivo tiene que estar relacionado con el tema que vamos a utilizar, y si pensamos que debiera estar ahí (un tipo de contenido personalizado, por ejemplo) aunque no usemos ese tema, lo más correcto es añadirlo en un plugin y activarlo. De esta manera estará ahí, sea cual sea el tema que usemos.

¿Pero hacer un plugin no es muy complicado? Oh, no, nada de eso… Igual que los temas, con muy poco podemos ir arrancando y según vayamos aprendiendo y mejorando, iremos modificando nuestro plugin para usar más opciones, modularizarlo, etc, etc. Por ejemplo, si queremos crear aparte de las entradas y las páginas un tipo de contenido que sea Recomendaciones, podemos hacerlo de esta manera:

Enqueue scripts & styles

Al hacer una web en HTML solemos llamar a pelo desde el head de nuestro código a las hojas de estilo CSS y a los archivos JavaScript que necesitamos. Eso en WordPress es una mala práctica. ¿Por qué? Porque tenemos dos funciones que nos permiten hacerlo de manera correcta y, sobre todo, que permiten a otros desarrolladores que utilicen nuestros temas o plugins, desenganchar nuestros archivos y cambiarlos por otros o por los suyos.

Aquí tenéis toda la información del Codex sobre cómo incluir archivos CSS y JS en nuestros desarrollos. Y aquí un par de ejemplos si, por ejemplo, hacemos lo que recomienda WordPress para cargar nuestra hoja de estilos y cargar sólo el script de comentarios donde se pueden hacer comentarios, y también si quisiéramos cargar una biblioteca externa como puede ser prettyPhoto de JavaScript para hacer un efecto de lightbox en las imágenes de la página de multimedia. Tenemos un archivo para inicializar el script y luego cómo quedaría nuestro functions.php.

Durante la charla hablé de utilizar esto para cargar los scripts del plugin Contact Form 7, muy usuado a nivel global, sólo en la página de contacto. Revisando la documentación del plugin, ahora hay una manera diferente de hacerlo, por si queréis echarle un ojo, mediante un par de filtros y un par de funciones.

Imágenes y thumbnails

Uno de los problemas clásicos al pasar de un diseño a un tema es que nos volvamos locos con los tamaños de las imágenes. A veces se terminan cargando imágenes gigantes (en píxeles y en megabytes) para necesidades muy pequeñas del diseño como pueden ser miniaturas. Si tenemos bien seleccionados los tamaños de las miniaturas que vamos a necesitar, los podremos usar más adelante en nuestras plantillas y nos ayudará a que todo esté más optimizado.

Gracias a la función add_image_size() podemos generar las imágenes que justo queramos. Toda la info sobre esta función, claro, en su sección del Codex.

El menú

No caigamos nunca en la tentación de generar un menú a mano aunque sean sólo un par de elementos, porque a la larga pueden ir creciendo y, además, si WordPress te ofrece una función para hacerlo automáticamente, es buena idea utilizarlo. En este caso tenemos wp_nav_menu() que nos permite utilizar después el elemento de Apariencia > Menú del administrador para crear nuevos menús (que hemos tenido que registrar previamente) y gestionarlos.

Si por ejemplo queremos que en nuestra web haya un menú superior para luego irle añadiendo páginas que vayamos creando, tendríamos que utilizar este código.

Usar el personalizador: el logo

Hasta hace no mucho, la mayoría de los temas premium tenían una página de opciones desde la que hacer todo tipo de modificaciones al tema: colores, logos, imágenes, fondos, código personalizado, etc… Desde hace un tiempo y cada vez más este 2017 se está potenciando el uso del personalizador integrado en WordPress para todas estas cosas. Se puede acceder desde el menú Apariencia > Personalizar y ahí se abren una serie de paneles para modificar nuestro tema. Podéis probar con cualquiera de los que vienen por defecto.

Pero nosotros también podemos utilizarlo sin ningún problema para nuestro tema. Por ejemplo, si queremos utilizar el logo que desde ahí subamos para ponerlo en la cabecera de nuestra web, simplemente tenemos que añadir este código al functions.php. De esta manera hemos añadido la compatibilidad de nuestro tema con la imagen del sitio que viene por defecto en el personalizador.

Si queréis añadir nuevos paneles, nuevas opciones o lo que se os ocurra, existe la API del personalizador de temas con toda la información en la documentación sobre ella.

Añadir sidebars: los widgets

Las barras laterales en nuestra cabeza está claro lo que son, barras laterales a la derecha o a la izquierda del contenido principal donde metemos el contenido… menos importante casi siempre. Pero en WordPress no tiene por qué ser así, pueden ser lo que nosotros queramos que sean. Una de las ventajas que tienen es que en ellas podemos meter widgets (desde Apariencia > Widgets) y sacarlos mucho partido, ya sean los widgets que vienen por defecto en WordPress, los que aparecen al instalar ciertos plugins o incluso widgets personalizados que podemos crear para la ocasión.

Y podemos colocarlo allá donde queramos nosotros en nuestro código y que tengan la apariencia que nosotros queramos con nuestros estilos CSS. Por ejemplo, en muchos temas la zona del footer tiene diferentes sidebars que equivalen a diferentes columnas donde podemos poner un cuadro de búsqueda, un texto plano o un widget que muestra las entradas más recientes o los últimos comentarios publicados. ¿Y qué necesitamos para tener una de estas sidebars en nuestro tema? Simplemente declararlo en nuestro functions.php y aparecerá mágicamente en Apariencia > Widgets para que lo gestionemos como queramos.

No olvidemos los tags condicionales

En este repaso a todo lo que podemos hacer con nuestro tema, hay un apartado que nos va a salvar la vida en muchas ocasiones: los tags condicionales. Uno de los ejemplos más claros ocurren con el título de nuestra web. Casi todos estaremos de acuerdo en que el título debería ir entre etiquetas <h1> en la portada de la web, ya que es el término más importante de la misma (hola amigüitos del SEO). Pero claro, sí en nuestro header.php definimos nuestro título entre etiquetas <h1>… ¡sería así en todas las páginas!

Por eso existen los tags condicionales que nos permiten decir… si es la portada, escríbelo entre h1, y si es cualquier otra página, mételo dentro de un div, o un span, o un lo que sea… ¿Y a nivel de código cómo se hace esto? ¿Y qué tipos de condicionales hay? Prácticamente todos los que se os ocurran, aquí tenéis el listado del Codex. Destacan algunos como is_home(), is_front_page(), is_admin(), is_single(), is_page(), is_category(), in_category()…

Los campos personalizados

A veces no todos los contenidos que tenemos para introducir encajan en el recuadro de escribir el contenido –el the_content()– y conviene utilizar los campos personalizados. Yo soy declarado fan de ACF Pro (Advanced Custom Fields), pero si queréis conocer todas las opciones que ofrece WordPress para esto, os recomiendo ver la charla que dio Mauricio Gelves en la WordCamp Madrid 2017 sobre «Boxeo de campos personalizados» para ver quién gana la batalla.

A la hora de trabajar con clientes está genial que ellos sólo tengan que ir rellenando campos y nosotros poder mostrarlo en nuestro tema personalizado utilizando la función the_field(). Una maravilla.

Internacionalización y localización

Esta última parte de la presentación ya son las típicas cosas que tienes que tener en cuenta desde el principio… pero una vez que ya controlas todo lo demás. Es decir, son muy importantes, pero si te centras en ellas sin aprender la base, te vas a volver loco y es probable que te pierdas y acabes cayendo de nuevo en las redes de ThemeForest…

La internacionalización (I18N) y la localización (L10N) tienen sus páginas en el theme handbook y se refieren tanto a la capacidad de permitir que nuestro tema se traduzca a cualquier idioma que se quiera traducir, como al hecho de hacer una traducción acorde al idioma y a la cultura de las personas que hablen ese lenguaje.

Este fantástico post de Pascal Birchler, que dio una charla precisamente sobre internacionalización en la WordPress Bilbao el mismo día que yo, explica con pelos y señales todo lo que tenéis que saber sobre este tema y por qué es importante. Desde las diferencias entre culturas que muchas veces damos por supuesto que no serán, a herramientas para que nuestro código esté correctamente preparado para ser traducido.

Accesibilidad

Si hay algo que muchas veces pasamos por encima por desconocimiento o vagancia desarrollando un tema es la accesibilidad. Que por supuesto tiene su apartado en el theme handbook. Pero que no es sólo importante «porque ayuda a mejorar el SEO«, sino porque gente con algún tipo de discapacidad, incluso temporal (¿te has roto un brazo y has tenido que navegar en alguna web móvil? ¿has tenido vista cansada e intentado leer una web con una fuente de 12 píxeles?) necesita poder utilizar bien tu web.

Yo reconozco que hasta hace no mucho lo que sabía de accesibilidad lo sabía de oídas, los típicos consejos sobre poner texto alternativo a las imágenes, utilizar los headings de h1 a h6 y no hacer trapalladas como dicen aquí en Galicia. Pero después de ver esta charla de Juanjo Montiel en el Front Fest 2017 cambió mi percepción de la accesibilidad un montón. Os lo recomiendo por encima de todo lo que podáis ver y aprender en este post. Vedlo. Y alucinad.

Seguridad

¿La seguridad aquí abajo? ¡Madre mía! Lo sé, lo sé, pero como ya he dicho antes, éstas son las cosas que hay que tener en cuenta desde el principio una vez tenemos claro todo lo que vamos a hacer para crear nuestro tema, si no es probable que lo dejemos a mitad de camino. ¿Cuándo hablamos de seguridad en un tema de WordPress de qué hablamos exactamente? Esto no es como los bugs del core o los problemas de algún plugin… Estamos hablando de utilizar buenas prácticas de desarrollo de temas, y eso trae consigo la validación, sanación y escape de todos los datos que integremos en el tema. Validating, sanitizing and escaping, en inglés que es como lo veréis más a menudo.

Esto quiere decir que si tenemos por ejemplo un formulario que va a guardar los datos que se envíen en nuestra base de datos, nos aseguremos primero de que si lo que tienen que poner es una dirección de correo electrónico, lo que el usuario introduzca en el campo sea una dirección de correo electrónico. Y no una orden para ejecutar un script que nos borre la base de datos de nuestra web, por ejemplo. O cualquier otra maldad que se nos ocurra. En serio, es algo a tener muy en cuenta.

¿Y si tiene WooCommerce?

A estas alturas ya habréis visto que en la documentación oficial de WordPress está todo muy bien explicadito para hacer un tema con un montón de buenas prácticas. Pero ¿qué pasa si queremos que nuestro tema quede integrado con algún plugin de los más utilizados? ¿Es posible? Por supuesto que sí. Y no es nada difícil, ya que la mayoría de plugins tienen una gran documentación que nos facilita la tarea (hay que leer un poco, pero si has llegado hasta aquí no pongo en duda tu capacidad).

En el caso de WooCommerce tenemos la explicación de cómo hacerlo en la página Third party / custom / non-WC theme compatibility, y también podemos aprender sobre la gestión de plantillas de WooCommerce y su estructura en Template Structure + Overriding Templates via a Theme.

Si, por ejemplo, en nuestro tema queremos tener preparada una sección de tienda, no tendríamos más que utilizar el siguiente código para tener un tema WooCommerce ready.

Conclusión final y presentación

Como podéis ver, el tema de la creación de temas da para horas y horas de aprendizaje, y siempre quedan cosas por seguir investigando y mejorando. Cada uno de los apartados por los que he pasado por encima da para una charla de una hora tranquilamente, pero como no podía estar 20 horas hablando sin parar, he decidido hacer este post con un montón de enlaces para profundizar sobre todo lo comentado.

También sé que podría haber hecho quince posts diferentes menos largos y entrando un poquito más en cada asunto, pero ya lo siento, nunca he tenido visión de aprovecharme del SEO o de ir manteniendo a mis lectores aquí pillados leyendo las cosas cachito a cachito. Aquí está todo y si creéis que faltan cosas, no dudéis de añadirlas en los comentarios.

Para finalizar, os dejo más o menos cómo quedaría el código de la página de portada del tema para la web de la guía de disfrutar las WordCamps, quién sabe, igual algún día me animo y lo creo como web (más o menos) seria… Hay que tener en cuenta que desde el administrador de WordPress he creado las páginas correspondientes para el menú, he subido un logo desde el personalizador, he puesto el título y el subtítulo, he añadido una imagen destacada a la página de Portada, he añadido un widget con una frase al sidebar y he creado una serie de campos personalizados con ACF para la página de portada para meter el texto principal y el de cierre, así como un repeater para generar las columnas con imagen, título y subtítulo.