Por que não registrar códigos de acesso se o painel is_admin?

Percebi que alguns plugins como o Contact-form-7 , Nextgen-gallery , possivelmente outros, têm um interessante recurso anti-registro de não registrar seus códigos de acesso quando isso is_admin()é verdade.

O problema é que, se você deseja gerar algum conteúdo dinâmico (que pode ter código de acesso curto) a partir do ajax e usar a maneira wp "correta" de fazer isso, admin-ajax.php, é impossível não ter o WP_ADMIN verdadeiro. Veja as primeiras linhas do admin-ajax.php:

define( 'DOING_AJAX', true );
if ( ! defined( 'WP_ADMIN' ) ) {
    define( 'WP_ADMIN', true );
}

Agora, parece que existem extensões PHP que permitem desabilitar uma constante definida (hacky), ou pode haver uma maneira de mexer com o sistema WP_Screen não documentado e $GLOBALS['current_screen']tornar o is_admin()retorno da função falso? A solução mais útil parece estar sendo postada na página ou na raiz do site.

É comum que plugins registrem seus códigos de acesso quando is_admin()falsos? Nesse caso, não encontrei nenhuma documentação ou motivo para isso, a não ser que possa ser uma otimização prematura.

Eu observei o mesmo problema com o formulário de contato-7 há algum tempo.

Mas observe que o registro de códigos de acesso com base em is_adminestá doing_it_wrong ( consulte a resposta do gmazzap )

Existem duas razões que parecem legítimas à primeira vista (e por que estão erradas):

1. (Improvável) O autor do plug-in tentou otimizar o script para registrar apenas códigos de acesso quando necessários. Nesse caso, o autor não considerou que o código de acesso possa ser usado nas solicitações do Ajax.

   Errado porque : essa otimização não fornece nenhum ganho de desempenho. Ele simplesmente agrega um valor à matriz global de "códigos de acesso registrados".

2. (Este é o mais provável) O autor do plug-in desabilitou intencionalmente o suporte ao código de acesso nas solicitações do Ajax. Com o Contact-Form-7, esse é possivelmente o caso, pois os formulários podem ser definidos como "Enviar via Ajax". No entanto, esse recurso requer que o formulário carregue arquivos javascript adicionais que não são carregados quando o código curto é analisado via Ajax e o javascript é adicionado via enqueue_scripts().

   O autor decidiu desativar o suporte ao Ajax para evitar relatórios de erros como "Não use isso: o formulário é exibido, mas clicar no botão Enviar não funciona. Conclua a perda de tempo!"

   Portanto, o usuário verá um formulário com garantia de funcionamento ou nenhum formulário.

   Errado porque : procurar is_adminaqui é uma prática ruim. O condicional deve verificar se a constante DOING_AJAXestá definida e verdadeira.

Embora a maioria dos plug-ins não use esse tipo de condição, os poucos que têm essa restrição possivelmente a têm devido a problemas no passado.

Quando um código curto está simplesmente produzindo alguma saída na página, não há motivo para adicionar nenhuma condição de administrador. No entanto, quando o código curto também enfileira arquivos js ou css, faz sentido limitar o uso a solicitações que não são de administrador / não são de ajax.

Na verdade, não há razão para não registrar códigos de acesso no admin.

Se o autor dos plug-ins quiser desativar o formulário de plug-in Ajax, eles deverão fazer

if (defined('DOING_AJAX') && DOING_AJAX)

em vez de procurar por admin.

Observe que, no futuro, é possível que o Shortcake seja incorporado no núcleo porque é um "Plugin de recursos".

Se isso acontecer, o código de acesso não definido em admin não funcionará com ele. Isso confirma outra vez que não há razão para não registrar códigos de acesso no administrador: até os desenvolvedores principais estão trabalhando em itens que exigem códigos de acesso disponíveis no administrador.

Dito isto, você tem possibilidades:

1. entre em contato com o autor dos plug-ins e veja se eles podem corrigir esse comportamento
2. tente encontrar uma solução sozinho

Em relação ao item 2, existem realmente bibliotecas que podem forçar is_admina verdade. Por eles são hackish, e eu nunca usaria aqueles em produção.

Um exemplo é Patchwork .

Usando-o, você pode substituir qualquer função personalizada do PHP.

Em um plugin MU, você pode fazer (completamente UNTESTED):

add_action('muplugins_loaded', function() {
  if ( defined('DOING_AJAX') && DOING_AJAX ) {
     require 'path/to/Patchwork.php';
     Patchwork\replace("is_admin", function() {
        return FALSE;
     });
  }
});

Isso fará com que o is_admin()retorno seja falso em solicitações de ajax.

No entanto, como já foi dito, isso é bastante tolo e afetará o comportamento de outros plugins (e principais) com efeitos imprevisíveis.

Outra coisa que você pode fazer é registrar o manipulador de códigos de acesso do plugin nas solicitações de administrador.

Por exemplo, se o código do plug-in for:

if (! is_admin()) {
  add_shortcode( 'shortcode' , 'plugin_shortcode_handler' );
}

então você pode escrever outro plugin que faça:

if (is_admin()) {
  add_shortcode( 'shortcode' , 'plugin_shortcode_handler' );
}

Dessa forma, o código de acesso será adicionado nos dois casos.

Isso pode ou não funcionar sozinho, dependendo de outro código de plug-in, mas não há uma resposta geral para isso.