Cuando comienzas a desarrollar un plugin es normal cometer errores y pasar por una fase de ensayo y error, acumulas código bastante desordenado e incluso innecesario hasta que empieza a tomar forma. Programar necesita mucha práctica y experiencia, por eso
no te preocupes, no hay que castigarse por ello.
Resumen:
Practica todo lo que puedas que al final lo conseguirás, pero, en cambio, sí se pueden evitar algunos de los errores más comunes que todos cometemos. Si somos conscientes de ello y los tenemos presentes, los que hemos pasado por ello te dejamos estas experiencias que te serán de utilidad.
Veamos cuáles son:
Ocho errores más comunes que se cometen al empezar a programar plugins para WordPress
1. No considerar la compatibilidad de tu plugin con las versiones PHP
Lo primero que debemos saber es cuál es la versión de PHP en la que debemos desarrollar. Nuestro plugin será de interés para ciertos usuarios y debemos codificarlo en una versión de PHP que sea compatible para la mayoría de ellos.
Para hacerse una idea de en qué versión programar, WordPress.org ofrece una página con estadísticas de uso de las versiones de PHP.
Viendo esto, podemos decir que nuestro plugin no es compatible con versiones 5.6 o inferiores, alrededor del 40% no podrán hacer uso de él.
2. Nombrar mal las funciones
En el desarrollo de nuestro plugin seguro que crearemos diferentes funciones a las que debemos dar un nombre. Este nombre no debe ser genérico; siempre tiene que ser un nombre que describa a la función y, por su puesto, diferente de las demás funciones.
Muchas veces nos empeñamos en poner nombres cortos, pero es un error porque esto nos puede llevar a repetirlos y no serán suficientemente descriptivos.
3. No usar prefijos para las funciones
Al nombrar una función es fácil que otros desarrolladores hayan codificado una función con el mismo nombre que tú. Eso será un problema porque todas ellas están en el mismo entorno para ser ejecutadas y no hay forma de diferenciarlas.
Este error es fácilmente subsanable poniendo a nuestras funciones un prefijo que para nosotros sea significativo y fácil de recordar. Esto ya las hará diferentes de otras (la probabilidad de coincidir baja).
4. No incluir función de desinstalación
La mayoría de los usuarios, una vez que haya terminado con el plugin, es posible que quieran borrarlo. Es esencial poder desinstalar un plugin.
Hay dos posibles formas de tener disponible la desinstalación:
– Usando un gancho de desinstalación
register_uninstall_hook(__FILE__,’pluginprefix_function_to_run’);
– Usando un archivo de desinstalación (deberás crear tu propio archivo .php)
Puedes encontrar más información en el Codex de WordPress.
5. Desactivar el modo depuración
El modo depuración no debería estar desactivado durante el desarrollo. Debe aparecer así:
Esta funcionalidad la podemos encontrar en el archivo wp-config.php.
La funcionalidad de depuración de WordPress nos ayudará a ver los posibles errores pero también a hacer un seguimiento de las funciones que utilizamos (pueden tener fecha de caducidad).
6. No usar nonces
El término “nonce” es la abreviación en inglés de “number used once” (número usado una vez). En WordPress, los nonces son cadenas de texto aparentemente aleatorias, pero que en realidad han sido generados a través de un tipo específico de funciones.
No hacer uso de estas funciones es un error relacionado directamente con la seguridad de nuestro plugin. Con ellas podemos evitar el uso indebido de nuestras URLs.
Estas funciones crean una marca de tiempo única que nos aseguran que las peticiones provienen de su área de administración y no es un intento de interferir en la URL.
Si quieres más información visita la página de WordPress dedicado al uso de nonces.
7. No utilización de comentarios y/o sangrados
La única forma de que tu plugin pueda ser actualizado o modificado, bien sea por ti mismo o por otras personas, es que esté bien comentado y escrito de una forma legible. Sólo así, pasado un tiempo, entenderás lo que se hizo.
El uso de comentarios durante la codificación es esencial para saber y recordar qué hace nuestro código y por qué lo hicimos, tanto si lo revisamos nosotros como si es otra persona el que lo lee. También es muy útil ayudarnos de los sangrados porque nos ayudarán a estructurar todo el código e incluso a evitar algún error.
Además es una buena práctica en programación.
8. No seguir los estándares de codificación de WordPress. El Codex es la biblia de WordPress.
El trabajo que realizamos puede servir a otros desarrolladores al igual que nosotros podemos utilizar el trabajo de los demás. Esto sólo será posible si todos seguimos unas pautas y reglas básicas de codificación que nos marca WordPress.
Los estándares de codificación que marca WordPress los puedes encontrar en los siguientes enlaces:
• WordPress PHP Coding standards.
• WordPress HTML Coding Standards.
• WordPress CSS Coding Standards.
• WordPress JavaScript Coding Standards.
Esperamos que este artículo te sea de utilidad, te animamos a que no dejes de aprender sobre WordPress