Recent Post
Miksi WordPressin AJAX-toiminnot lakkaavat toimimasta?
WordPressissä AJAX näkyy käyttäjälle yleensä hyvin yksinkertaisena asiana. Painetaan nappia ja jotain tapahtuu ilman, että koko sivu latautuu uudelleen.
Esimerkiksi hakutulokset vaihtuvat, tuotteita tulee lisää listaan tai lomakkeen tiedot lähetetään taustalla.
Kun tällainen toiminto lakkaa toimimasta, ongelma voi näyttää pieneltä. Painike on edelleen sivulla. JavaScript-tiedosto on paikallaan. PHP-koodiakaan ei ehkä ole muutettu viikkoihin.
Silti mitään ei tapahdu.
Tässä kohtaa on helppo alkaa epäillä itse WordPressiä. Usein ongelma on kuitenkin paljon lähempänä yksittäistä muutosta.
Ensimmäinen asia: tapahtuuko selaimessa mitään?
Jos painiketta painetaan eikä palvelimelle lähde pyyntöä, PHP-koodia ei ole vielä mitään järkeä tutkia.
Tämä selviää selaimen kehittäjätyökaluista.
Network-välilehti kertoo melko nopeasti, syntyykö pyyntö vai ei. Console taas voi paljastaa JavaScript-virheen, joka pysäyttää koodin ennen AJAX-kutsua.
Tämä on ehkä yksinkertaisin testi koko ongelmassa, mutta se jää helposti tekemättä.
Jos pyyntöä ei ole olemassa, vika on selaimen puolella.
Jos pyyntö löytyy, tilanne on toinen.
JavaScript voi hajota pienestä muutoksesta
☑️ WordPress-sivustolla JavaScript ei yleensä elä yksin.
☑️ Teema voi vaihtaa HTML-rakennetta. Lisäosa voi muuttaa jonkin elementin nimeä. Optimointityökalu voi siirtää skriptin latausjärjestystä.
☑️ Mukautettu JavaScript saattaa edelleen odottaa vanhaa rakennetta.
☑️ Esimerkiksi koodi hakee painikkeen tietyn CSS-luokan perusteella. Luokka muuttuu teeman päivityksessä. Painike näyttää käyttäjälle aivan normaalilta, mutta JavaScript ei enää löydä sitä.
☑️ Tämän vuoksi AJAX voi hajota ilman, että itse AJAX-koodia on koskettu.
Entä jos pyyntö lähtee?
➢ Silloin kannattaa avata itse pyyntö.
➢ WordPressin perinteisessä toteutuksessa vastaanottajana on usein admin-ajax.php. Sen näkeminen Network-välilehdellä kertoo jo, että selain pääsi ainakin tähän asti.
➢ Seuraavaksi kiinnostaa vastaus.
➢ HTTP 200 ei vielä tarkoita, että kaikki meni oikein. Palvelin voi palauttaa 200-vastauksen, jonka sisältö ei ole sitä mitä JavaScript odottaa.
➢ Vastaus voi sisältää esimerkiksi PHP-varoituksen, virheilmoituksen tai väärän JSON-rakenteen.
➢ Silloin käyttöliittymässä näkyy helposti vain rikkinäinen toiminto.
Yksi pieni PHP-virhe riittää
AJAX-käsittelijä voi tehdä paljon muutakin kuin palauttaa muutaman rivin dataa.
Se voi hakea WordPressin postauksia, tarkistaa käyttäjän oikeudet, tehdä tietokantakyselyn tai kutsua ulkopuolista APIa.
Jos jokin näistä epäonnistuu, ongelma päätyy lopulta selaimeen.
Tuotannossa tätä ei aina näe suoraan näytöllä. Sen sijaan WordPressin tai PHP:n lokissa voi olla varsin selvä virheilmoitus.
Siksi debug-loki on usein hyödyllisempi kuin AJAX-koodin tuijottaminen.
Nonce aiheuttaa oman ryhmänsä ongelmia
☑️ WordPressin AJAX-pyynnöissä käytetään usein nonce-tarkistusta.
☑️ Jos nonce on väärä tai sitä ei lähetetä ollenkaan, palvelin voi hylätä pyynnön.
☑️ Tämä voi tulla vastaan esimerkiksi päivityksen jälkeen, kun selaimessa on vanha JavaScript-tiedosto mutta palvelin käyttää jo uutta koodia.
☑️ Sivuston välimuisti tekee tilanteesta vielä hankalamman. Kehittäjä voi katsoa palvelimelta oikeaa koodia ja ihmetellä, miksi selain toimii edelleen vanhalla tavalla.
☑️ Selain ei kuitenkaan katso, mitä tiedostoja palvelimella pitäisi olla. Se käyttää sitä versiota, jonka se on saanut ladattua.
Toimiiko se vain kirjautuneena?
➢ Tämä testi kannattaa tehdä erityisesti WordPress-sivustoilla, joissa on mukautettua toimintalogiikkaa.
➢ Ylläpitäjänä kaikki voi näyttää hyvältä.
➢ Uloskirjautuneena sama painike ei tee mitään.
➢ Syynä voi olla se, että AJAX-toiminnolle on rekisteröity käsittelijä vain kirjautuneille käyttäjille. Tai palvelimen käyttöoikeustarkistus estää pyynnön.
➢ Tässä ei auta se, että toimintoa testataan uudelleen ylläpitäjänä.
➢ Jos ominaisuus on tarkoitettu kaikille kävijöille, se pitää testata myös sellaisena käyttäjänä.
Joskus AJAX toimii, mutta liian hitaasti
Tämä on eri ongelma, vaikka käyttäjälle lopputulos näyttää samalta.
Hakupainiketta painetaan. Sivulle tulee latausanimaatio. Tuloksia ei kuulu.
Ensimmäinen ajatus voi olla, että AJAX on rikki.
Palvelin voi kuitenkin olla edelleen tekemässä työtä.
Esimerkiksi tietokantakysely voi olla raskas. Mukautettu haku voi käydä läpi suuren määrän post meta -tietoja. Tai sama pyyntö voi kutsua ulkopuolista APIa ennen kuin vastaus voidaan palauttaa.
Pienessä kehitysympäristössä tätä ei ehkä huomaa lainkaan.
Tuotannossa dataa on enemmän ja käyttäjiä on samaan aikaan paljon.
Silloin vanha toteutus alkaa näyttää ongelmalliselta.
Tietokanta on usein piilossa käyttäjän näkymältä
☑️ AJAX-pyyntö itsessään voi olla nopea.
☑️ Se ei tarkoita, että sen tekemä työ olisi nopeaa.
☑️ Jos mukautettu toiminto hakee esimerkiksi tuotteita ja jokaiselle tuotteelle vielä lisää tietoja erillisillä kyselyillä, tietokantaan voi syntyä paljon enemmän liikennettä kuin käyttöliittymästä katsottuna voisi arvata.
☑️ Tämä on yksi niistä tilanteista, joissa pelkkä JavaScriptin tutkiminen ei vie pitkälle.
☑️ Jos pyyntö kestää sekunteja, kannattaa selvittää mitä palvelin tekee sen aikana.
Välimuisti voi olla syyllinen, mutta myös peittää ongelman
➢ WordPressissä voi olla useampi välimuisti samanaikaisesti.
➢ Selaimessa on oma välimuistinsa. Sivustolla voi olla optimointilisäosa. Palvelimella voi olla välimuisti ja sen päällä vielä CDN.
➢ Kun mukautettua JavaScriptiä muutetaan, vanha tiedosto voi jäädä käyttöön.
➢ Syntyy helposti tilanne, jossa kehittäjä testaa uutta PHP-koodia ja selain lähettää edelleen vanhan AJAX-pyynnön.
➢ Toinen erikoinen tilanne on se, että välimuisti tekee hitaasta toiminnosta hetkellisesti nopean. Kun välimuisti tyhjennetään, todellinen suorituskyky tulee näkyviin.
➢ Siksi ongelmaa ei kannata tutkia vain yhdessä välimuistitilanteessa.
Optimointi voi myös rikkoa toimivan koodin
JavaScriptin yhdistäminen ja pienentäminen ovat tavallisia WordPress-optimointeja.
Ne eivät kuitenkaan aina sovi mukautettuun koodiin sellaisenaan.
Jos AJAX lakkasi toimimasta sen jälkeen, kun optimointiasetuksia muutettiin, yhteys kannattaa ottaa vakavasti.
Testi on yksinkertainen: palautetaan kyseinen optimointi hetkeksi pois käytöstä ja katsotaan muuttuuko tilanne.
Jos toiminto alkaa toimia, seuraava tehtävä ei ole välttämättä poistaa koko optimointia. Parempi on selvittää, mikä skripti tai riippuvuus aiheuttaa ristiriidan.
Teeman päivitys voi olla todellinen syy
☑️ Mukautettu AJAX-toiminto voi riippua teemasta enemmän kuin aluksi näyttää.
☑️ JavaScript voi käyttää teeman tuottamaa HTML-rakennetta. PHP voi odottaa tiettyä templatea tai hookia.
☑️ Kun teema päivittyy, nämä voivat muuttua.
☑️ Sivusto näyttää muuten normaalilta. Etusivu toimii. Tuotesivut toimivat.
☑️ Vain yksi suodatin tai mukautettu painike on rikki.
☑️ Tällaisessa tapauksessa kannattaa verrata sitä, mitä selaimessa oli ennen päivitystä siihen, mitä siellä on nyt. Pelkkä nykyisen PHP-tiedoston katsominen ei aina riitä.
Entä jos WordPress tai lisäosa päivitettiin?
➢ Sama pätee WordPressin ja lisäosien päivityksiin.
➢ Ongelma ei välttämättä ole uudessa versiossa itsessään. Vanha oma koodi on voinut perustua toimintaan, jota uusi versio ei enää tarjoa samalla tavalla.
➢ Tällaisia tapauksia on vaikea ratkaista arvaamalla.
➢ Jos toiminto toimi eilen ja hajosi päivityksen jälkeen, muutoksen ajankohta on arvokas tieto. Sen avulla ongelmaa voidaan rajata huomattavasti.
AJAX ei aina ole oikea paikka korjata ongelmaa
Jos mukautettu AJAX-toiminto on kasvanut vuosien aikana, sen ympärille voi olla kertynyt paljon ehtoja ja poikkeuksia.
Yksi osa tarkistaa käyttäjän. Toinen tekee kyselyn. Kolmas muokkaa dataa. Neljäs rakentaa HTML:n. Lopuksi JavaScript yrittää päätellä, onnistuiko kaikki.
Silloin uuden if-lauseen lisääminen ei välttämättä paranna tilannetta.
Joskus järkevämpi ratkaisu on erottaa tietojen hakeminen, liiketoimintalogiikka ja käyttöliittymän päivitys toisistaan.
Uudessa toteutuksessa voidaan käyttää myös WordPress REST APIa, jos se sopii toiminnon tarkoitukseen.
Tekniikan vaihtaminen ei silti ratkaise huonoa tietokantakyselyä tai rikkinäistä liiketoimintalogiikkaa. Sama ongelma voidaan aivan hyvin siirtää uuteen rajapintaan.
Miten aloittaisin tutkimisen?
☑️ Jos WordPressin AJAX-toiminto lakkaa toimimasta, en aloittaisi kirjoittamalla koko ominaisuutta uudelleen.
☑️ Katsoisin ensin selaimesta, lähteekö pyyntö.
☑️ Jos ei lähde, katsoisin Console-virheet ja JavaScriptin.
☑️ Jos pyyntö lähtee, katsoisin vastauksen.
☑️ Jos palvelin palauttaa virheen, seuraavaksi lokit.
☑️ Jos pyyntö onnistuu mutta kestää pitkään, katsoisin tietokannan, PHP:n ja mahdolliset ulkoiset kutsut.
☑️ Ja jos ongelma alkoi heti päivityksen jälkeen, tarkistaisin ensin juuri sen muutoksen.
☑️ Tällä tavalla ongelman alue pienenee joka vaiheessa.
Lopuksi
➢ WordPressin AJAX-toiminto voi lakata toimimasta monesta syystä. Usein vika ei edes ole itse AJAXissa.
➢ JavaScript ei ehkä enää löydä oikeaa elementtiä. Selain voi käyttää vanhaa tiedostoa. Nonce voi olla väärä. PHP voi kaatua. Käyttäjän oikeudet voivat estää pyynnön. Tietokanta voi olla liian hidas. Tai optimointilisäosa voi muuttaa skriptien latausta.
➢ Siksi rikkinäistä AJAX-toimintoa ei kannata lähteä korjaamaan sokkona.
➢ Seuraa yhtä pyyntöä selaimesta palvelimelle ja takaisin.
➢ Siinä vaiheessa ongelma alkaa yleensä näyttää paljon vähemmän mystiseltä.