Una de las tareas de desarrollo más habituales para el programador WordPress es la modificación y personalización de plugins para crear aplicaciones adaptadas a las necesidades del cliente pero hay muchas maneras de hacerlo mal y muchas de hacerlo bien.
El modo más habitual de hacerlo mal es cualquier variación de modificar el plugin «a pelo«, de añadir, eliminar, modificar el código del plugin y entregárselo a tu cliente tal cual.
Y sí, lo bonito del código abierto, del Open Source, y de que WordPress sea GPL es que siempre tienes ahí el código para modificarlo, pero el problema es que si modificas el plugin y se lo entregas tuneado a un cliente le negarás las actualizaciones del plugin original, generándole un problema de seguridad y otro de pérdida de funcionalidades futuras.
Vale que siempre puedes hacerle tu el mantenimiento del plugin, por un módico precio, pero incluso para ti las actualizaciones serán un infierno, pues tendrás que hacerlas manualmente, revisando cada línea de código, las dependencias con tus modificaciones, etc., etc.
¿Hablamos de plugins hijos?
Índice de contenidos
¿Plugins hijos?
Existe el concepto y desarrollo de temas hijos pero no existe, en principio, el mismo concepto para los plugins, así que no hay tal cosa como lo que podríamos llamar un plugin hijo o un modo estructurado y unificado de hacerlo. Se ha propuesto, pero no ha prosperado de momento.
Quizás el avance más prometedor vino de la parte de Plugin Dependencies, un meta-plugin que ofrece incluso una interfaz desde la que comprobar las dependencias de un plugin hijo sobre uno padre, incluso usando esta terminología. El plugin avisa de las dependencias al activarse e incluso permite desactivar padre e hijo al unísono.
Un ejemplo de uso lo muestran en la misma página del plugin…
/* Plugin Name: BuddyPress Debug Depends: BuddyPress, Debug Bar */
¿Qué hace este plugin hijo?
- Impide que se active BuddyPress Debug si no están antes activos BuddyPress y Debug Bar.
- Cuando se desactiven tanto BuddyPress o Debug Bar, también se desactivará BuddyPress Debug.
El problema es que pocos plugins incluyen información de dependencias, pero la idea es buena, y quizás algún día se desarrolle.
No obstante no es algo tan sencillo como los temas hijo, pues todos tienen una estructura similar, mientras que los plugins son cada uno de su padre y de su madre.
Entonces ¿cómo lo hacemos? Es más ¿se puede?
Pues sí, y hay varios modos de personalizar plugins, vamos a verlos…
Contacta con el desarrollador
De puro obvio a muy poca gente se lo ocurre que no hay manera más sencilla de personalizar un plugin que contactar con el desarrollador, plantearle tus modificaciones y que él mismo las incorpore en una nueva versión, incluso con tu ayuda.
Haz un fork
Otra posibilidad, que puede, y debería, pasar previamente por el método anterior, es hacer tu propia versión del plugin, un fork que incluya aquellas modificaciones que has detectado y quieres añadir.
Lo bueno de este método es que si subes tu fork al directorio oficial de plugins otros usuarios disfrutaremos de tus buenas ideas y trabajo. De paso ganas prestigio en la comunidad y ante tus presentes y futuros clientes.
Lo malo de este método es que adquieres un compromiso en su mantenimiento, algo no siempre posible.
Crear un plugin dependiente con hooks
¡Por fin hemos llegado a algo viable y correcto!
El modo correcto de personalizar un plugin es crear otro plugin hijo dependiente del padre que, mediante hooks personalizados utilice las funciones del padre ampliando o modificando sus funcionalidades.
Y, como ya sabrás, hay dos tipos de hooks o ganchos: action hooks y filter hooks. ¿Vamos a ello?
¿Qué son los action hooks y filter hooks?
Has visto, e incluso utilizado, muchos de ellos. Cada vez que vemos un modo de personalizar WordPress sin modificar los archivos core lo hacemos usando action hooks y filter hooks.
Sí, me refiero a todas las modificaciones y personalizaciones que hacemos mediante nuestro plugin de utilidades o añadiendo funciones personalizadas al archivo functions.php del tema.
Así que si el desarrollador del plugin ya incluyó en su código hooks personalizados estás de enhorabuena. Es una buena práctica de los buenos desarrolladores, aunque no todos aún la utilizan.
Extendiendo un plugin con hooks
Lo único que necesitas hacer es crear un plugin aparte que se ejecute conjuntamente con el plugin que quieres personalizar, y registrar los callbacks para los hooks personalizados que ofrezca el plugin original.
Extendiendo plugins con action hooks
Las acciones son hooks (o ganchos si lo prefieres) que lanza el núcleo de WordPress en puntos específicos de su ejecución, o cuando ocurre algo. Son funciones PHP que se ejecutan en estos puntos de ejecución, ya sea en WordPress, plugins o temas, y permiten personalizar su comportamiento.
Ejemplo:
Function loquesea(){
//cualquier cosa que hagas habitualmente
do_action('Nombre-De-Tu-Action-Hook', $args1,$args2)
//cualquier cosa que hagas habitualmente
}Con esto ya podemos interacturar con la función y usar sus argumentos ($args1,$args2) utilizando el hook ‘Nombre-De-tu-Action-Hook’. Por ejemplo:
add_action('Nombre-De-Tu-Action-Hook','hook_function_callback');Extendiendo plugins con filter hooks
Los filtros son hooks que lanza WordPres para modificar texto u otros elementos antes de añadirlos a la base de datos o enviarlos al navegador. Tu plugin puede especificar que una o más de sus funciones PHP modifiquen tipos específicos de texto.
Veamos un ejemplo de nuevo:
Function loquesea(){
//cualquier cosa que hagas habitualmente
$output = apply_filters('Nombre-De-Tu-Filter-Hook', $output,$args1,$args2)
//cualquier cosa que hagas habitualmente
}Y, como en el caso anterior, ya podremos hacer cosas con esa función, filtrar la $output y usar sus argumentos ($args1,$args2) utilizando tu hook ‘Nombre-De-Tu-Filter-Hook’. Así…
add_filter('Nombre-De-Tu-Filter-Hook','hook_function_callback');Registrando callbacks
Seguramente te habrás fijado en que en los métodos vistos estamos registrando callbacks que reemplazan los del plugin original y los sustituyen por los nuestros.
Luego, en nuestros callbacks llamamos a funciones del otro plugin, el padre, que necesitemos para recrear las partes de sus funcionalidades que queremos ampliar o modificar, y evitamos las partes que no necesitamos.
Conclusión
Como verás, aunque no existe el concepto de plugins hijo como tal, si que es totalmente factible aprovechar las funcionalidades de un plugin original y ampliarlas con nuestro propio plugin que, mediante hooks, aproveche sus funcionalidades base y añada o sustituya aquellas que queramos modificar.
De este modo tendremos nuestro plugin personalizado hijo, dependiente del plugin original padre, que nuestro cliente podrá actualizar normalmente sin que se pierdan las personalizaciones que hayamos añadido.
Solo tenemos que dejar claramente especificado en la documentación la dependencia, para que a nadie se le ocurra desinstalar el plugin padre, como es lógico, o dejarán también de funcionar nuestras personalizaciones, al no ser un plugin independiente, sino dependiente.
¿Ejemplos?
Afortunadamente hay bastantes buenos ejemplos de los que podemos aprender este tipo te técnicas, aquí tienes algunos plugins dependientes:
- Google Authenticator – Per User Prompt (dependiente de Google Authenticator Plugin)
- Contact Form 7 Textarea Wordcount (dependiente de Contact Form 7)
- JetPack Extras (dependiente de JetPack)
Referencias para ampliar conocimientos:
¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!
AVISO: Esta publicación es de hace 3 años o más. Si es un código o un plugin podría no funcionar en las últimas versiones de WordPress, y si es una noticia podría estar ya obsoleta. Luego no digas que no te hemos avisado. ¡Ah! ¿te funciona? pues entonces no he dicho nada :)
