Des child plugins ?

Le concept est utile je pense. Combien de fois j’ai du me brancher sur des plugins comme WP SEO ou des Ads Manager pour des clients.

Parfois même pour mon usage personnel, je trouve un plugin qui va me faire gagner du temps sur les fonctions core et où je n’aurais qu’à mettre en forme.

Pourquoi ?

Le problème est qu’à l’instar des thèmes les plugins se mettent à jour donc je n’ai pas envie de tout refaire à chaque fois. Dans la même veine je n’ai pas forcément envie d’inclure une personnalisation de plugin dans le thème.

Comment ?

Donc je complète tout simplement le plugin en question avec un plugin maison. Et moi j’aime bien appeler ces plugins “plugin name – child”.

Cela permet de juxtaposer naturellement les plugins reliés dans l’admin des extensions l’un en dessous de l’autre, ça c’est pour le côté un peu maniac du dév mais c’est de manière générale pratique sur les installations avec beaucoup de plugins ou sur un multisite par exemple.

Ensuite pour le code, je suis plutôt cette voie pour détecter le plugin parent et utiliser les fonctions qui m’intéressent, puis j’inclue dans le code de mon plugin systématiquement une notice. Cela permet de prévenir les admins qu’il y a un souci avec un des plugins et que cela va affecter également mon plugin qui en dépend.

Conclusion

Finalement ici on créé un autre plugin lambda ou presque mais qui va simplement dépendre d’un autre plugin. Maintenant ce n’est pas toujours valable. Si par exemple vous avez un plugin parent qui est entièrement codé en OOP cela peut-être plus intéressant de passer par les class extends. Cela dit vous devrez tout de même passer par un class_exists() pour éviter l’erreur fatale si le plugin parent est désactivé et que donc la classe que vous étendez n’existe plus.