Plugins em diretórios com links simbólicos?

20

Quando desenvolvo plugins, eu os testo em várias versões do WordPress, associando o diretório do meu plugin nos diferentes wp-contentdiretórios. Isso é ótimo, pois só preciso editar os arquivos uma vez, mas quebra uma construção importante para gerar referências aos recursos no meu plug-in: __FILE__refere-se ao local do plug-in físico, não ao local wp-content. Como devo resolver isso?

Minha estrutura de diretórios é assim:

/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 como um link simbólico para o plug-in acima
  - 3.1-multi-dir/
    - wp-content/
      - plugins/
        
        monkeyman-rewrite-analyzer como um link simbólico para o plug-in acima
  - 3.1-multi-domain/
    - wp-content/
      - plugins/
        
        monkeyman-rewrite-analyzer como um link simbólico para o plug-in acima

Se eu quiser enfileirar o arquivo Javascript, eu deveria usar plugins_url( 'monkeyman-rewrite-analyzer.js', [base file] ), mas usando __FILE__aqui não vai funcionar, porque o caminho do arquivo real será /path/to/wordpress/development/dir/plugin-development/monkeyman-rewrite-analyzer/monkeyman-rewrite-analyzer.php, não /path/to/wordpress/development/dir/versions/*/wp-content/plugins/monkeyman-rewrite-analyzer/monkeyman-rewrite-analyzer.php, de modo WordPress não pode tirar a primeira parte para fora e gerar uma URL relativa à instalação do WordPress.

plugin-development customization

— Jan Fabry
fonte

6

O problema pode ser parcialmente resolvido com um plug-in obrigatório de usar no plugins_urlfiltro.

Ele não trata de todos os outros casos em que plugin_basename()é usado, como register_activation_hook()e co.

Mais informações: http://core.trac.wordpress.org/ticket/16953

— scribu
fonte

Eu acredito que o uso WP_PLUGIN_URLnão é recomendado porque os administradores devem ter permissão para alterar o nome do diretório deste plug-in específico, mas há outro motivo para evitá-lo? E, de fato, seu ingresso seria uma solução simples.

— Jan Fabry

Pelo contrário. WP_PLUGIN_URL contém apenas o URL que aponta diretamente para o diretório 'plugins'. Veja a resposta atualizada.

— Scrib:

@ scribu: Mas e se meus plugins residirem, /external/folder/banana-plugin/mas o administrador vincular esse diretório como /httpd-root/wp-content/plugins/apple-plugin/? Então ele tentará ir /wp-content/plugins/banana-plugin/, não? E acredito que o administrador deve ser livre para escolher os nomes de diretório de plugins individuais?

— Jan Fabry

Não vou mais discutir com você sobre isso, porque encontrei a solução: o filtro 'plugins_url'. Resposta atualizada novamente.

— scribu

FWIW, esta solução pode estar sujeita a erros e depende dos desenvolvedores de plug-ins usando apenas plugins_url () após o carregamento de todos os plug-ins; caso contrário, você não poderá registrar um filtro antes que a função seja chamada. o plugin Akismet e muitos outros têm esse problema.

— jerclarke

3

Atualmente, uso um truque para obter o local do arquivo relativo ao WordPress: wp_get_active_and_valid_plugins()retorna os caminhos do arquivo, wp_settings.phppassa-os por cima e inclui os arquivos . Portanto, a $pluginvariável global se refere ao seu plug-in atual (é claro apenas quando o plug-in é carregado, então eu o salvo em uma variável global prefixada):

$monkeyman_Rewrite_Analyzer_file = $plugin;

Como os plug-ins também podem ser carregados como plug-ins obrigatórios ou de rede e esses loops usam outros nomes de variáveis , o código completo se parece com o seguinte:

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

O fallback ainda é __FILE__, portanto, se alguém alterar o nome da variável de loop no futuro, meu código ainda funcionará em 99% de todas as instalações, apenas minha instalação de desenvolvimento falhará e eu posso lançar uma nova versão com facilidade.

— Jan Fabry
fonte

Ótima solução @Jan. Eu implementei algo semelhante chamando as funções e fazendo um loop porque esqueci que essas variáveis estavam acessíveis como global. Graças ao seu post aqui, percebi que poderia torná-lo muito mais simples. BTW, eu também estou testando false === strpos( __FILE__, WP_CONTENT_DIR )antes de executar suas instruções if porque estou assumindo que o plug-in está no WP_CONTENT_DIRnão está vinculado; Espero que seja lógica válida.

— 21812 Mike12:

0

Um comentário no bug 46260 sugere usar em $_SERVER["SCRIPT_FILENAME"]vez de __FILE__. Isto funciona?

— fuxia
fonte

11

Não, isso não muda nos arquivos incluídos. Então, se index.phpinclui library.php, $_SERVER['SCRIPT_FILENAME']em library.phpainda será index.php. Mas obrigado pela referência ao bug, eu o seguirei de perto!

— Jan Fabry

0

$_SERVER["SCRIPT_FILENAME"]funciona se você usá-lo corretamente. Você só precisa usá-lo para definir um caminho base e, em seguida, incluir seus arquivos usando um caminho relativo a esse caminho base.

Algo como:

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

Observe que isso é mais útil quando você ainda não tem acesso ao wp-blog-header.php (por exemplo, no processamento de uma solicitação de formulário baseada no Ajax)

— Chad Furman
fonte