Plugin in directory con link simbolici?

20

Quando sviluppo plug-in, li collaudo su più versioni di WordPress collegando simbolicamente la mia directory di plug-in nelle diverse wp-contentdirectory. Questo è fantastico poiché devo modificare i file solo una volta, ma rompe un costrutto importante per generare riferimenti alle risorse nel mio plugin: si __FILE__riferisce alla posizione fisica del plugin, non a quella in wp-content. Come dovrei risolverlo?

La mia struttura di directory è simile alla seguente:

/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 come link simbolico al plugin sopra
  - 3.1-multi-dir/
    - wp-content/
      - plugins/
        
        monkeyman-rewrite-analyzer come link simbolico al plugin sopra
  - 3.1-multi-domain/
    - wp-content/
      - plugins/
        
        monkeyman-rewrite-analyzer come link simbolico al plugin sopra

Se voglio accodare il file Javascript, dovrei usare plugins_url( 'monkeyman-rewrite-analyzer.js', [base file] ), ma l'uso __FILE__qui non funzionerà, perché il percorso del file effettivo sarà /path/to/wordpress/development/dir/plugin-development/monkeyman-rewrite-analyzer/monkeyman-rewrite-analyzer.php, no /path/to/wordpress/development/dir/versions/*/wp-content/plugins/monkeyman-rewrite-analyzer/monkeyman-rewrite-analyzer.php, quindi WordPress non può eliminare la prima parte e generare un URL relativo all'installazione di WordPress.

plugin-development customization

— Jan Fabry
fonte

6

Il problema può essere parzialmente risolto con un plug-in indispensabile che si collega al plugins_urlfiltro.

Non gestirà tutti gli altri casi in cui plugin_basename()viene utilizzato, come register_activation_hook()e co.

Ulteriori informazioni: http://core.trac.wordpress.org/ticket/16953

— scribu
fonte

Credo che l'uso WP_PLUGIN_URLnon sia raccomandato perché agli amministratori dovrebbe essere permesso di cambiare il nome della directory di questo specifico plugin, ma c'è anche un altro motivo per evitarlo? E infatti, il tuo biglietto sarebbe una soluzione semplice.

— Jan Fabry,

Anzi. WP_PLUGIN_URL contiene solo l'URL che punta direttamente alla directory 'plug-in'. Vedi la risposta aggiornata.

— scribu,

@scribu: Ma cosa succede se i miei plugin vivono /external/folder/banana-plugin/ma l'amministratore si collega a quella directory come /httpd-root/wp-content/plugins/apple-plugin/? Quindi proverà ad andare a /wp-content/plugins/banana-plugin/, no? E credo che l'amministratore debba essere libero di scegliere i nomi delle singole directory dei plugin?

— Jan Fabry,

Non ne parlerò più con te, perché ho trovato la soluzione: il filtro 'plugins_url'. Risposta aggiornata di nuovo.

— scribu,

FWIW questa soluzione può essere soggetta a errori e dipende dagli sviluppatori di plug-in che utilizzano plugins_url () solo dopo aver caricato tutti i plug-in, altrimenti non è possibile registrare un filtro prima che venga chiamata la funzione. il plugin Akismet e molti altri hanno questo problema.

— jerclarke,

3

Attualmente uso un trucco per ottenere la posizione del file relativo a WordPress: wp_get_active_and_valid_plugins()restituisce i percorsi dei file, wp_settings.phpli scorre sopra e include i file . Quindi la $pluginvariabile globale farà riferimento al tuo plugin corrente (ovviamente solo quando il plugin è caricato, quindi lo salvo in una variabile globale con prefisso):

$monkeyman_Rewrite_Analyzer_file = $plugin;

Poiché i plug-in possono anche essere caricati come plug-in indispensabili o plug-in di rete e questi loop utilizzano altri nomi di variabili , il codice completo è simile al seguente:

$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;
}

Il fallback è ancora __FILE__, quindi se in futuro qualcuno cambierà il nome della variabile loop il mio codice dovrebbe funzionare per il 99% di tutte le installazioni, solo la mia configurazione di sviluppo fallirà e potrò rilasciare una nuova versione con facilità.

— Jan Fabry
fonte

Ottima soluzione @Jan. Ho implementato qualcosa di simile chiamando le funzioni e il loop perché ho dimenticato che quelle variabili erano accessibili come global. Grazie al tuo post qui ho capito che avrei potuto renderlo molto più semplice. A proposito, sto anche testando false === strpos( __FILE__, WP_CONTENT_DIR )prima di eseguire le tue istruzioni if perché presumo che il plug-in sia nel WP_CONTENT_DIRlink non simbolizzato; Spero sia una logica valida.

— MikeSchinkel,

0

Un commento nel bug 46260 suggerisce di usare al $_SERVER["SCRIPT_FILENAME"]posto di __FILE__. funziona?

— fuxia
fonte

1

No, questo non cambia nei file inclusi. Quindi, se index.phpcomprende library.php, $_SERVER['SCRIPT_FILENAME']in library.phpsaranno ancora index.php. Ma grazie per il riferimento al bug, lo seguirò da vicino!

— Jan Fabry,

0

$_SERVER["SCRIPT_FILENAME"]funziona se lo usi correttamente. Devi solo usarlo per impostare un percorso di base, quindi includere i tuoi file usando un percorso relativo a quel percorso di base.

Qualcosa di simile a:

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

Nota, questo è più utile quando non hai ancora accesso a wp-blog-header.php (cioè nell'elaborazione di una richiesta di modulo basata su ajax)

— Chad Furman
fonte