es en eo es en es en es en en en es pt es es es es es en en it gl es es es de de de es es es es es es es es es es es es es es es es es es es es es es es es es es es es es es es es es es es es es es es es es es es es es es es es es es es es
Si alguna vez te has planteado programar en WordPress ¿sabes por dónde empezar? ¿Dónde encontrar la documentación?
Migra tu sitio WordPress en SiteGround: Uno de los dolores de cabeza más grandes a la hora de decidirte por un alojamiento es el de migrar tu sitio web. Y SiteGround te lo pone fácil con su herramienta de migración.
Joan ha presentado el Curso de Curso de Distribución digital musical.
Javier ha estado reconfigurando copias de seguridad y guardando en Wasabi.
Hoy traigo un tema que va a traer polémica, porque ya lo sé, pero me da un poco igual, porque las cosas de WordPress hay que decir las cosas buenas, y también las malas… y hoy vamos a ver una de las últimas.
Y, por poner en contexto, aunque conozco un poco las tripas de WordPress he de decir que no soy muy buen programador de WordPress. Puedo instalarlo, configurarlo, optimizarlo, escalarlo, y tengo algún pequeño plugin, pero la parte de programar a nivel pro, se me escapa.
Y es curioso porque en 2005 cuando empecé había que prácticamente programar mil cosas porque no había más que hacer. Un tema era fácil de implementar, y ahora es un poco caos. En el editor un poco lo mismo, antes con el editor clásico, programar algo era relativamente sencillo, y ahora con los bloques es un poco caos.
Todo esto me lleva a recordar lo que pasó en Puerto Urraco a principio de los 90. Si alguien no sabe de que va, que lo busque en la Wikipedia… solo voy a decir que la venganza de los programadores es muy traicionera y que no me extrañaría que algún día acabemos con un Puerto Urraco digital.
No conozco a ningún programador de WordPress que en los 2 últimos años me haya dicho algo en plan «me he atrancado con esto de un plugin, o de un bloque, o de un tema, y no hay manera de que funcione». Con la coletilla de «que frustración».
Y en parte tienen razón. Dejando de lado el core de WordPress, tenemos los plugins, que quizá sigue siendo lo más sencillo de gestionar, excepto cuando tratan con el Editor, que es uno de los grandes follones. Y es que aunque Gutenberg, el plugin, hace que todo evolucione mucho cada dos semanas con una versión nueva, esas mejoras no se reflejan a la misma velocidad con la documentación. Hay que tener en cuenta que la documentación se hace sobre lo que va en el editor del core de WordPress, por lo que hasta que no se deciden qué versiones de Gutenberg se trasponen al core, todo eso no se puede documentar. Esto hace que, en general, la documentación no aparezca hasta un tiempo después. Además, en las últimas versiones, han cambiado muchos elementos de las API propias del Editor que, igual, también tardan en reflejarse en la documentación.
Lo otro que también tiene su miga es lo referente al frontal, a los Themes, a los temas, y más con los de Bloques. En realidad ambos elementos están muy relacionados, porque todo viene con la velocidad que hay en todo el editor nuevo, ya sea el Editor de Contenidos, como el Editor del Sitio.
El objetivo de hoy es intentar poner un poco de orden en cómo aprender.
Las primeras decisiones van a venir dependiendo de dos elementos:
El primero es el idioma: ¿sabes inglés?
El segundo es en qué sabes «programar» (entre comillas): PHP, JavaScript, React, CSS, HTML…
Voy a presuponer que si sois programadores el tema del inglés, al menos leer documentación técnica, está aprobado. El tema de programar, lo iremos viendo ahora.
WordPress está programado, principalmente, en PHP y SQL, así que estos dos elementos, al menos deberían ser conocidos mínimamente o muy en profundidad, depende de lo que vayáis a programar.
Así que el primer lugar por donde empezar es developer.wordpress.org. Esta es la web central donde está toda la documentación para desarrollar en WordPress. Aquí tenemos el Code Reference, que es el lugar donde podéis encontrar la información de las funciones. Lo malo es que ni nos podemos saber de memoria todas las funciones, ni tampoco están explicadas al completo con muchísimo detalle qué hace cada función. A ver, algunas sí, el WP_Query, pero incluso en algunas os podéis encontrar que tenéis que hacer experimentos.
Ahí también vamos a encontrar las buenas prácticas para desarrollar con WordPress. ¿Hay que tabular o poner espacios? Ahí tenéis la respuesta, en el Coding Standards. Y si queréis saber la respuesta, me niego a darla, que entonces sí que tendremos un Puerto Urraco.
Otra de las cosas que os recomiendo, al menos conocer de oídas, es el funcionamiento de las API de WordPress. Y con API no pensemos en las típicas API de comunicación en plan API-REST, sino en funciones internas de WordPress que dan soluciones a problemas concretos: cómo conectar y hacer llamadas a la base de datos, cómo gestionar un ShortCode, o cómo gestionar los Transients. Digamos que es aprender a cómo usar de forma nativa el núcleo de WordPress. Esto es quizá de lo más importante si queremos hacer cosas muy escalables.
A partir de aquí tenemos 3 vías que también están en ese lugar: bloques, plugins y temas.
Por ejemplo, para programar bloques necesitaremos conocer un poco de Node y NPM, porque vas a tener que montarte un entorno de desarrollo que no es el habitual de WordPress.
Si no conoces el funcionamiento de Node y NPM vas a tener una curva de aprendizaje un poco más grande de la que habitualmente hay o había para otros elementos de WordPress. Saber JavaScript también es casi una obligación porque hay JSON por todos sitios.
Pero no todo es negativo, que conste. Hay plugins y herramientas base que son clave para usar como inicio de cualquier desarrollo y que se pueden usar como ficheros mínimos a partir de los que construir.
Lo bueno o malo de construir bloques es Gutenberg. El Plugin. Y es que como desarrollador tienes dos estrategias: la primera es la de solo dar soporte al editor que viene con WordPress, es decir, el estándar y estable, o ir detrás de las versiones RC del plugin Gutenberg para validar que no explota tu bloque. Y digo bien, las versiones RC de un plugin que ya de por sí es experimental… pero es que he visto en mil ocasiones que plugins grandes (como los típicos de SEO) se dan de tortas con las versiones que se van lanzando de Gutenberg… y es tener versión de Gutenberg nueva, durante dos días no poder guardar un contenido, y al cabo de ese tiempo, versión nueva del plugin de turno que se ha de adaptar a una versión experimental de una cosa que en general no tiene nadie en su editor… es complejo, es comprensible, pero personalmente no sé si es la mejor estrategia.
Mi recomendación personal, y recalco que es mi opinión, si te dedicas a hacer bloques para clientes, desarrolla solo para versiones estables de WordPress, y avisa a todo el mundo que tu bloque puede no ser compatible con «el plugin experimental Gutenberg». Yo he estado a punto de hacer un Puerto Urraco en los 2 o 3 plugins de SEO que se te están pasando por la cabeza… sí, esos.
Si nos vamos al asunto de los Themes, aquí ya has de tomar otra gran decisión antes de empezar: ¿Vas a desarrollar un tema de Bloques, uno Universal, uno Híbrido o uno Clásico? A ver, que nadie se ponga nervioso. Si vas a ponerte a aprender a programar por primera vez en los temas, mi recomendación es que te vayas a Temas de Bloques, con la posibilidad de extenderlo a Tema Universal (que es un tema de bloques con Personalizador).
Si este es el caso, lo mejor es comenzar por los ejemplos y documentación de los Temas de Bloques en la sección de desarrolladores.
Los temas de bloques tienen 4 grandes partes a tener en cuenta si pensamos en desarrollo:
La primera es la creación de la base. Un poco tener la estructura de ficheros y todo eso. Esto en realidad lo encontraréis en muchos ejemplos o en los Empty Theme que ya hay por ahí y que son temas «sin diseño» pero que incluyen los 4 ficheros de ejemplos base para comenzar.
Y aquí viene la segunda parte, que quizá es lo más importante de estos temas: las plantillas y partes. La gracia de los temas de bloques no es el tema en sí, sino todas esas plantillas que vamos a poner incluir de forma sencilla para que los usuarios no tengan que hacer prácticamente nada: una plantilla de contactar, de quienes somos, de ficha de producto para WooCommerce, la de la página principal, el listado de contenidos del blog, una landing page… las posibilidades son ilimitadas… y por supuesto, las partes, que podrían ser simplemente la zona del formulario de contacto que se pueda incluir en varias «partes» del sitio.
La tercera parte va a ser aprender un poco de estilo. Los temas de bloques incluyen el famoso «theme.json», un fichero JSON en el que podemos crear muchas variaciones de los colores, tipografías, espaciados, plantillas, partes y demás cosas. A vueltas con lo mismo… esto cambia mucho con el plugin Gutenberg, por lo que, de nuevo, tendremos que estar muy atentos con los cambios en la parte de los bloques.
Y con esto llega la última de las partes en cuanto a themes:
La paleta de colores
la paleta de tamaños de letra
Cómo se deben comportar los embeds
Los estilos en el frontal, vayamos a poner un fondo azul con un texto verde, que os hago un Puerto Urraco.
Y por supuesto, cómo van a interactuar los bloques que vienen con WordPress con vuestro tema.
He de decir que esta parte es una de las que tiene más negocio dentro del mundillo de WordPress en cuanto a temas: el hacer un tema base y meter la mayor cantidad de templates, partes y variations, porque básicamente la idea es que cualquier inútil en lo diseñil, como yo, pueda irse al tema, elegir las plantallas que ya vienen por defecto, elegir una variación de estilos y colores y pa’lante. Facilito, que si no me liais y no sé usarlo.
Y para acabar con cosas que se pueden aprender, tenemos los plugins… de nuevo, mi recomendación personal con los plugins va en dos líneas. La primea de ellas es que consigáis haceros con vuestra propia plantilla base de creación de un plugin. Hay por ahí, y las podéis usar, pero os recomiendo una vuestra en la que os sintáis cómodos y que incluyan los elementos base de cualquier plugin, como por ejemplo, los elementos de seguridad, ya de forma nativa. Ningún plugin sin su «nonce».
Para aprender de plugins habría que seguirse unos pasos. El primero es saber crear la base de un plugin. Esto es más o menos fácil, porque hay mil ejemplos, boilerplates y cosas parecidas, lo importante es entender cómo funciona esa base.
Lo segundo es la seguridad. Los mayores problemas de seguridad de WordPress vienen de esta parte, y es que en muchas ocasiones creamos una funcionalidad nueva y no pensamos cómo se le ha de aplicar la seguridad desde el principio. Si vas a poner un formulario y en él vas a pedir un número, asegúrate que eso que te llega solo es un número y nada más.
Otro de los elementos básicos de un plugin es interactuar con los «hooks». Los ganchos. Los hooks son esos puntos dentro de todo el código de WordPress, de un tema e incluso de otros plugins en los que puedes «acceder y hacer cosas», que se supone que es la idea de un plugin, hacer cosas. Hay muchísimos hooks en WordPress, y de ahí que sea importante conocer la referencia que comentaba al principio del todo, porque ahí están los que vienen con WordPress, aunque deberás buscar otros hooks en temas o plugins , que ahí es más complicado porque no suelen estar muy documentados.
Lo siguiente a la hora de programar un plugin es cómo interactuar con las diferentes partes del panel de administración y otras herramientas: llámese menús del panel, shortcodes, ajustes, metadatos, custom post types, taxonomías, usuarios, y seguro que me dejo algo.
Y todo esto hay que hacerlo, como también decía al principio, con los Coding Standards y las API de WordPress, para hacerlo BIEN, ese BIEN, en mayúsculas.
Y a partir de aquí, algunas cosas extra, como los Crones, si es que hacen falta. Esto es relativamente fácil porque la documentación está bastante bien, básicamente porque esto lleva años funcionando de la misma manera.
Y, para acabar con los plugins, y que también habría que tener en cuenta con bloques y temas: la «internacionalización». Cuando acabes la primera versión de tu plugin, bloque o tema has de dedicarle un poco de cariño a modificar todas esas cadenas de texto que has puesto para que se pueda traducir al centenar largo de idiomas a los que se traduce WordPress, y que ayudará a que tu plugin llegue a ese rincón del mundo que ni siquiera sabes situar en un mapa.
Como programador, tienes todo ahí, en el developer.wp.org… aunque quizá, si quieres tantear un poco todo, te puedas plantear darle una ojeada a algunos tutoriales, manuales o cursos que hay en Learn WordPress y, por supuesto, si vas más perdido que un pulpo en un garage, quizá lo que quieras es buscarte un lugar donde aprender con la colaboración de un profesor al que puedas hacerle las consultas necesarias si te atrancas en algún momento.
Recordad que nos podéis dejar ideas posibles temas de los que queréis que hablemos en el podcast.
Ya sabéis que podéis encontrar a Joan Boluda donde tenéis sus cursos de WordPress, y a Javier Casares con todos sus proyectos.
Ya sabéis que estáis más que invitados a participar a través de la sección de contacto de la web, a través de la que podéis enviar preguntas, dudas, y sugerencias para nuevos episodios.
Y recuerda que puedes suscribirte y escucharnos cada semana en Pocket Casts, Apple Podcasts, Spotify, Google Podcasts e iVoox.