Remarque: Cette réponse est juste là pour faciliter la discussion entre @scribu et @kaiser. Mods: veuillez ne pas supprimer. Utilisateurs / lecteurs: veuillez ne pas voter. Si vous souhaitez suivre la discussion, consultez le journal de révision / édition. Si vous souhaitez participer à la discussion, modifiez la réponse. Si la discussion a un résultat, il sera marqué comme tel. Je vous remercie.
Scénarios
Il existe également différents scénarios qui pèsent différemment, où vous pourriez avoir une dépendance de plugin. (Les exemples ne sont que fictifs). Le mot "(parent) Plugin" peut être échangé avec "Theme" du point de vue parent.
- (difficile) Un plugin enfant qui étend uniquement les fonctionnalités ou modifie l'affichage (et similaire) d'un plugin existant et ne peut donc pas exister sans le parent. Exemple: BuddyPress »BuddyPress-FunkyCommentDisplay
- (normal) Un plugin qui a des fonctionnalités étendues lorsqu'un plugin enfant est activé. Exemple: jQueryAttachmentCarousel »jQuerySlideDeck
- (soft) Un plugin qui ajoute juste une fonctionnalité. Exemple: DisneyWonderlandTheme »MickeysSocialLinks
Dans ce qui suit, j'essaie d'esquisser ce qui se passe lorsque vous mettez à jour le "autre" plugin et que la vérification ne fonctionne plus.
- Annonce 1) Le plugin ne pourrait pas exister sans BuddyPress activé »Les choses sont complètement cassées.
- Annonce 2) Le plugin ne pouvait pas offrir la possibilité de passer du carrousel à SlideDeck »Affiche câblé (je suppose que les styles sont modifiés en SlideDeck).
- Annonce 3) Les liens sociaux Mickeys disparaissent.
Vérifier
Il existe trois possibilités de vérification, si vous souhaitez savoir si un plugin est actif:
- A. Le dossier existe-t-il?
- B. Le fichier principal - option
'active_plugins'
- existe-t-il?
- C. Existe-t-il une fonction particulière?
Si je prends maintenant mon plugin Internal Link Checker comme exemple, qui n'offre aucune API publique et n'est pas destiné à être étendu, je ne verrais aucune raison (en tant qu'auteur) de ne pas changer le nom des fonctions internes à la demande ou simplement à volonté. . Donc, si quelqu'un essayait de se greffer sur ce plugin, alors les choses se briseraient simplement (selon la fonctionnalité et l'étroitesse du regroupement) à la mise à jour. Il en va de même pour les noms de fichiers. Je n'aurais aucune raison réelle (à part que le plugin serait désactivé lors de la mise à jour) de ne pas changer le nom du fichier. La seule chose qui m'empêcherait de changer le nom du dossier est que la vérification et la notification de la mise à jour s'exécutent par rapport au nom du fichier - s'il est hébergé dans le référentiel officiel.
Je dirais donc que la partie la plus faible (facile à changer) à la plus difficile (beaucoup parlent contre le changement) d'un plugin (parent) serait:
fonction »nom du fichier principal» dossier
Quand j'ai dit qu'une vérification de fonction est moins fragile que l'utilisation, is_plugin_active()
j'ai supposé que la fonction en question est celle que l'auteur du plugin encourage explicitement. L'exemple ultime de ceci serait la wp_pagenavi()
balise de modèle offerte par le plugin WP-PageNavi.
La difficulté de définir des dépendances est qu'il n'existe aucun moyen standard d'identifier de manière unique les plugins qui n'impliquent pas de noms de fichiers.
Plus de réflexions sur le sujet:
http://wordpress.org/support/topic/plugin-plugin-dependencies-unreliable-plugin-namingidentifying-scheme
Je suppose que nous pouvons jusqu'à présent le résumer en trois points:
- Nous avons parlé de sujets légèrement différents
- Nous convenons qu'il n'y a pas de moyen à toute épreuve de contourner ce que je pensais que le sujet serait
- D'après votre compréhension de la question, vous avez proposé un chemin valide
La manière la plus intelligente (jusqu'à présent) à laquelle je peux penser, que j'ai déjà vue dans certains plugins (beaucoup moins):
// inside the plugin file:
add_action( 'plugin_custom_hook', 'plugin_trigger' );
// inside some template:
do_action( 'plugin_custom_hook' );
Sans trop y penser en détail, mais je suppose que vous pouvez accrocher votre avis dans un filtre sur 'tous' et vérifier à l' intérieur du filtre actuel s'il a été déclenché lorsque vous êtes shutdown
accroché ...?
L'utilisation de hooks fonctionnerait bien pour les dépendances «normales» et «faibles». Le seul inconvénient est que vous devrez toujours utiliser function_exists()
ou is_plugin_active()
si vous souhaitez arrêter si la dépendance n'est pas remplie. Utiliser le filtre «tout» pour cela serait trop cher à l'OMI.
@scibu Cela visait "votre" sujet. (J'ai déjà arrêté de parler du mien). :)
Donc, fondamentalement, si vous avez besoin d'une dépendance - et que vous avez un bon auteur - alors il pourrait offrir un crochet à la place / en remplacement d'une balise de modèle. Parce que le plugin ne s'y accrocherait que si le crochet était présent, ou ne faisait simplement rien. Et de l'autre côté, vous n'auriez pas d'erreur, lorsque les plugins ne sont pas présents.
Voici la partie difficile (ou plus d'un Q): Pour rédiger un avis administrateur pour informer l'utilisateur de la dépendance "Vous devez installer» DisneyWonderLinks «", vous pouvez vérifier le array_keys( $GLOBALS['wp_filter']['template_tag_like_hook'] )
. Je ne sais pas si cela fonctionnerait, mais afaik le tableau devrait être accessible des deux côtés (public / admin).
Ça ne marcherait pas. Le fait qu'un rappel soit enregistré sur un hook ne signifie pas que le hook sera déclenché lorsque prévu. La seule chose qui ferait une sorte de travail est d'utiliser le hook 'shutdown', que vous avez mentionné précédemment:
add_action( 'shutdown', function() {
if ( !did_action( 'template_tag_like_hook' ) )
echo 'Problem.';
} );
Bien sûr, cela serait imprimé tout en bas, après la </html>
balise, sur le front-end (car c'est là que les balises de modèle sont normalement utilisées), ce qui n'est pas très utile.
Vous pouvez essayer de stocker le message dans wp_options puis l'afficher dans la zone d'administration, mais cela ouvrirait une toute nouvelle boîte de vers: invalidation, mise en cache des plugins, etc.
function_exists
, un utilisateur normal recevra simplement le message indiquant qu'il n'a pas installé le plug-in sur lequel un autre plug-in s'appuie. Le problème est que l'utilisateur aura réellement installé le plugin et se demandera alors pourquoi cela ne fonctionne pas . Oh, et je ne vais pas vous déprécier pour ça.