Uso de ganchos de WordPress para limpiar código, activar y desinstalar
Publicado: 2015-01-23Los autores de complementos dedican tanto tiempo y energía a la funcionalidad principal de sus productos, que permiten que las cosas menos importantes se queden en el camino.
Tome la activación y desactivación, por ejemplo. Si bien los ganchos de activación están muy extendidos, muchos complementos necesitan agregar algunas opciones, borrar reglas de reescritura, tal vez crear una tabla de base de datos o verificar las diferencias de versión en la instalación, los ganchos de desactivación y desinstalación son mucho menos comunes.
¿El punto aquí? Muchos autores de complementos no se toman el tiempo para limpiar después de ellos mismos. ¿La instalación de WordPress realmente necesita la tabla personalizada que creó después de eliminar el complemento? ¿Por qué no eliminar algunas opciones que son exclusivas del complemento antes de tirarlo a la basura?
En este artículo, le mostraré cómo usar los ganchos de activación, desactivación y desinstalación para inicializar su complemento y limpiar las cosas más fácilmente una vez que los usuarios hayan terminado con su producto.
- El gancho de activación
- La secuencia de instalación
- Reglas de reescritura de vaciado
- Creación de tablas de base de datos
- Comprobaciones de dependencia
- El gancho de desactivación
- El gancho de desinstalación
- Seguridad adicional
- Es hora de limpiar
Nota: si planea hojear este artículo, le sugiero que eche un vistazo a la sección "Seguridad adicional" al final, que complementa el código con algunas comprobaciones de seguridad valiosas. Además, si necesita ayuda con los ganchos de complementos de WordPress, aquí hay un repaso rápido sobre el uso de ganchos de WordPress y cómo activar una función en WordPress.
El gancho de activación
Aunque el enlace de activación es bastante sencillo, instalarlo es un caso un poco especial, por lo que debemos prestar atención a la secuencia de eventos. Antes de entrar en todo esto, aquí hay un ejemplo simple:
La clave de todo es la función register_activation_hook() . El primer parámetro es la ruta al archivo del complemento principal; el segundo parámetro define la función a ejecutar. Internamente, la función register_activation_hook() es un envoltorio para la acción "activate_[plugin_name]", pero dado que es un poco más fácil de usar, es inusual ver el gancho en los complementos.
La secuencia de instalación
Comprender la secuencia de instalación es importante porque evita el uso de métodos a los que puede estar acostumbrado. register_activation_hook() se llama entre el usuario que hace clic en el enlace de activación y, en consecuencia, ve el aviso de activación. Se ejecuta en una página intermedia, que redirige inmediatamente antes de que cualquier enlace pueda tener la oportunidad de ejecutarse.
Veamos un ejemplo para ver por qué esto es un gran fastidio:
Reglas de reescritura de vaciado
Varios complementos crean tipos de publicaciones personalizadas. Vaciar las reglas de reescritura en la activación para asegurarse de que los usuarios no reciban un error 404 cuando visiten una publicación del nuevo tipo de publicación personalizada es un movimiento inteligente.
El siguiente código parece lógico pero fallará.
Parece perfectamente bien. Se crea el tipo de publicación personalizada y, en la activación, eliminamos las reglas de reescritura. El problema es que los tipos de publicaciones personalizadas aún no se han creado cuando eliminamos las reglas de reescritura.
Así es como se ve el flujo del proceso:
- El usuario instala el complemento.
- El usuario hace clic en el enlace de activación.
- Una página intermedia ejecuta solo el gancho de activación, nada más. Esto vacía las reglas de reescritura.
- El complemento está activo y el código se ejecuta como de costumbre. El tipo de publicación personalizada está registrada.
Una solución publicada en Stack Overflow, que cuenta con el respaldo oficial del Codex de WordPress, resuelve nuestro pequeño problema. La solución consiste en agregar una opción para indicar que el complemento se acaba de instalar.
Si esta opción existe, hacemos nuestra activación y luego la eliminamos.
Algo como esto:
Personalmente, no me gusta demasiado esta solución. El problema es que la verificación en la línea ocho se ejecuta en cada carga de página. No hay nada de qué preocuparse, ya que no supondrá una gran carga para sus servidores y no ralentizará el sitio web para sus usuarios. Es una comprobación muy rápida con un impacto insignificante en el rendimiento. Sin embargo, es innecesario el 99,9% de las veces.
Hay una mejor solución mencionada en el Codex en la documentación para la función flush_rewrite_rules() . En esta solución, utilizamos la modularidad de nuestras funciones para registrar el tipo de publicación personalizada en la activación por separado:
En lugar de depender de una verificación que debe ejecutarse todo el tiempo, usamos la función de activación para registrar nuestros tipos de publicaciones. Tenga en cuenta que una vez que nuestro complemento esté activado, los tipos de publicaciones siempre se registrarán desde el gancho de init .
Este es un triste ejemplo de que el Codex está por todas partes. En general, WordPress tiene buena documentación, pero si algo parece un desperdicio o ilógico, no temas investigar por tu cuenta.
Creación de tablas de base de datos
Otra tarea que realizan algunos complementos es crear tablas de bases de datos. La mayoría de las veces, esto es innecesario, pero hay algunos casos de uso legítimos.
Este ejemplo del artículo del Codex sobre Creación de tablas muestra cómo se pueden usar varias llamadas de activación:
La primera función, jal_install() crea una nueva tabla de base de datos. La segunda función, jal_install_data agrega datos iniciales a la tabla. En lugar de usar register_activation_hook() para agregar una función que contenga todo este código, podemos usar register_activation_hook varias veces.
Esta es una gran práctica para la modularidad. Por un lado, no tiene que agregar datos de prueba iniciales, es tan simple como quitar el gancho de activación, por lo que puede mantener la función intacta. Por otro lado, puede reutilizar estas funciones en cualquier lugar, ya que están separadas.
Comprobaciones de dependencia
Otra tarea común para la función de activación es verificar las dependencias. Su complemento puede depender de una versión específica de WordPress, otro complemento o incluso una versión específica de PHP.
El siguiente código busca una versión mínima de WP y PHP y redirige al usuario (sin activar el complemento) si es necesario:
El gancho de desactivación
Los ganchos de desactivación se ejecutan cuando un usuario ha desactivado un complemento, pero antes de que se desinstale (elimine). Los ganchos de desactivación se utilizan de la misma forma que los ganchos de activación:
La desactivación significa que el usuario solo ha desactivado su complemento, por lo que no querrá hacer tanto como lo haría durante una desinstalación. Es posible que desee eliminar las reglas de reescritura, pero en esta etapa, no querrá deshacerse de todas sus opciones y su tabla de base de datos (si tiene una).
Esto es bastante sencillo, pero prestaré especial atención a las reglas de reescritura de vaciado ya que, una vez más, son problemáticas.
El códice recomienda hacerlo como se muestra a continuación, pero esto no funciona :
La razón por la que esto no funciona es la misma que antes. Ejecutar una desactivación realiza el gancho de init , lo que significa que mientras desactivamos nuestro complemento, también estamos registrando nuestro tipo de publicación personalizada. Las reglas de reescritura están vacías, pero tienen en cuenta el tipo de publicación personalizada.
Existe una multa de Trac para abordar esto, pero hasta entonces, no puedo brindarle una buena forma de hacerlo. La única forma que he encontrado que funciona es eliminar las reglas de reescritura por completo:
Si bien esto me ha funcionado en el pasado, no lo recomendaría. Introduce una mayor incertidumbre que el problema de tener algunas reglas de reescritura adicionales. Preferiría mostrar una nota a los usuarios pidiéndoles que visiten la configuración del enlace permanente después de la desactivación, lo que eliminaría las reglas de reescritura. Hasta que se implemente una mejor solución, estamos atascados con esto... ¡lo siento!
El gancho de desinstalación
Hay dos formas de ejecutar el código al desinstalar un complemento. Puede usar el gancho de desinstalación a través de register_uninstall_hook() o puede usar un archivo uninstall.php dedicado dentro de su complemento. Te mostraré ambos, pero el método preferido es usar el archivo de desinstalación.
El problema principal con el enlace de desinstalación es que “evita que el archivo del complemento principal se ejecute durante la desinstalación, lo que puede ser problemático si el complemento ejecuta código en el espacio global. También es mejor porque el código de desinstalación está centralizado”. –Scott Riley
El siguiente código muestra el proceso de desinstalación utilizando un gancho básico:
Como se ha comentado, esta no es la mejor solución. Una manera mucho mejor de manejar las desinstalaciones es usar el archivo uninstall.php . Todo lo que necesita hacer es crearlo y se utilizará si está disponible.
Como puede ver, esta es en realidad una solución más simple. Lo mejor de todo es que es autónomo.
Seguridad adicional
No quería complicar demasiado los ejemplos mostrados hasta ahora con problemas relacionados con la seguridad, pero realmente debería tomar algunas medidas para asegurarse de que solo aquellos que tienen permiso para hacerlo puedan ejecutar estas acciones.
Use el siguiente fragmento de código en la activación y desactivación:
Este bloque de código se asegura de que el usuario tenga los permisos para realizar esta acción y que la acción se haya originado en la página adecuada. Esto debería proteger contra la mayoría de los intentos maliciosos.
El proceso de desinstalación es especial, por lo que necesitaremos usar un código ligeramente diferente:
Es hora de limpiar
Si su complemento agrega cosas a WordPress, entonces es su deber como desarrollador eliminarlo cuando un usuario decide eliminar su complemento.
El uso de los métodos de activación, desactivación y desinstalación descritos anteriormente le permitirá crear un sistema que lo haga de forma segura. También recomiendo leer este hilo de Stackexchange, que describe estos procesos en entornos OOP.
Si aún no es miembro de WPMU DEV, regístrese hoy para una prueba gratuita, completamente libre de riesgos. Como miembro, obtendrá acceso a todos nuestros excelentes complementos y un servicio de alojamiento ultrarrápido, además de soporte experto las 24 horas del día, los 7 días de la semana para todas sus preguntas y problemas relacionados con WordPress.
Etiquetas: