# Általános hibák és megoldásaik

> A pixelek nem működnek, üres megerősítő oldal, kiírt szkriptkód, jQuery-ütközés, hozzájárulás miatt elnyelt kosárba tétel, tűzfal, REST-hibák, egyedi rendelésállapot, Action Scheduler.

## Első lépés: a konzolnaplózó

Mielőtt kézzel keresgélnél, kapcsold be a konzolnaplózót, és nézd meg, mi történik a követéssel:

1. Fűzd az oldal URL-jéhez a `?pmwloggeron` paramétert.
2. Nyisd meg a böngésző fejlesztői eszközeit (F12), a **Console** fület.
3. Keresd a Pixel Manager kimenetét: az eseményeket, a pixelhívásokat és a hibákat.

A naplózó azonnal megmutatja, mely események futnak le (vagy nem), milyen adat megy az egyes pixelekhez, mi a hozzájárulás állapota, és milyen szkriptbetöltési problémák vannak. A részletek a [Konzolnaplózó](https://hub.hellowp.io/hu/plugins/woocommerce-pixel-manager/fejlesztoknek-konzolnaplozo/) fejezetben vannak.

## Általános kérdések

### Hol jelenthetek hibát, hol javasolhatok fejlesztést?

Írd meg a problémádat a bővítmény WordPress támogatói fórumán, vagy küldj kérést a támogatásnak e-mailben. Utóbbinál nyisd meg a Pixel Managerben a **Support → Debug report** részt, kattints a **Generate debug report** gombra, és másold be a jelentést az e-mailbe.

### A leggyakoribb okok, ha a pixelek nem működnek

- **Gyorsítótár:** ha valamilyen gyorsítótárréteg fut, a szerver még a régi oldalakat szolgálhatja ki. Ürítsd ki a gyorsítótárat.
- **Minifikálás, összevonás, csomagolás:** egyes minifikáló és összevonó bővítmények annyira átalakítják a beszúrt JavaScriptet, hogy a követőpixelek leállnak. Kapcsold ki a minifikálást, az összevonást és a csomagolást, és próbáld újra.

Ha konkrét szkripteket, útvonalakat és végpontokat kell kizárnod a gyorsítótár- vagy optimalizáló bővítményben, a [Gyorsítótár és optimalizálás: kizárások](https://hub.hellowp.io/hu/plugins/woocommerce-pixel-manager/hibaelharitas-gyorsitotar-kizarasok/) fejezetben megtalálod őket.

Ha csak egyes események hiányoznak, miközben mások működnek, az ok általában speciálisabb. A Meta-pixelnél különösen: ha a `PageView` megérkezik, de az `AddToCart`, az `InitiateCheckout` és a `Purchase` soha, olvasd el a [Meta (Facebook) hibák](https://hub.hellowp.io/hu/plugins/woocommerce-pixel-manager/hibaelharitas-meta/) fejezet „A Meta csendben elejti az AddToCart, InitiateCheckout és Purchase eseményeket” részét. Ilyenkor a Meta blokkolja az eseményeket, és weboldali módosítás nem segít.

### Lassítja a `pmw_get_cart_items` az oldalamat?

Röviden: nem.

Mit csinál a `pmw_get_cart_items`: amíg a látogató a boltban böngészik, termékeket tesz a kosárba. Valahányszor a minikosárral módosítja a választását, a Pixel Managernek kéznél kell lennie az összes termékadatnak, hogy minden releváns adattal küldjön pixelesemény a Google, a Meta (Facebook) és a többi platform felé. Ezeket az adatokat nem lehet az oldal betöltésekor a HTML-be írni, mert a gyorsítótárazási mechanizmusok elavult adatot szolgálhatnának ki a böngészőnek. Ezért van szükség egy olyan mechanizmusra, mint a `pmw_get_cart_items`, amely lekéri a minikosár aktuális termékadatait a szerverről.

Néhány felhasználó észrevette a böngésző Network fülén, hogy a `pmw_get_cart_items` hívás egy újabb kérést ad hozzá, amely lassú szervereken akár egy másodpercnél tovább is tarthat. A szabványos WordPress Ajax-funkciót használja a termékadatok lekérésére.

De lassítja-e az oldalt? A `pmw_get_cart_items` hívás azután történik, hogy a böngésző jelezte a `load` eseményt, ami akkor következik be, amikor az összes tartalom már sikeresen betöltődött. A `load` esemény akkor fut le, amikor az egész oldal betöltődött, az összes függő erőforrással (stíluslapok, képek) együtt. A PageSpeed az oldal betöltési idejét a kezdeti kéréstől az utolsó beágyazott erőforrás (JS, CSS, képek stb.) betöltéséig méri, vagyis lényegében addig, amíg a `$(window).load()` lefut. A `pmw_get_cart_items` ezért semmilyen módon nem lassítja egy WooCommerce-bolt letöltését vagy megjelenítését.

### A témám megjelenít egy szkriptkódot a front enden, aminek nem kellene ott lennie

A Pixel Manager szkriptkimenetet használ a termékek követésére, olyan módon, hogy az minden gyorsítótárrendszerrel működjön. A kódot `<script></script>` címkék közé teszi, ami teljesen szabványos HTML. Mivel a kód `<script></script>` közé van zárva, a témának figyelmen kívül kellene hagynia, és nem szabadna láthatóan kiírnia a front enden.

Ezt a Pixel Manager oldaláról nem lehet megoldani. Kérd meg a téma fejlesztőjét, hogy frissítse a témát úgy, hogy figyelmen kívül hagyjon minden `<script></script>` közé zárt kódot.

### Elementor: kapcsolódó és upsell termékek widget

Ezt az Elementor Pro egy későbbi kiadása javította, ezért frissítsd az Elementor Prót.

A régi kiadásokban az Elementor „Related Products” és „Upsell Products” widgetjei nem dolgozzák fel megfelelően a Pixel Manager `<script>` kimenetét: el kellene rejteniük, de láthatóvá válik. Ezt csak az Elementor widgetek készítői tudják javítani.

A kapcsolódó termékek widget felhasználóinak van megkerülő megoldás: a beépített widget helyett használd a `[related_products limit="X"]` shortcode-ot. Az Upsell Products widget cseréjére egy bekarice által közzétett kódrészlet használható. A hibát az Elementor GitHub hibakövetőjében is jelentették (#16934), ahol egy másik megoldás is megtalálható, amellyel a widgetek megtarthatók, de az nem marad meg az Elementor-frissítések után, ezért minden frissítéskor újra el kell végezni, és csak saját felelősségre használd.

### A megerősítő oldal nem tölt be, üres oldalt mutat

Ha a megerősítő oldal betöltésekor üres oldal jelenik meg, az ok jellemzően a túl kevés lefoglalt memória. A Pixel Manager a megerősítő oldalon néhány lekérdezést futtat, amelyek több memóriát használnak, mint más oldalakon. Ha a bolt konfigurációjában a memóriakorlát túl alacsony, ez a hiba jelentkezhet. A megoldás egyszerű: emeld meg a memóriakorlátot. Gondoskodj róla, hogy a korlát jóval a maximális memóriafelhasználás fölött legyen.

Írd a `wp-config.php` fájlba az alábbi sorok egyikét:

```php
define('WP_MEMORY_LIMIT', '256M');
```

```php
define('WP_MEMORY_LIMIT', '512M');
```

```php
define('WP_MEMORY_LIMIT', '1024M');
```

A WooCommerce dokumentációja a memóriakorlát megemelésének más módjait is bemutatja.

### A megerősítő oldal nagyon lassan töltődik be, ha a Pixel Manager be van kapcsolva

A Pixel Manager a megerősítő oldalon néhány lekérdezéssel kiértékeli, hogy a vásárló új vagy meglévő ügyfél-e, és a vásárló különböző élettartamértékeit (customer lifetime value) is meghatározza. Ezek a lekérdezések egyes boltokban hosszú ideig futhatnak.

A legegyszerűbb megoldás nagy teljesítményű indexek hozzáadása a táblákhoz. Az egyik tesztben a lekérdezés sebessége 133-szorosára javult. Használd az **Index WP MySQL For Speed** bővítményt, hogy ezeket az indexeket a boltodhoz is hozzáadd. Nemcsak a megerősítő oldalon segít, hanem a bolt minden oldalán.

### Miért nem tudom ellenőrizni az oldalamat a Hotjaron?

A Hotjar beállítása egyszerű. A Pixel Managerben nyisd meg a **Tracking Pixels → Hotjar** részt, és másold be a Hotjar követőkódjából a Site ID értéket a **Site ID** mezőbe.

Néha mégsem lehet ellenőrizni az oldalt. Ennek általában ezek az okai:

- **Sütibanner:** az ellenőrzés idejére kapcsold ki a sütibannert. Néha a Hotjar sütijeit is blokkolja, és emiatt az ellenőrzés sikertelen.
- **Explicit Consent Mode:** ha a Pixel Managerben be van kapcsolva az **Enable Explicit Consent Mode** (**Consent → Explicit consent**), az sem engedi a sütikövetést az oldalon. A sütibannerhez hasonlóan ez is sikertelenné teszi az ellenőrzést.
- **Be vagy jelentkezve az ellenőrzés közben:** az ellenőrzést kijelentkezve kell végezni a WordPress vezérlőpultról, hogy az oldal követve legyen.
- **Szerveroldali gyorsítótár:** minden konfigurálás után ürítsd ki a szerveroldali gyorsítótárat, hogy a Hotjar ellenőrzője ne egy gyorsítótárazott változatot töltsön be.

### Duplikált jQuery-könyvtár véletlenszerű hibákat okoz

**Probléma:** a téma, egy bővítmény vagy egyedi kód egy további jQuery-könyvtárat tölt be, amely felülírja azokat az eseményeket, amelyekre a Pixel Manager kapcsolódik.

A WordPress hosszú ideig régi jQuery-verziót szállított, ezért egyes témafejlesztők vagy boltkezelők egy újabb jQuery-könyvtárat töltöttek be a HTML-forrásban. Ha ezt hibásan teszik, az felülírja az összes eseményt, amelyre egy bővítmény, például a Pixel Manager kapcsolódott, és az eseményfigyelők használhatatlanná válnak. A WordPress szerencsére az 5.5-ös verziótól a legmodernebb jQuery-t szállítja, ezért a további jQuery-könyvtár nyugodtan eltávolítható.

**Ellenőrzés:**

1. Nyisd meg a fejlesztői konzolt.
2. Keress az egész forráskódban (Macen Opt+Cmd+F) erre a szövegre: `jQuery requires a window with a document`.
3. Ha két találatot kapsz, a jQuery-könyvtár duplikált, és gondot okoz.

**Megoldás:** távolítsd el a további jQuery-könyvtárat. Tartsd meg azt, amelyet a WordPress tölt be.

### A Pixel Manager JavaScript-kódja láthatóvá válik a front enden

Ritkán előfordulhat, hogy a front enden láthatóan megjelenik a Pixel Manager által az oldalba szúrt JavaScript-kód. Ez jellemzően ezzel a sorral kezdődik:

```js
window.pmwDataLayer.products = window.pmwDataLayer.products || {};
```

Három ismert eset van:

1. Az oldalszerkesztő vagy a téma kiszedi a címkéket a termékrácsok termékkártyáiból. Ez ma a leggyakoribb eset. A működő megoldást lásd lent: „Termékrácsok, amelyek szövegként mutatják a kódot”.
2. Az Elementor Pro kapcsolódó és upsell termékek widgetje. Erre lásd az előző, Elementorról szóló részt.
3. A téma olyan front end JavaScript-könyvtárat használ, amely hibásan jeleníti meg a Pixel Manager által a terméksablonokba szúrt kódot. A Pixel Manager három HTML-elemet szúr az oldal forrásába: egy `<meta>`, egy `<input type="hidden">` és egy `<script></script>` elemet. Ezek mind definíció szerint láthatatlan elemek, és nem szabadna láthatóan megjeleníteni őket. Egyes JavaScript-segédkönyvtárak mégsem számolnak ezekkel a láthatatlan elemekkel, és mégis megjelenítik őket. Ezt a megjelenítő könyvtárak fejlesztőinek kell kijavítaniuk, a Pixel Manager nem tudja megkerülni.

### Termékrácsok, amelyek szövegként mutatják a kódot

**Probléma:** a kód látható szövegként jelenik meg egy termékrács termékkártyáin belül, például a bolt oldalán, a kategóriaoldalakon vagy egy oldalszerkesztővel épített rácsban.

A Pixel Manager a termékhurok minden terméke után egy rejtett jelölőelemet és egy kis inline `<script>` címkét ad hozzá a szabványos WooCommerce `woocommerce_after_shop_loop_item` horgon keresztül. Ez a kimenet táplálja a `view_item_list` és a `select_item` eseményeket.

Egyes oldalszerkesztők és témaszerkesztők megtisztítják mindazt, amit ez a horog kiír. Eltávolítják a `<script>` és az `<input>` címkéket, de megtartják a bennük lévő szöveget, így a szkript tartalma látható lesz minden termékkártyán. Ismert példák: az Elementor Products widget és a saját termékkártyákat megjelenítő témaszerkesztő-modulok.

**Megoldás:** a kimenetet áthelyezheted a láblécbe, a tisztító hatókörén kívülre. A követés továbbra is működik: az adatszkriptek a láblécben íródnak ki, a jelölőelemeket pedig visszahelyezi a termékkártyákba. Add hozzá ezt a gyermektéma `functions.php` fájljához:

```php
add_filter('pmw_defer_product_data_layer_to_footer', '__return_true');
```

Ezután ürítsd ki az összes gyorsítótárat, az oldal-gyorsítótárat és az oldalszerkesztő gyorsítótárát is.

Kezdd ezzel a globális változattal. Azok a kódrészletek, amelyek a szűrőt csak egy adott oldalszerkesztő-widgetre kapcsolják be, könnyen hibásak, mert a widget nevének pontosan egyeznie kell azzal, amit a rácsod valóban használ. Ha a globális szűrő megoldja, utána szűkítheted. A hatókörrel rendelkező változatok és korlátaik a [PHP-szűrők: további szűrők](https://hub.hellowp.io/hu/plugins/woocommerce-pixel-manager/fejlesztoknek-php-szurok-egyeb/) fejezetben vannak.

Ha egyáltalán nincs szükséged a `view_item_list` és `select_item` követésre a termékrácsokon, a kimenetet teljesen el is nyomhatod ugyanebben a fejezetben leírt módon. Minden más követés, például a termékoldalak, a kosár és a vásárlási események érintetlen marad.

### A kosárba tétel (vagy más űrlap) csendben nem működik, ha a hozzájárulás meg van tagadva

**A tünet jellemzői:**

- Egy kattintás vagy űrlapküldés semmit nem csinál (leggyakrabban a kosárba tétel, de egyedi űrlapok vagy AJAX-folyamatok is).
- Az oldal újratölt, vagy ugyanarra az URL-re navigál `?_gl=…` hozzáfűzve.
- A böngésző Network füle nem mutat a szerverig eljutó kérést a hibázó művelethez: nincs `add-to-cart=ID` POST, nincs AJAX-hívás.
- Nem keletkezik JavaScript-hiba.
- A hiba csak akkor reprodukálható, ha mindez együtt igaz: aktív egy hozzájárulás-kezelő platform (CMP, például Cookiebot), a látogató megtagadta a hozzájárulást, és a Pixel Manager Google Consent Mode `url_passthrough` funkciója be van kapcsolva. Hozzájárulás megadva, kikapcsolt CMP vagy kikapcsolt Pixel Manager mellett helyesen működik.

**Diagnosztikai teszt:** nyisd meg a fejlesztői eszközök **Network** fülét, és próbáld újra a hibázó műveletet.

- Ha egyáltalán nem indul kérés, a hiba kliensoldali. A legvalószínűbb ok az URL-átengedés (url passthrough) vagy egy versengő eseményfigyelő (expressz fizetési gombok, egyedi témaszkript).
- Ha a kérés elindul, de hibával tér vissza, szerveroldali vagy válaszkezelési hibáról van szó, ami független az URL-átengedéstől.

**Ok:** a Google Consent Mode `url_passthrough` funkciója megtagadott hozzájárulás esetén egy `_gl=…` paramétert fűz a kimenő URL-ekhez (hivatkozásokhoz és űrlapműveletekhez), hogy a domainek közötti munkamenet-folytonosság sütik nélkül is megmaradjon. Egyes témák és bővítmények egyedi kattintás- vagy űrlapkezelőt szállítanak, amely nem viseli el a módosított művelet-URL-t. A kezelő eldobhatja a POST törzset, GET-té alakíthatja a küldést, vagy teljesen megszakíthatja.

Nagyobb kockázatú környezetek, amelyeket érdemes ellenőrizni:

- olyan témák, amelyek egyedi kosárba tétel JavaScriptet használnak a termékoldalon,
- olyan oldalak, ahol több bővítmény versenyez a kosár űrlapjának kattintásáért, például a WooCommerce Payments expressz pénztár, a PayPal okos gombjai, vagy keresés/pénztár-bővítmények, mint a FiboSearch.

**Megoldás:** kapcsold ki az URL-átengedést ezzel a szűrővel:

```php
add_filter('pmw_google_url_passthrough', '__return_false');
```

A kosár és a többi űrlap megtagadott hozzájárulásnál is újra működik. A kompromisszum: elveszik a domainek közötti munkamenet-összekötés a hozzájárulást megtagadó látogatóknál. Egydomainű boltoknál a gyakorlati hatás gyakorlatilag nulla.

**Miért nem javítja ezt magától a Pixel Manager:** a további URL-paraméterek soha nem törhetik el az oldalt. A UTM-paraméterek, a `gclid`, az `fbclid` és a `_gl` mind szokásos kimenő kiegészítések, amelyeket hirdetési platformok, e-mail-eszközök és keresők tesznek hozzá. Az a téma vagy bővítmény, amely a `_gl` paramétertől elromlik, előbb-utóbb a többitől is elromlik. A javítás a hibás témában vagy bővítményben van, nem a Pixel Managerben.

### A REST-végpontok nem működnek

Ritka esetekben a Pixel Manager `wp-json` REST-végpontjai leállnak, és `404` hibát adnak. Ez jellemzően akkor történik, ha a WordPress permalink-beállításaiban szép hivatkozásokról nem szép hivatkozásokra váltasz, és az oldal gyorsítótárat használ. A probléma megoldásához ürítsd ki az összes szerveroldali gyorsítótárat (gyorsítótár-bővítmény, szerver-gyorsítótár, CDN-gyorsítótár stb.).

### Biztonsági tűzfal blokkolja a Pixel Manager kéréseit

A webalkalmazás-tűzfal (WAF) a WordPress előtt áll: lehet biztonsági bővítmény (Wordfence), a szerveren futó ModSecurity vagy Imunify360, esetleg szolgáltatás (Cloudflare, Sucuri). Ha az egyik szabálya illeszkedik egy Pixel Manager kérésre, a tűzfal maga válaszol, és a WordPress sosem látja a kérést. Az alábbi két jelleg a leggyakoribb.

#### A beállítások nem mentődnek, az admin „API error 403” vagy „blocked before it reached WordPress” üzenetet mutat

**Tünet:** módosítasz egy beállítást, és a Pixel Manager mentés helyett hibát jelez. A régi kiadások az „API error 403” üzenetet mutatják, a friss kiadás azt írja, hogy a kérést még a WordPress előtt blokkolták, és megnevezi a HTTP-állapotot és a kérést.

**Ok:** az admin minden módosítást `PATCH` kérésként ment a `/wp-json/pmw/v1/options` végpontra. Egy tűzfalszabály blokkolja ezt a kérést, néha a kérés törzsében lévő értékek miatt, néha mert a `PATCH` metódust egyáltalán blokkolja.

**Így ellenőrizheted:**

1. Nyisd meg a böngésző fejlesztői eszközeit (F12), lépj a **Network** fülre, és módosíts egy beállítást.
2. Kattints az `options` kérésre. Az olyan `403` állapot, amelynek a válasza HTML-oldal (egy „Forbidden” oldal, egy Wordfence blokkoló oldal, egy tárhely-hibaoldal), a tűzfaltól jön. Ha maga a WordPress utasít el egy kérést, a válasz JSON `code` mezővel.
3. Ha Wordfence-t használsz, nyisd meg a **Wordfence → Tools → Live Traffic** részt, szűrj a blokkolt kérésekre, és keresd a `/wp-json/pmw/v1/options` bejegyzést a mentés időpontjában. Megnevezi a tűzfalszabályt, amely lefutott. Adminisztrátori kérésnél a Wordfence általában a bejegyzésben felajánlja, hogy a blokkolt paramétert felvegye a tűzfal engedélylistájára.

**Megoldás:** vedd fel a kérést a biztonsági bővítmény engedélylistájára, vagy ha a blokkolás a szerveren történik, küldj a tárhelynek ilyen kérést:

> A Pixel Manager for WooCommerce beállításainak mentése HTTP 403 hibával meghiúsul az oldalamon. A kérés `PATCH /wp-json/pmw/v1/options`, bejelentkezett adminisztrátor küldte [dátum és idő, időzónával]. Kérlek, nézd meg a ModSecurity vagy WAF auditnaplót és a webszerver hibanaplóját erre a kérésre, mondd meg a blokkoló szabály azonosítóját, és módosítsd vagy kapcsold ki ezt a szabályt erre az oldalra. Erősítsd meg azt is, hogy a `PATCH` metódus engedélyezett a `/wp-json/` alatt.

#### A front end kérések HTTP 406-tal hibáznak, és a rendelések elveszítik a kattintásazonosítókat

**Tünet:** a vártnál több rendelés érkezik kattintásazonosítók nélkül, és a Click ID Capture Quality jelentés alacsony arányt mutat, bár futnak a kampányok és a hozzájárulás megvan. A boltban semmi nem látszik elromlottnak.

**Ok:** a kosár- és pénztároldalon a böngésző a kattintásazonosítókat egy `POST` kéréssel jelenti a szervernek a `/wp-admin/admin-ajax.php` felé (a művelet: `pmw_process_transient_session_identifiers`). Egy tűzfalszabály, jellemzően a ModSecurity, `406 Not Acceptable` válaszol erre a kérésre, így a WooCommerce munkamenet sosem kapja meg a kattintásazonosítókat, és a rögzítés csak a sütikre támaszkodik. A bolt tovább működik, ezért a veszteség észrevétlen marad.

**Így ellenőrizheted:**

1. Nyiss meg egy kosároldalt nyitott fejlesztői eszközökkel, lépj a **Network** fülre, és szűrj az `admin-ajax` szóra. Az olyan `POST`, amely `406`-ot ad, a blokkolás.
2. Nyisd meg közvetlenül a `/wp-admin/admin-ajax.php` címet a böngészőben. A sima `GET` a WordPress saját válaszát adja (`0` vagy `400`), ami megmutatja, hogy a WordPress elérhető, és a tűzfal csak a `POST` kérésre reagál.
3. Az ok gyakran egy kérésfejléc, nem a metódus. A Chromium-alapú böngészők kliensjelző fejléceket küldenek, például `sec-ch-ua`, és egyes szabálykészletek ezekre illesztenek. Kattints jobb gombbal a sikertelen kérésre, válaszd a **Copy → Copy as cURL** lehetőséget, és futtasd egy terminálban. Aztán vedd ki a `sec-ch-ua` fejléceket, és futtasd újra. Ha csak a fejlécek nélküli változat sikerül, a fejléc az ok.

Ezért mehet át a tárhely saját tesztje is: az ilyen fejlécek nélküli `curl` kérés `200`-at ad, miközben minden Chromium-látogatót blokkolnak.

**Megoldás:** kérd el a tárhelytől a lefutott ModSecurity-szabály azonosítóját (az auditnaplóból, a sikertelen `POST` adott időpontjára), és kérd, hogy javítsák vagy kapcsolják ki. Ne érd be egyetlen `admin-ajax.php` művelet engedélylistára tételével: ugyanaz a szabály általában más `POST` kéréseket is blokkol, a Pixel Managerétől és más bővítményekétől is.

### A Pixel Manager nem ismeri fel az egyedi „fizetett” rendelésállapotot

A Pixel Manager a WooCommerce fizetett rendelésállapotai alapján dönti el, hogy egy rendelés ki van-e fizetve. Ha egyedi fizetett rendelésállapotot használsz, a Pixel Manager nem ismeri fel. Az egyedi állapotot ezzel a szűrővel adhatod hozzá:

```php
add_filter('woocommerce_order_is_paid_statuses', function ($statuses) {
    $statuses[] = 'custom-paid-status';
    return $statuses;
});
```

Ezt a téma `functions.php` fájljába tedd.

## Action Scheduler

A Pixel Manager az Action Scheduler könyvtárat szállítja. Ez segít éjszaka összeállítani a jelentéseket, mert azok feldolgozása sokáig tarthat.

Ritkán az Action Scheduler táblái felpuffadnak, zárolódnak, és az egész weboldal leállhat. Úgy tűnik, ez egy tartós, nem csak a Pixel Manager felhasználóit érintő probléma a WooCommerce-világban. Többféleképpen kezelhető, de mindegyiknek az a célja, hogy kitisztítsa és megjavítsa az Action Scheduler tábláit.

### A felesleges rekordok törlése (sikertelen, megszakított és befejezett feladatok)

Csak akkor csináld, ha tudod, hogyan kell visszaállítani egy adatbázis-mentést.

1. Készíts mentést az adatbázisról.
2. Nyisd meg az adatbázist, és futtasd az alábbi SQL-utasításokat. Ha a tábláid `wp_`-től eltérő egyedi előtagot használnak, igazítsd az utasítás előtagját.

```sql
DELETE FROM `wp_actionscheduler_actions` WHERE `status` = 'canceled';
DELETE FROM `wp_actionscheduler_actions` WHERE `status` = 'failed';
DELETE FROM `wp_actionscheduler_actions` WHERE `status` = 'complete';
```

### Zárolt adatbázis

Csak akkor csináld, ha tudod, hogyan kell visszaállítani egy adatbázis-mentést.

Előfordulhat, hogy az Action Scheduler annyira elromlik, hogy az adatbázist folyamatosan zárolják az olvasásai és írásai. Ilyenkor nem férsz hozzá az adatbázishoz, és nem tudod megjavítani a hibát. Így oldd meg:

1. Készíts mentést az adatbázisról.
2. Nyisd meg a `wp-config.php` fájlt, jegyezd fel az adatbázis jelszavát, töröld a jelszót a fájlból, és mentsd. A weboldal ezután nem fér hozzá az adatbázishoz, és az adatbázis újra elérhetővé válik.
3. Végezd el a javításokat.
4. Írd vissza az adatbázis jelszavát a `wp-config.php` fájlba.

### Az aktuális táblák eldobása és friss táblák létrehozása

Csak akkor csináld, ha tudod, hogyan kell visszaállítani egy adatbázis-mentést.

1. Készíts mentést az adatbázisról.
2. Töltsd le a `replace-as-tables.sql` fájlt , és mentsd a számítógépedre `replace-as-tables.sql` néven.
3. Importáld a fájlt az adatbázisba. Ha az alapértelmezett `wp_` előtagot használod, ez lecseréli a meglévő táblákat.
4. Most friss Action Scheduler táblákat kaptál. Ha az alapértelmezett `wp_` előtagot használod, kész vagy, a táblák javítva vannak. Egyedi előtagnál folytasd a következő lépéssel.
5. Dobd el kézzel a régi táblákat.
6. Vedd az alábbi SQL-utasítást, cseréld a `custom_prefix_` részt az adatbázisod előtagjára, és futtasd:

```sql
RENAME TABLE
    wp_actionscheduler_logs TO custom_prefix_actionscheduler_logs,
    wp_actionscheduler_groups TO custom_prefix_actionscheduler_groups,
    wp_actionscheduler_claims TO custom_prefix_actionscheduler_claims,
    wp_actionscheduler_actions TO custom_prefix_actionscheduler_actions;
```

7. Ezzel friss Action Scheduler táblákat kaptál a helyes előtaggal, és újra mindennek működnie kell.

### További Action Scheduler támogatás

Az Action Schedulert az Automattic csapata tartja karban. Ha további segítségre van szükséged, közvetlenül hozzájuk fordulj a WooCommerce támogatásán keresztül.

### Call to undefined function `as_has_scheduled_action()`

Ha ezt a hibaüzenetet kapod:

```
Call to undefined function ... as_has_scheduled_action() in...
```

akkor egy harmadik féltől származó bővítményt használsz, amelyben az Action Scheduler könyvtár elavult. A Pixel Manager az Action Scheduler legfrissebb verzióját szállítja, amely tartalmazza az `as_has_scheduled_action()` függvényt.

Az Action Scheduler sok bővítménybe be van csomagolva. Betöltéskor automatikusan a könyvtár legfrissebb változata töltődik be, de ez megbízhatóan csak a `3.2.1` verziótól működik. A WooCommerce hibaelhárítási cikke a különböző Action Scheduler verziók ütközésének feloldásáról szól.

A Pixel Managerben van védelem, amely megakadályozza az `as_has_scheduled_action()` használatát, ha az nem elérhető. Előfordulhat azonban, hogy egy későbbi kiadásban elfelejtik ezt a védelmet hozzáadni (korábban már előfordult). Ha ilyet tapasztalsz, jelezd a támogatásnak, és azonnal javítják.

## Inkompatibilis bővítmények

### WC Custom Thank You

Ez a bővítmény egyedi köszönő oldalt hoz létre a WooCommerce-rendelésekhez, de nem követi a WooCommerce szabványát a megerősítő oldalra. Ahhoz, hogy a konverziós pixelek lefussanak a WooCommerce megerősítő oldalon, minden WooCommerce-témának helyesen kell megvalósítania az `is_order_received_page()` feltételt. Ez a megerősítő oldalt módosító bővítményekre is igaz. Emellett a WC Custom Thank You bővítményt régóta nem frissítették, és a fejlesztő nem válaszol a támogatási kérésekre.

## Frissítések nem láthatók

Néha előfordul, hogy a frissítések nem jelennek meg, bár az előfizetés aktív.

### A licenc kézi szinkronizálása

Nyisd meg a bővítmény **Account** fülét, és kattints a **Sync** gombra. Ez szinkronizálja a licencet, és lehet, hogy már megoldja a problémát. Ha nem, folytasd a következő módszerrel.

### Teljes visszaállítás

Néha sem a licenc kézi szinkronizálása, sem a bővítmény kikapcsolása és újrabekapcsolása nem segít. Ilyenkor a teljes visszaállítás segíthet:

1. Töltsd le a Freemius Fixer bővítményt a GitHubról (Freemius/freemius-fixer).
2. Telepítsd a bővítményt az oldaladra.
3. Futtasd a Freemius Fixert.
4. Add vissza a licencet a Pixel Managerben az **Account** oldalon. Ha nincs meg a licenckulcsod, a vásárlói fiókodból elérheted.