web-dev-qa-db-fra.com

Plugins dans les répertoires symlink?

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-dessus
      • 3.1-multi-dir/
        • wp-content/
          • plugins/
            • monkeyman-rewrite-analyzer en tant que lien symbolique vers le plugin ci-dessus
      • 3.1-multi-domain/
        • wp-content/
          • plugins/
            • monkeyman-rewrite-analyzer en tant que lien symbolique vers le plugin ci-dessus

Si 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.

20
Jan Fabry

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

6
scribu

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.

3
Jan Fabry

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

0
fuxia

$_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)

0
Chad Furman