Ismert problémák és megoldásaik

Ez a fejezet a megerősített, ismert problémákat és a hozzájuk tartozó megoldásokat gyűjti össze.

Megnyitom a szerkesztőt, de a vásznon nem látszanak az elemek

Ha a szerkezetpanelen látszanak az elemek, a vásznon viszont nem, és Cloudflare-t használsz, az ismert ütközés a Cloudflare Rocket Loader™ (vagy más teljesítményoptimalizáló funkció) és a Bricks szerkesztő JavaScriptje között.

Az egyszerű megoldás: kapcsold be a kísérleti Rocket Loader-kompatibilitási beállítást a Bricks → Beállítások → Szerkesztő lapon (Cloudflare Rocket Loader), és töltsd újra a szerkesztő oldalát.

Kerülő megoldások

1. módszer: konfigurációs szabály a Cloudflare-ben. Hozz létre egy szabályt a szerkesztő módra:

1. Jelentkezz be a Cloudflare vezérlőpultjára.
2. Válaszd ki a fiókodat és a webhelyedet.
3. Nyisd meg a Rules → Configuration Rules részt.
4. Hozz létre új szabályt, adj neki nevet, és válaszd az egyéni szűrőkifejezést (Custom filter expression): mező URI Query String, operátor contains, érték bricks=run.
5. A „Then the settings are…” résznél add hozzá a Rocket Loader beállítást, és hagyd üresen a jelölőnégyzetet (kikapcsolva).
6. A többi beállítást hagyd üresen.
7. Mentsd a szabályt a Deploy gombbal.
8. Várj néhány percet, majd a szerkesztőben végezz kemény frissítést (töröld a böngésző gyorsítótárát).

2. módszer: a Rocket Loader kikapcsolása.

1. Jelentkezz be a Cloudflare vezérlőpultjára.
2. Válaszd ki a fiókodat és a webhelyedet.
3. Nyisd meg a Speed → Optimization részt.
4. Görgess le a Rocket Loader beállításig.
5. Kapcsold ki.

3. módszer: a SiteGround Worker Routes kikapcsolása. Ha az előző két módszer nem segít, és SiteGround tárhelyed van, nézd meg és kapcsold ki a SiteGround által létrehozott Workert:

1. Jelentkezz be a Cloudflare vezérlőpultjára.
2. Válaszd ki a fiókodat és a webhelyedet.
3. Nyisd meg a Workers Routes részt.
4. Ha van sg_worker, vagy más gyanús worker, amiről nem tudsz, törölheted.

GoDaddy MU-bővítmény miatt üres a vászon

GoDaddy-s tárhelyen, ha Cloudflare Rocket Loader nélkül is üres a vászon, az ok a GoDaddy által beinjektált MU-bővítmény lehet. A megoldáshoz add hozzá a gyermektéma functions.php fájljához (vagy egy kódrészlet-bővítménnyel) ezt a kódot, amely eltávolítja a zavaró szkriptet:

add_action( 'wp_enqueue_scripts', function() {
  if ( bricks_is_builder() ) {
    wp_dequeue_script( 'GoDaddy\WordPress\Plugins\Launch\PublishGuidepublish-guide-script' );
    wp_deregister_script( 'GoDaddy\WordPress\Plugins\Launch\PublishGuidepublish-guide-script' );
  }
}, 1000 );

Így a GoDaddy MU-bővítménye nem zavarja a szerkesztő megjelenítését.

Az elemek vagy stílusok másolása és beillesztése nem működik

A Bricks a Vágólap API-t használja elemek és stílusok különböző webhelyek közötti másolásához és beillesztéséhez.

Firefox

A Firefox szigorúbb az API olvasásával kapcsolatban, ezért a beillesztéshez kézzel kell engedélyezned:

1. Írd be a címsorba: about:config.
2. Kattints az Accept the Risk and Continue gombra.
3. Keress rá a clipboard kifejezésre, és állítsd true értékre a dom.events.asyncClipboard.readText és a dom.events.testing.asyncClipboard beállítást.
4. Indítsd újra a Firefoxot.

500-as belső szerverhiba a kezdőlap Bricks-szel való szerkesztésekor

Ha egy oldal (gyakran a kezdőlap) szerkesztésekor 500-as belső szerverhiba képernyőt kapsz, nézd meg a szerver naplóit, és módosítsd a szerver beállításait. A hiba valószínűleg egy biztonsági szerverbeállítás miatt van, amely megakadályozza, hogy a kérés eljusson a WordPressig és a Bricks-ig.

Egyes szervereken nincs megadva a SecResponseBodyLimit, és ilyen hibát ad:

ModSecurity: Output filter: Response body too large (over limit of 1048576, total not specified).

(A SecResponseBodyLimit a pufferelt választörzs legnagyobb elfogadott méretét adja meg.)

Ha a hiba megmarad, fordulj a tárhelyszolgáltatód ügyfélszolgálatához. GoDaddy-nál lehet, hogy a .htaccess fájl első sorába ezt kell beírnod:

SubstituteMaxLineLength 10M

A Blog oldalam nem a bejegyzés-archívumsablont használja

A Blog oldal (a Beállítások → Olvasás oldalon megadott „Bejegyzések oldala”) a WordPressben különleges oldal, ezért nem archívum. Ha Bricks-sablont szeretnél hozzá, a sablon feltételének az Egyedi típust válaszd, és jelöld ki a Blog oldalt.

SVG-fájlokat használok, de nem tudom a színüket módosítani

Ez általában akkor fordul elő, ha az SVG-fájl beágyazott (inline) stílusokat tartalmaz, amelyek felülírják a Bricks által generált stílusokat. Ha a Bricks stílusvezérlőivel együtt akarod használni, töröld a beágyazott stílusokat az SVG-fájlból, mielőtt feltöltöd a WordPressbe.

Az egyéni betűtípusok nem látszanak a frontenden

Ha az egyéni betűtípusok nem jelennek meg a frontenden, valószínűleg a webhelyed HTTPS-en érkezik, de a WordPress-címek még HTTP-re vannak állítva (Beállítások → Általános). Állítsd át a címeket http://-ről https://-re, és a betűtípusok megjelennek.

A YouTube-háttérvideó nem indul automatikusan mobilon

Ezt a YouTube iFrame Player API korlátozza, a Bricks nem tud rajta változtatni. A Vimeo és a helyi (mp4) videók működnek, ha a mobileszköz nincs alacsony akkumulátor módban.

A csúszka nem indul automatikusan, az animáció villog vagy nem működik

Ennek valószínű oka az operációs rendszer csökkentett mozgás vagy animáció beállítása. Ez egy akadálymentességi funkció, amelyet a Bricks tiszteletben tart.

• Windowson kapcsold be az animációk megjelenítését.
• macOS-en kapcsold ki a „Mozgás csökkentése” (Reduce motion) beállítást.

Érvénytelen tartalomtípus vagy 404-es hiba az egyéni tartalomtípusnál

Ez a WordPress egyik leggyakoribb problémája: az egyéni tartalomtípus (CPT) 404-es hibát ad. Általában könnyen megoldható.

Mentsd újra a permalink-beállításokat

Nyisd meg a Beállítások → Közvetlen hivatkozások oldalt, és kattints a Módosítások mentése gombra.

Ellenőrizd a hivatkozásnév (slug) ütközéseit

A slug egy bejegyzés, oldal, kategória, címke vagy bármilyen tartalom (akár kép) URL-barát neve; ez azonosítja a konkrét tartalmat a címben.

Tegyük fel, hogy van egy „Portfólió” oldalad portfolio slugggal, és létrehozol egy „Portfólió” egyéni tartalomtípust, amelynek slugja szintén portfolio. Ha ezután megpróbálsz megnyitni egy portfólió-bejegyzést (oldalad.hu/portfolio/bejegyzesed), szintén 404-et kapsz. Nevezd át az oldal vagy a tartalomtípus slugját, mentsd újra a permalinkeket, és működni fog.

A szerkesztő módosításai nem mentődnek

Ha mentéskor minden mentettnek tűnik, de újratöltéskor vagy a frontenden a módosítások elvesznek, az adatbázis-séma hibája lehet.

Ellenőrizd a wp_postmeta tábla meta_value oszlopát (vagy a saját előtagoddal ellátottat, például psjw_postmeta). Ennek LONGTEXT típusúnak kell lennie, hogy nagy adatmennyiséget tárolhasson. Ha kisebb kapacitású típusra, például TEXT-re van állítva, előfordulhat, hogy a nagyobb adatok nem mentődnek jól. A WordPress alapból LONGTEXT-et használ.

A javítás menete:

1. Ellenőrizd a meta_value oszlop típusát a postmeta táblában.
2. Győződj meg róla, hogy LONGTEXT.

A típust ezzel az SQL-paranccsal módosíthatod:

ALTER TABLE your_prefix_postmeta MODIFY COLUMN meta_value LONGTEXT;

Cseréld le a your_prefix_postmeta részt a saját táblanevedre (például psjw_postmeta).

3. Ellenőrizd, hogy a postmeta tábla többi oszlopa is megegyezik a WordPress alapsémájával.

Ha nem vagy biztos a dolgodban, vagy felügyelt tárhelyed van, kérj segítséget a tárhelyszolgáltatótól. A hiba tárhelyek között is továbbvándorolhat, ha a hibás adatbázissémát telepítették át.

A Bricks → Rendszerinformációk oldalon a Postmeta tábla meta_value típusa sor mutatja az aktuális típust; longtext az elvárt érték.

A mentés gomb végtelenül forog (ModSecurity)

Ha a szerkesztő mentés gombja végtelenül forog, és a szerver naplói ModSecurity-hibákra utalnak, az oka lehet, hogy egyes ModSecurity-változók túl szigorúak:

• SecRequestBodyLimit
• SecRequestBodyNoFilesLimit
• SecResponseBodyLimit

Nem garantálható, hogy ez megoldja a te problémádat, de más felhasználóknál ezeknek az értékeknek a növelése segített. Az értékek szerverenként eltérhetnek, így kísérletezned kell, vagy kérj segítséget a tárhelyszolgáltatótól.

Lekérdezésszűrő indexelő: nincs előrehaladás

Ha a Szűrő elem a szerkesztőben tartósan „Indexelés folyamatban” állapotot mutat, próbáld meg az Indexelési feladat folytatása gombot a Bricks → Beállítások → Általános → Lekérdezésszűrők részen.

Ha az indexelési feladatok továbbra is függőben maradnak, a háttérfolyamatot valószínűleg tűzfalszabály blokkolja. Nézd meg a webhely tűzfalbeállításait, vagy kérdezd a tárhelyszolgáltatódat. Ha a webhelyed HTTP-hitelesítéssel védett, a gyermektéma functions.php fájljába fel kell venned a lekérdezésszűrők fejezetében leírt kódrészletet is.

Cloudflare-proxy esetén győződj meg róla, hogy a Bot Fight Mode ki van kapcsolva, hogy ne legyenek téves riasztások.

Lassú lekérdezések a média és csatolmány dinamikus adatoknál

Ha ACF, Meta Box vagy JetEngine mezőkkel képet vagy fájlt tárolsz, a mező visszatérési értékének érdemes objektumnak vagy azonosítónak (ID) lennie, nem URL-nek. Példák mezőtípusokra:

• ACF: Kép, Galéria, Fájl
• JetEngine: Média, Galéria
• Meta Box: Fájlbemenet, Képválasztó
• Toolset: Csatolmány URL-je bejegyzés-azonosítóra

Az ok: URL-értéknél a Bricks az attachment_url_to_postid WordPress-függvénnyel kéri le a további képadatokat (méretek, elérhető méretek). Sok bejegyzésű webhelyen ez erőforrásigényes, és lassíthatja az oldalbetöltést. Ha objektumot vagy azonosítót adsz vissza, a Bricks közvetlenül eléri a szükséges adatokat, ami gyorsabb.

Árva elemek

Ritkán a Bricks elemadatai megsérülhetnek. Ez előfordulhat, ha egy szülőelemet (például egy szekciót) törölnek, de a gyermekelemei hiba miatt nem, vagy ha egy harmadik féltől származó sablon hibás adatot tartalmaz. Ezek az elemek már nincsenek érvényes szülőhöz kötve: ezek az árva elemek.

Az árva elemek nem jelennek meg sem a szerkesztőben, sem a frontenden, de az oldal adatai között megmaradnak, ami váratlan problémákhoz vezethet:

• árva szöveg jelenik meg a WPML Advanced Translation Editorban,
• hibás szűrőelem-számok,
• használaton kívüli stílusok vagy szkriptek (például ikonkönyvtárak) betöltődnek.

Árva elemek keresése és takarítása

A szerkesztő képes az árva elemek észlelésére és eltávolítására. A Bricks a szerkesztő betöltésekor automatikusan keres árva elemeket. Emellett:

1. Kapcsold be az Árva elemek keresése a szerkesztő mentésekor beállítást a Bricks → Beállítások → Általános lap Adatintegritás részén, hogy minden mentéskor ellenőrizzen.
2. Fűzd hozzá a szerkesztő címéhez a &check=orphaned paramétert, hogy kézzel kiváltsd az ellenőrzést mentéskor (hibakereséshez hasznos).

Ha talál árva elemet, értesítést kapsz egy Adatok tisztítása lehetőséggel. Erre kattintva a Bricks eltávolítja az árva elemeket az aktuális oldalról. A tisztítás után nézd át az oldalt. Ha valami elromlott, a visszavonással visszaállíthatod.

Az egész webhely árva elemeinek áttekintése

Az egész webhelyet is átvizsgálhatod a Bricks → Beállítások → Általános → Adatintegritás részen: kattints az Indítás: Árva elemek áttekintése gombra. A Bricks végigmegy az összes sablonon, oldalon és a Bricks-et használó tartalomtípuson, és felsorolja azokat, amelyekben árva elem van.

Ha nincs találat, ezt látod: „No orphaned elements found”. Ha vannak, kattinthatsz a „Clean up all orphaned elements” (az összes árva elem takarítása) gombra, amely az összes érintett bejegyzésből eltávolítja őket. Takarítás előtt érdemes biztonsági mentést készíteni.