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

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ó 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 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 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:

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

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

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:

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:

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 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:

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á:

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.

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:

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.