Perché non registrare codici brevi se is_admin dashboard?

Ho notato che alcuni plugin come Contact-form-7 , Nextgen-gallery , forse altri, hanno un'interessante funzionalità anti-registrazione di non registrare i loro codici brevi quando is_admin()è vero.

La cosa problematica è che se vuoi generare del contenuto dinamico (che può avere shortcode) da ajax e usare il modo wp "corretto" per farlo, admin-ajax.php, è impossibile non avere WP_ADMIN vero. Vedi le prime righe di admin-ajax.php:

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

Ora, sembra che ci siano estensioni PHP che ti permetteranno di annullare l'impostazione di una costante definita (hacky), o potrebbe esserci un modo per pasticciare con il sistema WP_Screen non documentato e $GLOBALS['current_screen']per rendere la is_admin()funzione restituire false ?? La soluzione più utilizzabile sembra essere la pubblicazione nella pagina o nella radice del sito.

È comune per i plugin registrare i loro codici brevi quando is_admin()è falso? In tal caso, non sono riuscito a trovare alcuna documentazione o motivo per questo se non che potrebbe essere un'ottimizzazione prematura.

Ho riscontrato lo stesso problema con contact-form-7 qualche tempo fa.

Ma nota che la registrazione di codici brevi in base a is_adminsta facendo it_it_wrong ( vedi la risposta di gmazzap )

Ci sono due motivi che sembrano legittimi a prima vista (e perché sono sbagliati):

1. (Improbabile) L'autore del plugin ha cercato di ottimizzare lo script per registrare i codici brevi solo quando sono necessari. In questo caso l'autore non ha ritenuto che lo shortcode potesse essere utilizzato nelle richieste Ajax.

   Sbagliato perché : questa ottimizzazione non fornisce alcun miglioramento delle prestazioni. Aggiunge semplicemente un valore alla matrice globale "shortcode registrati".

2. (Questo è il più probabile) L'autore del plugin ha disabilitato intenzionalmente il supporto per lo shortcode nelle richieste Ajax. Con Contact-Form-7 questo è probabilmente il caso perché i moduli possono essere impostati su "Invia tramite Ajax". Tuttavia, questa funzione richiede che il modulo carichi file javascript aggiuntivi che non vengono caricati quando lo shortcode viene analizzato tramite Ajax e javascript viene aggiunto tramite enqueue_scripts().

   L'autore ha deciso di disabilitare il supporto Ajax per impedire la segnalazione di bug come "Non utilizzare questo: il modulo viene visualizzato ma facendo clic sul pulsante Invia non funziona. Completa perdita di tempo!"

   Quindi l'utente vedrà un modulo funzionante o nessun modulo.

   Sbagliato perché : controllare is_adminè una cattiva pratica qui. Il conditon dovrebbe verificare se la costante DOING_AJAXè definita e vera.

Sebbene la maggior parte dei plug-in non utilizzi questo tipo di condizione, i pochi che hanno questa limitazione potrebbero averlo a causa di problemi in passato.

Quando uno shortcode sta semplicemente eseguendo un output sulla pagina non c'è motivo di aggiungere alcuna condizione di amministrazione. Tuttavia, quando lo shortcode accoda anche i file js o css, ha senso limitare l'utilizzo a richieste non amministrative / non Ajax.

In realtà, non vi è alcun motivo per non registrare codici brevi sull'amministratore.

Se l'autore dei plug-in desidera disabilitare il plug-in Ajax, dovrebbero farlo

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

invece di controllare è admin.

Si noti che in futuro è possibile che Shortcake sia incorporato nel core perché è un "plug-in di funzionalità".

In tal caso, lo shortcode non definito nell'amministratore non funzionerà con esso. Questo ti dà un'altra conferma che non c'è motivo per non registrare shortcode su admin: anche gli sviluppatori core stanno lavorando su cose che richiedono shortcode disponibili su admin.

Detto questo, devi avere possibilità:

1. contattare l'autore dei plugin e vedere se sono in grado di correggere quel comportamento
2. prova a trovare una soluzione da solo

Per quanto riguarda il n. 2, esistono effettivamente librerie che possono forzare is_adminad essere vere. Con loro sono hacker e non li userei mai in produzione.

Un esempio è Patchwork .

Usandolo puoi sovrascrivere qualsiasi funzione personalizzata di PHP.

In un plug-in MU puoi fare (completamente NON TESTATO):

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

Questo renderà il is_admin()ritorno falso su richieste Ajax.

Tuttavia, come detto, questo è piuttosto hacker e influenzerà il comportamento di altri plugin (e core) con effetti imprevedibili.

Un'altra cosa che puoi fare è registrare il gestore di shortcode del plugin su richieste di amministrazione.

Ad esempio se il codice del plugin è:

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

allora si può scrivere un altro plugin che fa:

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

In questo modo il codice funzione verrà aggiunto in entrambi i casi.

Questo potrebbe funzionare o meno da solo a seconda dell'altro codice plugin, ma non esiste una risposta generale a questo.