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

10

Tenho notado que alguns plugins como Contact-form-7 , Nextgen-gallery , possivelmente outros, têm um anti-recurso interessante de não registrar seus códigos de acesso quando is_admin() for verdadeiro.

A coisa problemática é, se você quer gerar algum conteúdo dinâmico (que pode ter shortcode) do ajax, e usar o modo "correto" do wp, admin-ajax.php, é impossível não ter WP_ADMIN seja verdadeiro. Veja as primeiras linhas de admin-ajax.php:

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

Agora, parece que existem extensões PHP que permitem que você desabilite uma constante definida (hacky), ou pode haver uma maneira de mexer com o sistema WP_Screen não documentado e $GLOBALS['current_screen'] fazer com que is_admin() function retorne false ?? A solução mais útil parece estar postando na página ou na raiz do site.

É comum os plugins registrarem seus códigos de acesso quando is_admin() é falso? Em caso afirmativo, não consegui encontrar nenhuma documentação ou razão para isso, a não ser que possa ser uma otimização prematura.

    
por NoBugs 21.05.2015 / 07:21

2 respostas

6

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_admin é doing_it_wrong ( veja a resposta do gmazzap )

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

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

    Errado porque : essa otimização não fornece nenhum ganho de desempenho. Ele simplesmente adiciona um valor ao array "shortcodes registrados" global.

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

    O autor decidiu desativar o suporte do Ajax para evitar relatórios de bugs como "Não use isto: o formulário é exibido, mas clicar no botão Enviar não funciona. Perda de tempo completa!"

    Assim, o usuário verá um formulário de trabalho garantido ou nenhum formulário.

    Errado porque : Verificar is_admin é uma má prática aqui. A condição deve verificar se a constante DOING_AJAX está definida e verdadeira.

Embora a maioria dos plugins não use esse tipo de condição, os poucos que têm essa restrição possivelmente a têm por causa de problemas no passado.

Quando um shortcode está simplesmente fazendo alguma saída na página, não há razão para adicionar qualquer condição de administrador. No entanto, quando o shortcode também enfileira arquivos js ou css, faz sentido limitar o uso a solicitações não administrativas / não-ajax.

    
por Philipp 23.05.2015 / 17:37
3

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

Se o autor do plug-in quiser desativar o formulário de plug-in Ajax, ele deverá fazer

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

em vez de verificar se é admin.

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

Se isso acontecer, o shortcode não definido no admin não funcionará com ele. Isso dá a você outra confirmação de que não há motivo para não registrar códigos de acesso no administrador: até mesmo os desenvolvedores principais estão trabalhando em coisas que exigem códigos de acesso disponíveis no administrador.

Dito isto, você tem que 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

Com relação ao nº 2, existem bibliotecas que podem forçar o is_admin a ser verdadeiro. Por eles são hackish, e eu nunca usaria aqueles em produção.

Um exemplo é Patchwork .

Ao usá-lo, você pode sobrescrever qualquer função personalizada do PHP.

Em um plug-in 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 is_admin() retorne false em solicitações de ajax.

No entanto, como foi dito, isso é bastante agressivo e afetará o comportamento de outros plug-ins (e principais) com efeitos imprevisíveis.

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

Por exemplo se o código do plugin é:

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

então você pode escrever outro plugin que:

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

Desta forma, o código de acesso será adicionado em ambos os casos.

Isso pode ou não funcionar sozinho, dependendo do código do outro plugin, mas não há uma resposta geral para isso.

    
por gmazzap 24.05.2015 / 11:12