Ajax impiega 10 volte più tempo del necessario
Mi sono appena imbattuto nel mio primo serio problema con WordPress e, per qualcuno che apprezza Ajax, questo è davvero importante.
Ho una richiesta Ajax che impiega 1,5 secondi per completarsi mentre utilizza l'API Ajax di WordPress.
Se prendo lo stesso identico codice e lo eseguo con uno script personalizzato (senza WordPress), la richiesta Ajax impiega solamente 150 millisecondi. Questo non è un'esagerazione
Se si guarda il primo commento di http://wp.smashingmagazine.com/2011/10/18/how-to-use-ajax-in-wordpress/ e la conversazione che segue, si può vedere che questa lentezza è causata dal fatto che ad ogni richiesta viene caricato tutto WordPress...
Spero che esista una soluzione che renda possibile effettuare richieste Ajax senza caricare l'intero WordPress.
Quali sono le vostre esperienze nell'ottimizzazione delle richieste Ajax con WordPress?

Sì, questo è un problema fastidioso: per avere un ambiente WordPress completo è necessario dedicare un tempo considerevole al suo caricamento.
Per lavoro, avevo bisogno di prestazioni molto migliori (per una funzionalità di ricerca incrementale molto dinamica) e la soluzione che ho adottato è stata:
- Un file personalizzato come gestore Ajax.
- La costante SHORTINIT per un caricamento limitato del core di WP.
- Parti del core caricate in modo molto selettivo, solo quelle necessarie per il compito.
Questo fornisce un ambiente molto limitato, ma le prestazioni sono di gran lunga migliori e si mantiene un ragionevole grado di compatibilità con WP (a partire da $wpdb
).
Ecco l'inizio del mio file di caricamento, non è elegante ma funziona per esigenze specifiche:
<?php
ini_set('html_errors', 0);
define('SHORTINIT', true);
require '../../../../wp-load.php';
require( ABSPATH . WPINC . '/formatting.php' );
require( ABSPATH . WPINC . '/meta.php' );
require( ABSPATH . WPINC . '/post.php' );
wp_plugin_directory_constants();
// roba va qui

Cosa intendi con la costante SHORTINIT? Puoi fornire degli esempi? Immagino che dovrò configurare i miei gestori con diversi livelli di WP caricati a seconda delle necessità della richiesta, ma mi piacerebbe vedere alcuni esempi che hai creato.

@Mike non è molto conosciuto ma è davvero semplice nel concetto - se la costante SHORTINIT
è impostata WP non caricherà la maggior parte del core (niente API/funzioni principali, niente plugin, niente tema). Aggiungerò del codice per rispondere.

Sembra ok. Semplicemente non mi piace il fatto che dobbiamo usare require '../../../../wp-load.php'; questo lo rende piuttosto personalizzato. Mi preoccupa anche quanto sia facile effettivamente includere le risorse di cui hai "bisogno", perché dalla mia esperienza WordPress non è molto modulare.

@Mike corretto, ma anche con i problemi è molto meglio di un endpoint che non ha la minima idea di WP. Questo può (e dovrebbe) essere migliorato ancora un po' ma non è un compito urgente per me al momento.

Esistono metodi per rilevare la posizione di wp-load.php all'interno di WordPress? Ad esempio, potrei scrivere un file statico con il percorso impostato come variabile al suo interno durante il caricamento del plugin, per poi includere quel file nel file di risposta Ajax standalone?

@hereswhatidid sì, quella è una delle opzioni, potresti usare ad esempio get_included_files()
di PHP. Tuttavia nota che scrivere nella directory del plugin non è una buona pratica, in genere le scritture sul filesystem dovrebbero avvenire solo nella directory dei contenuti. Questo è il tipo di problema che non è così difficile da configurare per te stesso, ma è piuttosto complicato produrre una soluzione appropriata per un codice pubblico.

@Rarst, invece di require '../../../../wp-load.php';
penso sia meglio usare qualcosa come: $dir = explode ( 'wp-content', dirname(__FILE__) );
e poi require $dir[0] . 'wp_load.php'
? Penso sia più flessibile e possa essere utilizzato ovunque nel tema o nel plugin

@G.M. la cartella dei contenuti può essere liberamente riposizionata, è un presupposto sbagliato che il codice venga eseguito all'interno della directory principale. Come sopra - è difficile gestirlo in modo generico.

@Rarst, sicuramente la cartella dei contenuti può essere riposizionata, ma se così fosse la tua soluzione può anche fallire, o mi sbaglio? Se nel mio plugin (o tema) ho un file options.php
dove define('WPCONTENTROOTFOLDER', 'wp-content')
e poi $dir = explode ( WPCONTENTROOTFOLDER, dirname(__FILE__) )
questo funzionerà nel 90% dei casi, per il resto scrivo nella documentazione del plugin cosa cambiare se la cartella dei contenuti viene spostata. Ad esempio, posso implementare un'altra costante 'FULLWPCONTENTFOLDER', normalmente vuota ma se impostata il plugin userà questa invece.

@G.M. la mia soluzione è specifica per la mia installazione, non è pensata per codice distribuibile. Il tuo codice semplicemente imposta presupposti diversi (più generici relativamente, concordo), ma personalmente non penso che raggiunga il livello di codice distribuibile neanche quello

@Rarst (ultima cosa, giuro) Sì, probabilmente il mio non è codice distribuibile (sicuramente non nel repository WP e/o per un pubblico ampio), ma penso sia codice riutilizzabile, anche solo per me stesso: al momento ho più di 20 installazioni WP di clienti online e in tutte ci sono plugin sviluppati da me, quindi scrivere codice facilmente riutilizzabile è vitale per me anche se non per codice distribuibile.

Sto usando una versione forkata (privata) di questo plugin trovata su GitHub: http://github.com/EkAndreas/ajaxflow/

Ho trovato questo codice e ha velocizzato le mie richieste AJAX.
function my_deregister_heartbeat() {
global $pagenow;
if ( 'post.php' != $pagenow && 'post-new.php' != $pagenow ) {
wp_deregister_script('heartbeat');
wp_register_script('heartbeat', false);
}
}
add_action( 'admin_enqueue_scripts', 'my_deregister_heartbeat' );
