Cómo crear un plugin para WordPress. Making of de SimTerm (primera parte)

Son muchos los plugins para WordPress disponibles hoy en día, aunque la magia de este sistema de publicación radica en sus posibilidades para extenderlo. Así que aquí contaré la historia de la primera versión de mi primer plugin más o menos serio para WordPress: SimTerm. Contando, los pasos que di, lo que pude haber hecho de otra forma y lo que debí haber hecho de otra forma.

Índice

1. Instalación local de WordPress.
2. Elección del nombre.
3. Creando nuestro plugin
4. Pequeña intro a la programación de plugins
5. Vistas

Instalación local de WordPress

Lo primero, siempre que nos embarquemos en este tipo de proyectos será instalar WordPress de manera local, en nuestro ordenador. Así iremos mucho más rápido. En ningún caso recomiendo trabajar en remoto editando los archivos en el servidor. Conozco casos de otros desarrolladores que argumentan que así van más rápido pero:

• Si trabajas a través de un FTP, debes contar el tiempo que tarda una conexión en establecerse y un archivo en subirse. Crear o modificar un plugin es una tarea que implica salvar muchísimas veces los archivos y tal vez eches entre 5 y 10 segundos extra cada vez que salves y tengas que probar el archivo.
• Si trabajas con sesiones SSH, en ocasiones los servidores no responden inmediatamente como si estuvieras en local, por lo que pequeños retardos en las respuestas del editor de texto pueden causarte una pérdida grande de tiempo global.
• Si trabajas desde un editor desde la misma web, aunque los hay muy eficientes, pero siempre hay que hacer un envío de información con los contenidos del archivo que implica un tiempo de envío.
• Cuando pruebes la web, un servidor de Internet, tal vez tarde uno o dos segundos más (en el mejor de los casos) en responder, que suma al tiempo perdido editando.
• Te quedas sin Internet un momento, y no puedes trabajar.
• La depuración puede ser horrible, Muchos servidores están configurados para ocultar todos los errores. Así que sólo veremos pantallas vacías o de errores de servidor que no nos dirán nada. Por otro lado, si configuramos el servidor para poder visualizar correctamente los errores, todo el mundo podrá verlos.
• Volviendo a lo de antes, si todo el mundo puede ver los errores, también verá los progresos, y las páginas rotas constantemente, por lo que perderemos visitas a nuestro sitio (o nuestro cliente perderá sus visitantes), lo que tampoco es recomendable.

Así que, antes de nada, instalemos en local un WordPress vacío, si nuestro plugin necesita dependencias, instalémosle también éstas. O si nuestro proyecto es para un cliente y necesitamos adaptarnos a su WordPress tal y como está ahora, siempre podemos migrar la instalación a nuestro servidor local.

Para este caso, yo utilicé WP-CLI, con el que realicé una instalación de WordPress en mi ordenador. Primero creé un usuario en MySQL (podríamos utilizar nuestro root, que es local y no pasa nada, pero yo prefiero tener todo organizado):

> CREATE SCHEMA wptest
Query OK, 1 row affected (0.00 sec)
> GRANT ALL PRIVILEGES ON wptest.* TO 'wptest'@'localhost' IDENTIFIED BY '12345';
Query OK, 0 rows affected (0.00 sec)

Ahora, instalé WordPress de la siguiente manera:

$ wp core download -path=wptest -locale=es_ES
Downloading WordPress 4.5.3 (es_ES)...
md5 hash verified: d991b3152a1649b1286fd076658e1066
Success: WordPress downloaded.
$ wp core config -dbname=wptest -dbuser=wptest -dbpass=12345 -dbhost=localhost -locale=es_ES
Success: Generated wp-config.php file.
$ wp core install -url="http://localhost/wptest/" -title="WP Tests" -admin_user="admin" -admin_password="pass" -admin_email="blakeyed@totaki.com"
Success: WordPress installed successfully.

Si utilizar MySQL sandbox, tendrás el motor de base de datos instalado en otro socket, o puerto diferente, en mi caso, tengo la base de datos que utilizo en /tmp/mysql_sandbox5167.sock así que, para instalar WordPress ahí, tengo que decir:

dbhost=localhost:/tmp/mysql_sandbox5167.sock

Y ya tendría la base de datos lista.

Elección del nombre

Tampoco es nada del otro mundo. Pero debemos procurar que sea descriptivo y no esté siendo utilizado por otro plugin de WordPress. En principio, ya que el plugin va a servir para simular un terminal (de Linux o de cualquier otro SO), simterm me pareció un buen nombre (porque WP-Terminal estaba cogido).
Para ver si el nombre está cogido, debemos crear un slug, o un título corto que utilice caracteres seguros, en este caso coincide con el nombre "simterm", pero podría ser wp-simterm, wordpress-sim-term o algo así. Para ver si el slug está cogido, podemos acceder a https://wordpress.org/plugins/[slug] y ver si hay algo ahí.

El hecho de que el nombre no esté siendo utilizado por otro, es más que nada para que nos encuentren fácilmente. Si otro se llama igual, puede haber confusión por parte de los usuarios. El hecho de que el slug no esté cogido, además de para poder subirlo a WordPress.org va a hacer que no haya conflicto con otros plugins y como la vida de una página en WordPress es larga, no sabemos qué plugins vamos a instalar. Me refiero sobre todo al hecho de crear un plugin privado (que no vamos a liberar) que se llame igual que otro plugin que hay instalado.

Creando nuestro plugin

Lo primero que hacemos es crear un directorio donde estará nuestro plugin. Lo crearemos dentro de wp-content/plugins/ y se llamará simterm.
Una vez hecho esto, creamos un archivo que se llame igual que el directorio que acabamos de crear, pero con extensión php, e incluimos lo siguiente:
wp-content/plugins/simterm/simterm.php:

Será un comentario de PHP muy grande con información básica sobre el plugin.

En este mismo instante, nuestro plugin ya debe aparecer en la sección de Plugins de WordPress:

Pequeña intro a la programación de plugins

WordPress permite hacer los plugins de la forma que queramos, podemos empezar a escribir funciones y llamadas a la API de WordPress sin parar, aunque debemos hacer el plugin también bonito por dentro. Esto es subjetivo, pero tras leer varios plugins de WordPress de otras personas, hay una forma que me parece sencilla para empezar y a la vez elegante para crear nuestro plugin.
En el mismo archivo principal del plugin (simterm.php) empezaremos creando una clase SimTermLoader, con varios métodos, uno de ellos será Enable() o Init() donde tendremos todas las llamadas necesarias a funciones de WordPress para inicializar nuestro plugin: configuración de pantallas de administración, idiomas, shortcodes, hooks, etc, así como carga de ficheros, instanciación de clases. Las funciones que llame WordPress de nuestro plugin serán ahora de una clase SimTerm que crearemos en un archivo llamado (simterm-core.php, o podremos llamarla nuestroplugin-main.php, nuestroplugin-base.php, etc.).
Y lo primero que haremos nada más cargar el plugin será llamar de forma estática a este método SimTermLoader::Init()

La estructura básica será la siguiente:

wp-content/plugins/simterm/simterm-core.php:

Algunos autores prefieren que la clase principal de su plugin (SimTerm en mi caso) sea de tipo Singleton. De ese modo todas las acciones y callbacks de WordPress irán a métodos de la clase SimTermLoader y ésta obtendrá la instancia del Singleton SimTerm y llamará al método adecuado.

Vistas

Los plugins producirán una salida de cara al usuario. Y personalmente no me gusta mezclar los archivos PHP de un plugin con salidas HTML del usuario. Por eso, vamos a colocar un pequeño sistema de vistas, no muy elaborado, pero evolucionará. Con este sistema conseguiremos separar la salida del usuario de los propios archivos del plugin haciendo más fácil su mantenimiento y más ordenado.
Estas vistas, las colocaremos dentro del directorio del plugin, en un directorio llamado views. Y haremos algo muy parecido a lo que hace get_template_part() en los temas, pero para nuestro plugin. Para ello, incluiremos dentro del archivo principal del plugin (simterm.php) el archivo views.php cuyo contenido es:

Por lo tanto, a partir de ahora, siempre que queramos incluir algo de HTML (un poco de PHP también se permite, pero cuidaremos que éste sea sólo para generar salidas HTML para el usuario), lo escribiremos todo en un archivo aparte que situaremos dentro de views/ y lo llamaremos:

o

slug-name.php

Siendo slug y name dos palabras que identificarán nuestra vista. Nuestro plugin buscará la plantilla y la volcará a pantalla usando la API de WordPress.
Además, tenemos un array llamado variables, que será asociativo y contendrá las variables que representaremos más tarde dentro de la vista. Así si hacemos:

La vista podrá contener algo parecido a esto:

Preparados para la segunda parte

El 22 de agosto saldrá la segunda parte de esta introducción a la creación de plugins de WordPress con mucho más contenido, enfocado a las páginas de configuración, a la inclusión de archivos CSS y JS a la web y a la creación del shortcode que utilizará este plugin.