¿Complementos en directorios con enlaces simbólicos?

19

Cuando desarrollo complementos, los pruebo en varias versiones de WordPress al vincular mi directorio de complementos en los diferentes directorios wp-content . Esto es genial ya que solo tengo que editar los archivos una vez, pero rompe una construcción importante para generar referencias a los recursos en mi complemento: __FILE__ se refiere a la ubicación física del complemento, no a la que está en wp-content . ¿Cómo debo resolver esto?

Mi estructura de directorios se ve así:

  • %código%
    • %código%
      • %código%
        • /path/to/wordpress/development/dir/
        • %código%
          • plugin-development/
    • %código%
      • %código%
        • %código%
          • %código%
            • monkeyman-rewrite-analyzer/ como un enlace simbólico al complemento anterior
      • %código%
        • %código%
          • %código%
            • monkeyman-rewrite-analyzer.php como un enlace simbólico al complemento anterior
      • %código%
        • %código%
          • %código%
            • js/ como un enlace simbólico al complemento anterior

Si quiero poner en cola el archivo Javascript, debería usar monkeyman-rewrite-analyzer.js , pero usar versions/ aquí no funcionará, porque la ruta real del archivo será 3.1/ , no wp-content/ , por lo que WordPress no puede eliminar el primera parte y genere una URL relacionada con la instalación de WordPress.

    
pregunta Jan Fabry 20.04.2011 - 12:13

4 respuestas

6

El problema se puede solucionar parcialmente con un complemento de uso obligatorio que se enlaza al filtro plugins_url .

No manejará todos los demás casos en los que se use plugin_basename() , como register_activation_hook() y co.

Más información: enlace

    
respondido por el scribu 20.04.2011 - 12:56
3

Actualmente utilizo un truco para obtener la ubicación relativa del archivo de WordPress: wp_get_active_and_valid_plugins() devuelve las rutas del archivo, y wp_settings.php hace un bucle sobre ellos e incluye los archivos . Por lo tanto, la variable global $plugin se referirá a su complemento actual (por supuesto, solo cuando se carga el complemento, así que lo guardo en una variable global con prefijo):

$monkeyman_Rewrite_Analyzer_file = $plugin;

Porque los complementos también pueden cargarse como complementos de uso obligatorio o de red y estos bucles usan otros nombres de variables , el código completo tiene este aspecto:

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

El respaldo sigue siendo __FILE__ , así que si alguien cambia el nombre de la variable de bucle en el futuro, mi código aún debería funcionar para el 99% de todas las instalaciones, solo la configuración de mi desarrollo fallará y puedo lanzar una nueva versión con facilidad.

    
respondido por el Jan Fabry 20.04.2011 - 12:22
0

Un comentario en bug 46260 sugiere usar $_SERVER["SCRIPT_FILENAME"] en lugar de __FILE__ . ¿Funciona esto?

    
respondido por el fuxia 20.04.2011 - 12:22
0

$_SERVER["SCRIPT_FILENAME"] funciona si lo usas correctamente. Solo tiene que usarlo para establecer una ruta base, y luego incluir sus archivos usando una ruta relativa a esa ruta base.

Algo como:

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

Tenga en cuenta que esto es más útil cuando todavía no tiene acceso a wp-blog-header.php (es decir, al procesar una solicitud de formulario basada en ajax)

    
respondido por el Chad Furman 24.03.2012 - 17:06

Lea otras preguntas en las etiquetas