Lorsque je développe des plugins, je les teste sur plusieurs versions de WordPress en faisant un lien symbolique avec le répertoire de mes plugins dans les différents répertoires wp-content
. C’est formidable, car je n’ai besoin d’éditer les fichiers qu’une seule fois, mais cela rompt une construction importante pour générer des références aux ressources de mon plugin: __FILE__
fait référence à l’emplacement du plugin physique, pas à celui de wp-content
. Comment devrais-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
en tant que lien symbolique vers le plugin ci-dessus3.1-multi-dir/
wp-content/
plugins/
monkeyman-rewrite-analyzer
en tant que lien symbolique vers le plugin ci-dessus3.1-multi-domain/
wp-content/
plugins/
monkeyman-rewrite-analyzer
en tant que lien symbolique vers le plugin ci-dessusSi je veux mettre en file d'attente le fichier Javascript, je devrais utiliser plugins_url( 'monkeyman-rewrite-analyzer.js', [base file] )
, mais utiliser __FILE__
ici ne fonctionnera pas, car le chemin d'accès au fichier actuel sera /path/to/wordpress/development/dir/plugin-development/monkeyman-rewrite-analyzer/monkeyman-rewrite-analyzer.php
et non /path/to/wordpress/development/dir/versions/*/wp-content/plugins/monkeyman-rewrite-analyzer/monkeyman-rewrite-analyzer.php
. Par conséquent, WordPress ne peut pas supprimer la première partie et générer une URL relative à WordPress. installation.
Le problème peut être partiellement résolu avec un plug-in à utiliser dans le filtre plugins_url
.
Il ne gérera pas tous les autres cas où plugin_basename()
est utilisé, tels que register_activation_hook()
et co.
Plus d'infos: http://core.trac.wordpress.org/ticket/16953
J'utilise actuellement une astuce pour obtenir l'emplacement du fichier relatif à WordPress: wp_get_active_and_valid_plugins()
renvoie les chemins d'accès aux fichiers, et wp_settings.php
les parcourt et inclut les fichiers . Ainsi, la variable globale $plugin
fera référence à votre plug-in actuel (bien sûr, uniquement lorsque le plug-in est chargé, je l'enregistre donc dans une variable globale préfixée):
$monkeyman_Rewrite_Analyzer_file = $plugin;
Comme les plugins peuvent également être chargés en tant que plugins must-use ou network et ces boucles utilisent d'autres noms de variable , 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;
}
La solution de remplacement est toujours __FILE__
. Ainsi, si quelqu'un modifie le nom de la variable de boucle à l'avenir, mon code devrait toujours fonctionner pour 99% des installations, seule la configuration de développement échouera et je pourrai facilement publier une nouvelle version.
Un commentaire dans bug 46260 suggère d'utiliser $_SERVER["SCRIPT_FILENAME"]
au lieu de __FILE__
. Est-ce que ça marche?
$_SERVER["SCRIPT_FILENAME"]
fonctionne si vous l'utilisez correctement. Vous devez simplement l'utiliser pour définir un chemin de base, puis inclure vos fichiers en utilisant 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 ceci 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 ajax)