Des plugins dans des répertoires à liens symboliques?

20

Lorsque je développe des plugins, je les teste sur plusieurs versions de WordPress en créant un lien symbolique vers mon répertoire de plugins dans les différents wp-contentrépertoires. C'est génial car je n'ai à modifier les fichiers qu'une seule fois, mais cela casse une construction importante pour générer des références aux ressources dans mon plugin: __FILE__fait référence à l'emplacement physique du plugin, pas celui de wp-content. Comment dois-je résoudre ce problème?

Ma structure de répertoire ressemble à ceci:

  • /path/to/wordpress/development/dir/
    • plugin-development/
      • monkeyman-rewrite-analyzer/
        • monkeyman-rewrite-analyzer.php
        • js/
          • monkeyman-rewrite-analyzer.js
    • versions/
      • 3.1/
        • wp-content/
          • plugins/
            • monkeyman-rewrite-analyzer comme lien symbolique vers le plugin ci-dessus
      • 3.1-multi-dir/
        • wp-content/
          • plugins/
            • monkeyman-rewrite-analyzer comme lien symbolique vers le plugin ci-dessus
      • 3.1-multi-domain/
        • wp-content/
          • plugins/
            • monkeyman-rewrite-analyzer comme lien symbolique vers le plugin ci-dessus

Si je veux mettre le fichier Javascript en file d'attente, je devrais utiliser plugins_url( 'monkeyman-rewrite-analyzer.js', [base file] ), mais l'utilisation __FILE__ici ne fonctionnera pas, car le chemin d'accès au fichier sera /path/to/wordpress/development/dir/plugin-development/monkeyman-rewrite-analyzer/monkeyman-rewrite-analyzer.php, non /path/to/wordpress/development/dir/versions/*/wp-content/plugins/monkeyman-rewrite-analyzer/monkeyman-rewrite-analyzer.php, donc WordPress ne peut pas supprimer la première partie et générer une URL relative à l'installation de WordPress.

plugin-development customization Jan Fabry
la source

Réponses:

6

Le problème peut être partiellement résolu avec un plugin indispensable à accrocher dans le plugins_urlfiltre.

Il ne gérera pas tous les autres cas où il plugin_basename()est utilisé, comme register_activation_hook()et co.

Plus d'informations: http://core.trac.wordpress.org/ticket/16953

scribu
la source
Je crois que l'utilisation WP_PLUGIN_URLn'est pas recommandée car les administrateurs devraient être autorisés à changer le nom du répertoire de ce plugin spécifique, mais y a-t-il également une autre raison de l'éviter? Et en effet, votre ticket serait une solution simple.
Jan Fabry
Au contraire. WP_PLUGIN_URL contient uniquement l'URL qui pointe directement vers le répertoire 'plugins'. Voir la réponse mise à jour.
scribu
@scribu: Mais que se passe-t-il si mes plugins existent mais que /external/folder/banana-plugin/l'administrateur est lié à ce répertoire /httpd-root/wp-content/plugins/apple-plugin/? Ensuite, il essaiera d'aller vers /wp-content/plugins/banana-plugin/, non? Et je crois que l'administrateur devrait être libre de choisir les noms de répertoire des plugins individuels?
Jan Fabry
Je ne discuterai plus de cela avec vous, car j'ai trouvé la solution: le filtre 'plugins_url'. Réponse mise à jour à nouveau.
scribu
FWIW, cette solution peut être sujette aux erreurs et dépend des développeurs de plugins qui n'utilisent plugins_url () qu'après le chargement de tous les plugins, sinon vous ne pouvez pas enregistrer un filtre avant l'appel de la fonction. le plugin Akismet et beaucoup d'autres ont ce problème.
jerclarke
3

J'utilise actuellement une astuce pour obtenir l'emplacement du fichier relatif à WordPress: wp_get_active_and_valid_plugins()retourne les chemins d'accès aux fichiers, les wp_settings.phpboucle et inclut les fichiers . Ainsi, la $pluginvariable globale fera référence à votre plugin actuel (bien sûr uniquement lorsque le plugin est chargé, donc je l'enregistre dans une variable globale préfixée):

$monkeyman_Rewrite_Analyzer_file = $plugin;

Étant donné que les plugins peuvent également être chargés en tant que plugins à utiliser ou réseau et que ces boucles utilisent d'autres noms de variables , le code complet ressemble à ceci:

$monkeyman_Rewrite_Analyzer_file = __FILE__;
if ( isset( $mu_plugin ) ) {
    $monkeyman_Rewrite_Analyzer_file = $mu_plugin;
}
if ( isset( $network_plugin ) ) {
    $monkeyman_Rewrite_Analyzer_file = $network_plugin;
}
if ( isset( $plugin ) ) {
    $monkeyman_Rewrite_Analyzer_file = $plugin;
}

Le remplacement est toujours __FILE__, donc si quelqu'un change le nom de la variable de boucle à l'avenir, mon code devrait toujours fonctionner pour 99% de toutes les installations, seule ma configuration de développement échouera et je peux facilement publier une nouvelle version.

Jan Fabry
la source
Grande solution @Jan. J'ai implémenté quelque chose de similaire en appelant les fonctions et en boucle car j'ai oublié que ces variables étaient accessibles en tant que global. Grâce à votre message ici, j'ai réalisé que je pouvais le rendre beaucoup plus simple. BTW, je teste également false === strpos( __FILE__, WP_CONTENT_DIR )avant d'exécuter vos instructions if car je suppose que si le plugin est dans le, WP_CONTENT_DIRil n'est pas lié par un lien symbolique; J'espère que c'est une logique valable.
MikeSchinkel
0

Un commentaire dans le bug 46260 suggère d'utiliser à la $_SERVER["SCRIPT_FILENAME"]place de __FILE__. Est-ce que ça marche?

fuxia
la source
1
Non, cela ne change pas dans les fichiers inclus. Donc, si index.phpinclut library.php, $_SERVER['SCRIPT_FILENAME']en library.phpsera toujours index.php. Mais merci pour la référence au bug, je vais le suivre de près!
Jan Fabry
0

$_SERVER["SCRIPT_FILENAME"]fonctionne si vous l'utilisez correctement. Il vous suffit de l'utiliser pour définir un chemin de base, puis d'inclure vos fichiers à l'aide d'un chemin relatif à ce chemin de base.

Quelque chose comme:

$plugin_dir = dirname($_SERVER["SCRIPT_FILENAME"]);
$myFile = $plugin_dir."/includes/js/myJavascriptFile.js";

Notez que cela est plus utile lorsque vous n'avez pas encore accès à wp-blog-header.php (c'est-à-dire lors du traitement d'une demande de formulaire basée sur ajax)

Chad Furman
la source