# A pénztáron végtelenül forog a töltésjelző

> Mit tehetsz, ha a pénztár oldal elhalványul, és a töltésjelző nem áll le: a kérés vizsgálata, gyorsítótár, JavaScript-hibák, naplók.

Ha a pénztár oldal egy töltésjelző mögött elhalványulva marad, a böngésző általában egy kérés válaszára vár, elutasítja a választ, vagy a JavaScript nem tudja befejezni a pénztár frissítését. A teendő attól függ, hogy a boltod klasszikus pénztárat vagy a **Pénztár** blokkot használja.

A vizsgálathoz boltadminisztrátori hozzáférés és egy tesztoldal vagy teszt fizetési mód kell. A leírás a WooCommerce alapbővítmény pénztárára vonatkozik. Ha csak egy fizetési, szállítási, adó-, cím- vagy csalásmegelőző kiegészítő érintett, nézd meg annak naplóit és leírását is.

A töltésjelző önmagában nem árulja el az okot. Lehet gyorsítótár, bővítményütközés, blokkolt kérés vagy szerverhiba. Először állapítsd meg a pénztár típusát, és reprodukáld biztonságosan a hibát.

## Melyik pénztárat használod?

Szerkeszd a **WooCommerce → Beállítások → Haladó** oldalon **Pénztár**ként kijelölt oldalt:

| Típus | Hogyan ismered fel | Mit használ a böngésző |
|---|---|---|
| **Pénztár** blokk | A szerkesztőben egy Pénztár blokk van | A WooCommerce Store API-t a kosár és a pénztár kéréseihez |
| Klasszikus pénztár | Klasszikus rövidkód blokk vagy rövidkód blokk a WooCommerce pénztárhoz | A WooCommerce AJAX-végpontokat, például az `update_order_review` kérést az összegek, a szállítás és a fizetési módok frissítésekor |

Ne cseréld az egyik típust a másikra első lépésként. A kiegészítők eltérően támogatják őket, a váltás elrejtheti az eredeti kompatibilitási gondot.

## Felkészülés

- Készíts friss mentést, és ha lehet, tesztoldalon reprodukáld a hibát.
- Tesztoldalon kapcsold le az éles fizetési módokat és külső szolgáltatásokat, vagy kapcsold be a dokumentált teszt módjukat.
- Kezdd egyetlen egyszerű, készleten lévő termékkel és kupon nélkül. Jegyezd fel, melyik cím, szállítási mód és fizetési mód váltja ki a töltésjelzőt.
- Jegyezd fel a pontos időpontot, a böngészőt, az eszközt, a felhasználó állapotát (vendég vagy bejelentkezett), a várt eredményt és azt, hogy mi történik helyette.

> **Figyelem**
>
> A tesztoldal is terhelhet fizetési módot, küldhet e-mailt, hívhat webhookot és módosíthat összekapcsolt szolgáltatásokban lévő adatokat.

## A hibás kérés megkeresése a böngészőben

1. Nyisd meg a pénztár oldalt, nyisd meg a böngésző fejlesztői eszközeit (jobb klikk, majd **Inspect**).
2. Nyisd meg a **Network** panelt, válaszd a **Fetch/XHR** szűrőt, és ha van, kapcsold be a **Preserve log** opciót.
3. Töröld a rögzített kéréseket, majd ismételd meg a töltésjelzőt kiváltó műveletet. Ha a **Megrendelés** gomb után történik, újrapróbálás előtt nézd meg a **WooCommerce → Rendelések** oldalt: lehet, hogy a rendelés már létrejött.
4. Nyisd meg a függőben maradó vagy hibás kérést. Mentsd el az URL-jét, módszerét, állapotkódját, időtartamát és a válaszát.

Klasszikus pénztárnál olyan URL-t keress, amelyben `wc-ajax=update_order_review` (az összegek betöltésekor) vagy `wc-ajax=checkout` (a megrendelés után) szerepel. A Pénztár blokknál a `/wp-json/wc/store/` alatti kéréseket nézd, főleg a kosár és a pénztár útvonalait.

## Mit jelent a kérés eredménye

| Eredmény | Mit vizsgálj |
|---|---|
| Hosszan függőben van vagy időtúllépés | Lassú PHP, adatbázis-művelet, külső API, e-mail-kézbesítés vagy szerver erőforrás-korlát. |
| 403 | Tűzfal, biztonsági szabály, lejárt vagy hiányzó nonce (egyszer használatos biztonsági kód), vagy más jogosultság-ellenőrzés. |
| 404 | Hibás kérés-URL, átírási szabály, proxy-útvonal vagy áthelyezett webhelybeállítás. |
| 500 | PHP végzetes hiba vagy más szerveroldali hiba. Nézd meg a naplókat ugyanarra az időpontra. |
| JSON helyett HTML, bejelentkezési oldal vagy átirányítás | Gyorsítótár, karbantartási vagy biztonsági réteg, átirányítás, proxy vagy PHP-figyelmeztetés változtatja meg a választ. |
| Blokkolt, vegyes tartalmú vagy cross-origin hiba | A pénztár oldal és a kérés végpontja nem ugyanazt az HTTPS-t, hosztnevet, portot vagy engedélyezett eredetet használja. |

## Webhelycímek ellenőrzése

A **Beállítások → Általános** oldalon vesd össze a pénztár nyilvános URL-jét a Network panelen látott kérés URL-jével. Keress régi domaint, váratlan `www` különbséget, vagy HTTP-kéréseket egy HTTPS pénztár oldalról. Mielőtt a webhelycímeket módosítanád, kérd meg a tárhelyszolgáltatót, hogy vizsgálja meg a blokkolt kéréseket és átirányításokat.

A **WordPress cím (URL)** és a **Webhely cím (URL)** többnyire megegyezik, de szándékosan eltérhet, ha a WordPress saját könyvtárban van, vagy proxy van beállítva. Ne tedd őket azonossá pusztán a pénztár hibája miatt. Ha a mezők le vannak tiltva, vagy nem vagy biztos a helyes címekben, kérd meg a tárhelyszolgáltatót az ellenőrzésre. A lényeg az, hogy a böngésző a nyilvános oldalról el tudja-e érni a pénztár kérés URL-jét.

## Gyorsítótár

Zárd ki a **Kosár**, a **Pénztár** és a **Fiókom** oldalt az oldal- vagy peremgyorsítótárból. Győződj meg róla, hogy a gyorsítótár, a CDN, a tűzfal és a fordított proxy a WooCommerce AJAX- és Store API-kéréseket is tárolt válasz nélkül engedi át. Használd a gyorsítótár-szolgáltatód kizárási beállításait, vagy kérd meg a tárhelyszolgáltatót a beállításra. Minden gyorsítótár-réteget ürítsd ki, és ismételd meg a tesztet.

Ha a válasz csak `-1`, az AJAX nonce ellenőrzés sikertelensége lehet az oka. Gyakran lejárt vagy gyorsítótárazott nonce áll mögötte, de hiányozhat vagy megváltozhat, mielőtt a WordPressig ér. Töltsd újra a pénztárat, ürítsd a gyorsítótárakat, ellenőrizd, hogy az oldal ki van zárva, majd vizsgáld meg újra a kérést és a választ.

## JavaScript-hibák és ütközések

1. Nyisd meg a böngésző **Console** paneljét, töröld, és idézd elő a töltésjelzőt.
2. Mentsd el az első lényeges hibát és a forrásfájlját. A későbbi hibák az első következményei lehetnek.
3. Nézd meg, hogy tartalombiztonsági szabály, hozzájárulás-kezelő, hirdetésblokkoló, optimalizáló szolgáltatás vagy böngészőbővítmény nem blokkolt-e egy pénztár szkriptet vagy kérést.
4. Végezd el a téma- és bővítményütközés-vizsgálatot tesztoldalon. Az eredményt úgy erősítsd meg, hogy ugyanazzal a beállítással a hiba eltűnik, majd újra megjelenik.

## Naplók és szerverbeállítások

- A **WooCommerce → Állapot → Naplók** oldalon nyisd meg az érintett kiegészítőhöz és időponthoz tartozó naplót. A végzetes PHP hibák a fatal-errors naplóban lehetnek.
- Töltsd le az aktuális rendszerállapot-jelentést. Nézd meg a szoftververziókat, a memóriakorlátokat, a sablonfelülírásokat és az aktív bővítményeket. Az **Időzített műveletek** oldalon nézd át az ütemezett műveleteket.
- Ha a napló memóriakorlát kimerülést jelez, kérd meg a tárhelyszolgáltatót a korlátok és a hibás kérés átvizsgálására. A memória növelése anélkül, hogy kimerülés történt volna, nem helyettesíti a lassú vagy hibás kérés megkeresését.
- Ha a kérést a WordPress előtt blokkolják vagy időtúllépés éri, kérd meg a tárhelyszolgáltatót, hogy a rögzített időpontban nézze át a webszerver, a PHP, a tűzfal, a proxy és az erőforrás-korlátok naplóit.

## Külső szolgáltatások és e-mailek

Ellenőrizd a kiválasztott fizetési módot, a csalásmegelőző és adószolgáltatást, a webhookokat és a levélküldést. Használd a kiegészítő teszt módját és naplóit, és nézd meg a szolgáltató állapotát. A töltésjelzőből ne következtess az okra.

Ha a tárhelyszolgáltatód vagy a fejlesztőd megerősíti, hogy a pénztár közbeni e-mailküldés lassítja a kérést, a **WooCommerce → Beállítások → Haladó → Funkciók** oldalon van egy **Deferred emails** (halasztott e-mailek) funkció. Tesztoldalon, biztonságos címzettel próbáld ki. Bekapcsolás és mentés után a **WooCommerce → Állapot → Időzített műveletek** oldalon ellenőrizd, hogy a sorba tett e-mail-műveletek lefutnak, és a próbalevelek megérkeznek. Ne kapcsold be általános megoldásként, ha a hibás kérés még a rendelés beküldése előtt történik.

## Ellenőrzés a módosítások után

Minden módosítás után ismételd meg ugyanazt a lépéssort ugyanazzal a termékkel, címmel és fizetési móddal. Nézd meg, hogy az összegek és a fizetési módok betöltődnek-e, a kérés hiba nélkül lefut-e, és a pénztár használható lett-e. Ha a hiba a megrendelés után jelentkezett, végezz el egy teszt módú rendelést, és ellenőrizd, hogy pontosan egy rendelés jött létre, és megjelent a visszaigazolás. A teszt közben módosított, nem kapcsolódó beállításokat állítsd vissza.

## Mit gyűjts össze, ha segítséget kérsz

- A pénztár típusát (klasszikus vagy blokk).
- A pontos lépéseket, és hogy a hiba vendégnél, bejelentkezett vásárlónál vagy mindkettőnél előfordul-e.
- A hibás kérés URL-jét, módszerét, állapotkódját, időtartamát és válaszát, a hitelesítő adatok és vásárlói adatok eltávolításával.
- Az első lényeges konzolhibát, a hozzá tartozó szervernaplókat, a rendszerállapot-jelentést és az ütközésvizsgálat eredményét.

Megosztás előtt töröld a vásárlók adatait, a fizetési adatokat, a hitelesítő adatokat, a sütiket és a biztonsági tokeneket.