# Ismert problémák és megoldásaik

> A Bricks leggyakoribb ismert problémái: üres vászon, vágólap, 500-as hiba, SVG-színek, betűtípusok, 404 egyéni tartalomtípusnál, mentési hibák, árva elemek.

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:

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

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

```sql
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.