Mida tähendab WordPressi kasutamine puhverserverina?

Kui olete WordPressiga kaua töötanud, eriti mis puudutab teatud tüüpi Ajaxi funktsioonide kasutamist, siis olete tõenäoliselt mingil hetkel kuulnud fraasi "kasuta WordPressi puhverserverina".

Ja isegi kui teil pole tõenäosust, et olete seda tegelikult teinud, on üsna kõrge.

Kuigi ma arvan, et aja möödudes näeme lõpuks, et REST API asendab traditsioonilised viisid, mida oleme Ajaxi kasutanud, kuid see on tõenäoliselt teine ​​​​lugu.

Mida tähendab WordPressi kasutamine puhverserverina alati, kui töötate Ajaxi taotlustega? See nõuab pisut arusaamist saidiülestest päringutest, päringu marsruutimisest WordPressi kaudu ja seejärel vastuse sõelumisest.

Kasutage puhverserverina WordPressi

See on natuke pikk postitus, kas pole? Selle asemel proovin selle lühemaks jaotada, et saaksite seda lugeda ja seejärel tööle naasta.

Puhverserverina

Esiteks võtke puhverserveri määratlus :

volitused kedagi teist esindada, eriti hääletamisel

Kui klõpsate ülaloleval lingil, märkate, et on veel mõned määratlused, kuid ükski neist ei ole tegelikult piisav. Selle asemel meeldib mulle mõelda neile natuke abstraktsemalt, vähemalt mis puudutab tarkvara.

Selle postituse jaoks oletame, et WordPress on päringu puhverserver, mis tähendab, et see vastutab päringu alguse ja sellele vastuse vahelise vahendajana.

Lühidalt,

WordPress toimib puhverserverina, suunates päringu teise teenusesse ja jäädvustades selle vastuse.

Võib-olla olete midagi sarnast kuulnud, võib-olla mitte. Sellest hoolimata võib see kõrgel tasemel välja näha järgmiselt:

Nüüd, kui teil on vaja esitada asünkroonne taotlus (või Ajaxi päring, nagu ma kasutan selle postituse ülejäänud osas), on teil üks kahest võimalusest.

1. esitage taotlus lehele, mis eksisteerib WordPressis,
2. esitage päring teisel domeenil asuvale lehele.

Kui esitate päringuid teie rakenduses (loe: WordPressis) olemasolevatele lehtedele, pole teil probleeme.

Taotluste turvalisuse kohta

Kuid Ajaxi päringute tegemine väljaspool oma domeeni on keelatud. Seda seetõttu, et see on mõeldud XSS -i ja CSRF -i kaitsmiseks .

Lühidalt, igaüks neist viitab vastavalt järgmisele:

XSS-rünnakud ilmnevad siis, kui ründaja kasutab veebirakendust pahatahtliku koodi saatmiseks, tavaliselt brauseripoolse skripti kujul, teisele lõppkasutajale.

ja:

Cross-Site Request Forgery (CSRF) on rünnak, mis sunnib lõppkasutajat sooritama soovimatuid toiminguid veebirakenduses, milles ta on praegu autentitud.

Lühidalt, sellepärast peame puhverserverina kasutama WordPressi. Loomulikult tekitab see aga küsimuse, kuidas?

WordPressi kasutamine puhverserverina

Selleks vajate mitut asja:

1.  leht, millelt teie Ajaxi päring saab päringuid teha,
2. funktsioon ajaxi päringu püüdmiseks ja õigele URL-ile saatmiseks,
3. viis serveri poolel vastuse sõelumiseks,
4. funktsioon andmete tagastamiseks algsele Ajaxi funktsioonile.

Jällegi, ruumi huvides, ma ei esita selle kohta põhjalikku näidet, kuid sellest peaks piisama, et alustada.

Esiteks peate veenduma, et teil on Ajaxi päringu püüdmiseks määratud funktsioon. Codexis on selle kohta juba palju dokumentatsiooni. Selle lihtne näide näeks välja selline:

var _get_columns = function() {

    // Don't forget to use a nonce or security value here.
    var data = {
        'action':   'get_all_columns'
            'security': '<?php echo wp_create_nonce( "acme-security-ajax-nonce" ); ?>'
    };

    // TODO Check for error logging if the response value doesn't exist.
    $.get( ajaxurl, data, function( response) {

        response = $.parseJSON( response );
        // Your custom functionality here
    });
};

Järgmiseks vajate serveris lehte, et esitada päring teie andmeid sisaldavale URL-ile. Seda saab teha kasutades cURL -i, seda saab teha faili_get_contents abil ja seda saab teha mõnel muul viisil.

Kuna ma ei tea ega taha ettekirjutavat näidet tuua, jagan väga lihtsat demo selle kohta, kuidas see võiks toimida (vähemalt algstaadiumis ):

<?php

add_action( 'wp_ajax_get_all_data', 'get_all_data' );
/**
 * Retrieves the requested data from the specified URL 
 * returns the values in JSON.
 */
function get_all_data() {

  // Note $url is up to you.
  $curl = curl_init( $url );

  curl_setopt( $curl, CURLOPT_RETURNTRANSFER, 1 );                         
  curl_setopt( $curl, CURLOPT_HTTPAUTH, CURLAUTH_ANY );                    
  curl_setopt( $curl, CURLOPT_SSL_VERIFYPEER, false );                          
  curl_setopt( $curl, CURLOPT_FOLLOWLOCATION, true );                           

  $response     = curl_exec( $curl );                                          
  $resultStatus = curl_getinfo( $curl );                                   

  if( 200 !== $resultStatus['http_code']) {
    echo 'Call Failed '.print_r( $result_status );                         
  }
  curl_close( $curl );

  echo json_encode( utf8_encode( $response) ); 
  wp_die();
}

Kui saate vastuse, saate selle sõeluda serveri poolel (mida ma soovitan) ja tagastada see kerges vormingus algsele JavaScripti funktsioonile, nagu ülaltoodud. Pange tähele, et ma kasutan ülaltoodud koodis koodi json_encode .

Sealt saate oma olemasolevate andmetega kõnealuse lehega teha kõike, mida vajate. Pange tähele, et teave sisaldub vastuseobjektis ja selle õigeks käsitlemiseks peate võib-olla kontrollima, mida see sisaldab. See on saavutatud ja seda näitab ülaltoodud kood.

Kuid selle üksikasjad sõltuvad suuresti sellest, mida soovite saavutada.

WordPress puhverserverina

Lõppkokkuvõttes näeb juhtimisvoog välja umbes selline:

Kõige ülaltoodu mõte on aidata anda natuke tausta selle kohta, miks võite näha mõnda koodi, mida teete, ja miks peate oma koodi niimoodi struktureerima.