# Hibaelhárítás

> Módszeres hibakeresés egy Bricks-es webhelyen: reprodukálás, gyors ellenőrzések, kizárásos teszt, hiányzó adatok, hibajelentés.

Egy Bricks-szel épített webhely több részből áll, nem csak a Bricks-ből: a WordPress, a bővítmények, az egyéni kód, a böngésző, a gyorsítótárak, a CDN, a webszerver, a PHP és az adatbázis mind befolyásolja, amit látsz. Ha valami nem működik, először azt kell kideríteni, melyik rész okozza.

A tapasztalat szerint a leggyorsabb a kizárásos módszer: kezdd néhány ártalmatlan ellenőrzéssel, majd teszteld a webhelyet csak azokkal az összetevőkkel, amelyek a hiba előidézéséhez kellenek. Az útmutató akkor is érvényes, ha a hiba a szerkesztőben, a frontenden, mentéskor, frissítés után vagy máshol jelentkezik.

## Több mozgó alkatrész

A Bricks-ben látszó hiba nem feltétlenül a Bricks-ből indul. A főbb érintett részek:

- a böngésző és a kiegészítői,
- a WordPress, a Bricks és más bővítmények,
- az aktív téma és az egyéni kód,
- a böngésző-, bővítmény-, szerver- és CDN-gyorsítótárak,
- optimalizáló és biztonsági szolgáltatások,
- a PHP, a webszerver és az adatbázis.

Például egy végtelenül forgó mentés gomb szerkesztői hibának tűnik, de a kérést blokkolhatja egy böngészőkiegészítő, visszautasíthatja egy biztonsági bővítmény, megszakíthatja egy PHP-hiba, vagy egy tűzfalszabály. A hibakeresés lényege, hogy a lehetséges okokat egyenként kizárod.

## Győződj meg róla, hogy reprodukálható a hiba

Mielőtt bármit megváltoztatnál, ismételd meg a műveletet, amely a hibát okozza. Elég, ha tudod:

- milyen művelet váltja ki,
- mit vártál,
- mi történt helyette,
- csak egy oldalt érint, vagy az egész webhelyet,
- minden alkalommal előfordul-e.

A leírás legyen tényszerű. „A mentés jelzése forog, és újratöltés után a régi tartalom jön vissza” hasznosabb, mint „a Bricks nem tud menteni”.

Ha a hiba nem következetes, nézd meg, mi változik a próbálkozások között: függhet adott oldaltól, böngészőtől, felhasználói szerepkörtől, képernyőmérettől, mezőértéktől vagy gyorsítótárazott választól.

Ha a tesztelés érintheti a látogatókat, rendeléseket, űrlapokat, tagságokat, tárolt tartalmat vagy a webhely beállításait, használj tesztkörnyezetet (staging). Hiányzó adatok, sikertelen mentések, migrálás vagy adatbázisproblémák vizsgálata előtt készíts biztonsági mentést.

## Kezdd a gyors ellenőrzésekkel

Zárd ki az egyszerűen tesztelhető okokat, amelyek nem igényelnek változtatást a webhelyen:

1. Nyisd meg az érintett oldalt privát böngészőablakban.
2. Próbálj ki másik böngészőt.
3. Kapcsold ki ideiglenesen a böngészőkiegészítőket.
4. Ürítsd a böngésző, a WordPress, a szerver és a CDN gyorsítótárát.
5. Kerüld meg ideiglenesen a JavaScript-késleltetést, a kicsinyítést, a szkriptek összevonását és hasonló optimalizálási funkciókat.

Minden teszt után ismételd meg ugyanazt a műveletet.

Ha a hiba csak egy böngészőben jelentkezik, az ok valószínűleg annak a böngészőnek vagy kiegészítőjének a sajátja.

Ha a gyorsítótár ürítése átmenetileg megoldja, derítsd ki, melyik gyorsítótár adott ki elavult választ, különben a hiba visszatér, amikor az újra feltelik.

## Izoláld a webhelyet

Ha a gyors ellenőrzések nem hozzák meg az eredményt, teszteld a webhely minimális változatát tesztkörnyezetben.

Hagyd aktívan a Bricks-et. Ha a hiba másik bővítményhez kapcsolódik, azt is hagyd aktívan. A többi bővítményt, egyéni kódrészletet, gyorsítótárazást és optimalizálást kapcsold ki. Például ha a Bricks és egy többnyelvűsítő bővítmény együttműködését vizsgálod, csak a kettő legyen aktív.

Ezután ürítsd az összes gyorsítótárat, és ismételd meg az eredeti lépéseket.

### Ha a hiba megszűnik

Valami, amit kikapcsoltál, része volt a hibának. Egyesével kapcsold vissza a bővítményeket és funkciókat, és minden után ismételd meg a tesztet. Amikor a hiba visszatér, az utolsóként bekapcsolt összetevő része az ütközésnek.

Lehet, hogy ez az összetevő önmagában jól működik: a hiba csak két bővítmény, beállítás vagy szkript együttműködésekor jelentkezhet. A feltételezett kombinációt tesztelve erősítsd meg az eredményt.

### Ha a hiba megmarad

A legtöbb harmadik féltől származó bővítményt, egyéni kódot, gyorsítótárazást és optimalizálást kizártad. Szűkítsd tovább a tesztet:

- próbáld ugyanazt a műveletet egy új oldalon,
- lehetőleg használj egy alap Bricks-elemet,
- teszteld szabvány témával,
- próbálj ki másik rendszergazdai fiókot,
- távolítsd el a hiba kiváltásához nem szükséges tartalmat,
- teszteld egy friss WordPress-telepítésen, csak a Bricks-szel,
- ha másik bővítmény is érintett, csak a Bricks és az a bővítmény legyen aktív.

Egy ilyen folyamatot túlélő hibát sokkal könnyebb kivizsgálni, mert kevesebb rész lehet felelős.

## Kövesd a bizonyítékokat

Nem kell minden diagnosztikai ellenőrzést elvégezned. A látható tünet alapján döntsd el, hol nézz tovább.

### Hasonlítsd össze a szerkesztőt és a frontendet

Ha a hiba egy Bricks-oldalt érint, nézd meg ugyanazt az oldalt a szerkesztőben és a frontenden is.

- Ha a szerkesztőben jó, a frontenden nem: nézd meg a gyorsítótárat, a generált CSS-t, a sablonfeltételeket, a megjelenítési beállításokat és a frontend kódot.
- Ha az elemek látszanak a szerkezetpanelen, de a vásznon nem: nézd meg a CSS-t, a JavaScriptet, a böngészőkiegészítőket és az optimalizálást.
- Ha az elemek a szerkezetpanelről is hiányoznak: nézd meg a változatokat és a tárolt adatokat, mielőtt újra mentenéd az oldalt.
- Ha a frontend bejelentkezve működik, kijelentkezve nem: nézd meg a nyilvános gyorsítótárat, a sablonfeltételeket, a jogosultságokat és a frontend kéréseket.

Ellenőrizd, hogy az oldal a **Megjelenítés Bricks-szel** módot használja-e, ha azt várod, hogy a Bricks jelenítse meg az elrendezést. A **Megjelenítés WordPresszel** mód a WordPress tartalmát használja. Ennek a beállításnak a módosítása nem törli a mentett Bricks-elrendezést.

### Nézd meg a sikertelen böngészőkéréseket

Nyisd meg a böngésző fejlesztői eszközeit, és ismételd meg a műveletet. A **Console** fülön JavaScript-hibákat, a **Network** fülön sikertelen vagy blokkolt kéréseket találsz. A `401`, `403`, `404` és `500` állapotkódok segítenek megtalálni a következő vizsgálati pontot.

A sikertelen kérés érkezhet a WordPresstől, a Bricks-től, másik bővítménytől, biztonsági szolgáltatástól vagy a szervertől. A válasz törzse gyakran többet árul el, mint az állapotkód.

### Nézd meg a WordPresst és a szervert

Nyisd meg a **Bricks → Rendszerinformációk** oldalt, és nézd át a WordPress, a Bricks, a PHP, az adatbázis, a szerver és az aktív bővítmények adatait. Hasonlítsd össze a környezetet a Bricks rendszerkövetelményeivel.

Ha a böngésző sikertelen kérést mutat, keresd meg az időpontját a PHP- és a webszerver-naplókban. Ezeket keresd:

- PHP-hibák,
- kimerült memória,
- végrehajtási időkorlátok,
- kérésméret-korlátok,
- fájljogosultsági hibák,
- blokkolt REST API-kérések,
- ModSecurity- vagy tűzfalszabályok,
- sebességkorlátozás,
- SSL- vagy proxy-konfigurációs hibák.

Az időpont, a kérés URL-je, az állapotkód és a hozzá tartozó naplóbejegyzés általában jobb támpont, mint maga a látható hibaüzenet.

## Ha hiányzik a tartalom vagy a mentett adat

Ne mentsd tovább az érintett oldalt, amíg nem tudod, visszaállítható-e egy korábbi változat. Egy újabb mentés felülírhat egy hasznos változatot vagy automatikus mentést.

Nyisd meg a szerkesztőben a **Kezelés → Előzmények / Változatok** részt, és nézd meg az elérhető verziókat, mielőtt egyet alkalmaznál. Ha egy korábbi változat tartalmazza a hiányzó tartalmat, állítsd vissza, és ellenőrizd az oldalt. A biztonsági mentést tartsd meg, amíg nem érted, miért tűnt el vagy vált olvashatatlanná az adat.

### Webhely-migrálás után

A migrálás érintheti az URL-eket, a szerializált adatokat, a fájlútvonalakat, a jogosultságokat, a gyorsítótárakat és az adatbázis-beállításokat.

A frontend továbbra is gyorsítótárazott HTML-t mutathat, miközben a célhelyen az adatbázis olvashatatlan szerkesztői adatot tartalmaz. Mielőtt azt gondolod, hogy a migrálás mindent megőrzött, ellenőrizd a szerkesztőt és egy gyorsítótár nélküli frontendkérést is.

A Bricks elemadatai PHP-szerializált értékeket is tartalmazhatnak. Egy egyszerű szöveg- vagy SQL-csere úgy módosíthat egy URL-t, hogy a tárolt szöveghossz nem frissül, és a WordPress később nem tudja olvasni az értéket.

Ha migrálás után hiányzik a tartalom:

1. Ne mentsd tovább az érintett oldalakat a célhelyen.
2. Nézd meg, megnyílik-e a tartalom a forráswebhelyen.
3. Ellenőrizd a migrálás előtti biztonsági mentést.
4. Győződj meg róla, hogy a migrálóeszköz kezeli a PHP-szerializált adatokat.
5. Ha kell, ismételd meg a migrálást ép forrásból.

Ne futtass nyers SQL `REPLACE()` lekérdezést a Bricks bejegyzés-metaadatain: az adatbázis egészére kiterjedő URL-csere megrongálhatja a szerializált adatokat. A WP-CLI `search-replace` parancsa kezeli a szerializált adatokat, és próbafuttatást (dry run) is támogat.

### Speciális karakterek megadása után

Ha a tartalom eltűnik, miután okos idézőjelet, nem törhető kötőjelet, emojit vagy más speciális karaktert mentettél, nézd meg az adatbázis részt a **Bricks → Rendszerinformációk** oldalon.

- A zöld `utf8mb4_*` érték kompatibilis.
- A figyelmeztetés azt jelenti, hogy a tábla nem kompatibilis `utf8mb4` kollációt használ.
- Az ismeretlen azt jelenti, hogy a Bricks nem tudta lekérni a kollációt.

A kollációt kijavítva megelőzhető ugyanez a tárolási hiba a későbbi mentéseknél, de a már sérült adatot nem állítja vissza. Az érintett oldalt állítsd vissza változatból, automatikus mentésből, ép forráswebhelyről vagy adatbázis-mentésből. Éles adatbázis kollációjának módosításához ellenőrzött biztonsági mentés és WordPress-adatbázis-kezelésben jártas szakember kell.

## Nézd meg, ismert-e már a hiba

Ha izoláltad a hibát, keress rá az ismert problémák között (lásd az **Ismert problémák és megoldásaik** fejezetet) megerősített ütközésre vagy kerülő megoldásra. Keress rá a Bricks fórumán is a látható tünettel, a hibaüzenettel vagy az érintett összetevőkkel. Lehet, hogy más már jelentette ugyanezt.

Az izolálás eredményei hasznosabbá teszik a keresést: ahelyett, hogy „nem működik a szerkesztő”-re keresnél, konkrét kéréshibára, bővítménykombinációra, elemre vagy műveletre kereshetsz.

## Lehetséges hiba reprodukálása és jelentése

A Bricks-ben is lehetnek hibák. Ha izolálás után is fennáll a probléma, próbáld reprodukálni egy friss WordPress-webhelyen. A beállítás legyen a lehető legkisebb:

- a Bricks,
- a hiba kiváltásához szükséges bővítmények,
- egy oldal vagy sablon,
- csak a teszthez szükséges elemek és beállítások.

Ha a hiba itt is előjön, keress rá újra az ismert problémák között és a fórumon az újonnan szerzett információkkal. Ha nincs megfelelő bejelentés, jelentsd lehetséges hibaként. Add meg:

- a szükséges minimális bővítményeket,
- a hibát kiváltó pontos lépéseket,
- mit kellene tennie,
- mi történik helyette,
- minden alkalommal előfordul-e,
- a böngésző- vagy szerverhibákat,
- ha adott tartalom kell hozzá, egy kis sablon vagy oldal exportját.

Egy jó reprodukció így nézhet ki:

1. Telepíts WordPresst, és aktiváld a Bricks-et.
2. Hozz létre egy oldalt **Űrlap** elemmel.
3. Kapcsold be a megadott beállítást.
4. Küldd be az űrlapot kijelentkezve.
5. A kérés `403`-as választ ad az beküldés létrehozása helyett.

Az ilyen lépésekkel más a te webhelyed nélkül is reprodukálhatja a viselkedést.

Ha a hiba csak az eredeti webhelyen jön elő, a környezet vagy a tárolt adat is része a problémának. Hasonlítsd össze azt a webhelyet a tiszta teszttel, amíg meg nem találod a lényeges különbséget.

## AI-asszisztens használata a vizsgálat során

Csevegőasszisztensek, például a ChatGPT vagy a Claude segíthetnek értelmezni egy hibát, összevetni, mit teszteltél már, és javasolni a következő ellenőrzést. Illeszd be a lényeges hibaüzeneteket, és írd le, mi történt, de előtte töröld a privát információkat.

Egy ügynök, például a Codex vagy a Claude Code még többet tud, ha olyan környezetben fut, ahol hozzáfér a webhely fájljaihoz, a parancssorhoz, a böngészőhöz vagy a tárhelyfiókhoz. Egy ügynök használata nem ad automatikusan hozzáférést ezekhez a rendszerekhez: te döntöd el, milyen eszközöket és hitelesítő adatokat használhat.

Ha a kísérleti Bricks AI-képességeket és -készségeket használod, egy csatlakoztatott ügynök olvashatja a Bricks rendszerinformációit, az oldalszerkezetet, az elemeket, a változatokat és a bekapcsolt képességek által elérhetővé tett egyéb webhelyadatokat. Ez segíthet összehasonlítani az érintett oldalt egy működővel, megtalálni a bővítmény- és környezetbeli különbségeket, és megvizsgálni a látható hiba mögötti állapotot.

Kezdd csak olvasható hozzáféréssel, tesztkörnyezetben. Ha ez nem elég, az opcionális `bricks/execute-php` képesség lehetővé teszi, hogy egy jogosult ügynök célzott, egyszeri PHP-kódot futtasson a webhely WordPress-környezetében. Megvizsgálhatja az aktív bővítményeket, a regisztrált kampókat, a PHP-konfigurációt, az ütemezett eseményeket, a fájlútvonalakat és jogosultságokat, valamint a PHP-folyamat által olvasható fájlokat és naplókat. Reprodukálhat egy bővítményfüggvényt valódi webhelyadatokkal, vagy kifejezetten jóváhagyott fájl- vagy adatjavítást végezhet a következő teszt előtt.

A közvetlen PHP-futtatás nincs elkülönített környezetben (sandbox). Csak mentett, helyi vagy tesztwebhelyen kapcsold be, kérd meg az ügynököt, hogy írás előtt magyarázza el a javasolt műveletet, és a vizsgálat után kapcsold ki. A PHP-folyamat jogosultságain kívül eső szerverkonfigurációhoz és naplókhoz továbbra is tárhely- vagy szerverhozzáférés kell.

Példa kérés egy ügynöknek:

```
Segíts kivizsgálni egy hibát ezen a Bricks-szel épített WordPress-webhelyen.
Mi történik: [írd le a tünetet]
Várt eredmény: [mit kellene történnie]
Reprodukció: [pontos lépések]
Már kipróbáltam: [böngésző, gyorsítótár és izolálás eredményei]
Kezdd csak olvasható Bricks-képességekkel. Ha egy célzott PHP-ellenőrzés szűkítené az okot, futtatás előtt mondd el a pontos kódot és a várt kimenetet. Jóváhagyásom nélkül ne módosíts fájlt vagy webhelyadatot.
```

Hibák vagy konfiguráció megosztása előtt töröld a jelszavakat, sütiket, nonce-okat, licenckulcsokat, API-kulcsokat, személyes adatokat és az adatbázis-hitelesítő adatokat.