Cloudflare okozta hibák

A Cloudflare nem a WordPressben, hanem előtte áll, ezért a beállításai a Cloudflare vezérlőpultján vannak, és a kérés még a kiszolgálód elérése előtt érintik az oldalt. Két funkciója érinti az űrlapot: a Rocket Loader megváltoztatja a JavaScript futtatását, a HTML-gyorsítótárazás (Automatic Platform Optimization, röviden APO, vagy egy Cache Rule) pedig magát az oldalt tárolja. Alapértelmezés szerint a Cloudflare csak a statikus fájlokat gyorsítótárazza, az oldalakat nem.

Tünetek

• A feltételes logika vagy más JavaScriptes funkció nem csinál semmit, hibaüzenet nélkül.
• A mezők hibásan jelennek meg.
• Az űrlap nem küldhető be, vagy beküldési hibát jelez.
• Beküldés után üres képernyő jelenik meg.
• Az űrlapadatok feldolgozása hibás.
• A Mentés és folytatás váratlanul viselkedik.
• A Conversational Forms vagy más kiegészítő működése megszakad.
• Az űrlap bejelentkezve működik, de a gyorsítótárból kiszolgált nyilvános látogatóknak nem.

A gyorsítótárazott HTML okozta hiba csak akkor jelentkezik, ha az oldal már egy ideje a gyorsítótárban van. A gyorsítótár ürítése új oldalt és új biztonsági tokent hoz létre, így az űrlap azonnal újra működik, de később ismét elromlik. Ezért kijelentkezve, olyan oldalon teszteld, amely már egy ideje a gyorsítótárban áll, ne egy frissen ürítettet.

Mi okozza

Rocket Loader

A Rocket Loader az oldal kirajzolása utánra halasztja a JavaScriptet. A Gravity Forms szkriptjeinek futniuk kell a feltételes logikához, a többoldalas űrlap lapozásához és a beküldéshez, ezért a halasztás ezeket elronthatja.

Hol találod: Cloudflare vezérlőpult › Speed › Settings › Content Optimization.

Automatic Platform Optimization (APO)

Az APO a webhely HTML-jét a Cloudflare peremkiszolgálóin tárolja, és a Cloudflare WordPress-bővítményén át kapcsolható be. A gyorsítótárazott oldal az építésekor kapott biztonsági tokent hordozza, és ezt használja újra a gyorsítótár ürítéséig. A WordPress-tokenek 12 és 24 órán belül lejárnak, ezért az AJAX-os beküldések és a bejelentkezést igénylő űrlapok a lejárat után hibáznak. Az APO a bejelentkezett felhasználóknak nem szolgál ki gyorsítótárazott oldalt, ezért működhet az űrlap neked, és hibázhat mindenki másnak.

Hol találod: Cloudflare vezérlőpult › Speed › Settings › Content Optimization.

HTML-t gyorsítótárazó Cache Rule

Az a Cache Rule, amely egész oldalakat tárol, ugyanazt okozza, mint az APO, és az űrlapot is gyorsítótárazza. Az APO-val ellentétben a szabály nem hagyja ki a bejelentkezett felhasználókat, hacsak ezt a szabályban meg nem adod.

Hol találod: Cloudflare vezérlőpult › Caching › Cache Rules.

E-mail-cím elrejtés (Email Address Obfuscation)

Átírja az oldal HTML-jében az e-mail-címeket, és egy kis visszafejtő szkriptet ad hozzá. Ez megváltoztathatja a visszaigazoló szöveget vagy más, e-mail-címet tartalmazó tartalmat. Érdemes kizárni, ha semmi más nem magyarázza a viselkedést.

Hol találod: Cloudflare vezérlőpult › Security › Settings.

A hiba megerősítése

1. Kattints jobb gombbal az űrlapoldalon, válaszd az Oldal forrásának megtekintése menüpontot, és keresd a rocket-loader.min.js szöveget. Ha megtalálod, a Rocket Loader aktív az oldalon.
2. Nyisd meg a böngésző fejlesztői eszközeit, töltsd újra az oldalt, és válaszd ki a dokumentumkérést (magát az oldalt, nem stíluslapot vagy szkriptet). Nézd meg a cf-cache-status fejlécet. A HIT azt jelenti, hogy a Cloudflare gyorsítótárazott másolatot adott. A DYNAMIC azt, hogy a HTML nem volt gyorsítótárban.
3. Az űrlapot kijelentkezve, privát ablakban teszteld. Az APO a bejelentkezett felhasználóknak nem adja a gyorsítótárazott HTML-t, ezért ha WordPressbe belépve működik az űrlap, az még nem teszt.
4. Ha a gond szkriptekkel vagy tartalommal van, nem tokenekkel, kapcsolj ki ideiglenesen egyszerre egy beállítást (Rocket Loader, Email Address Obfuscation), és minden után próbáld ki újra az űrlapot.
5. Ha úgy tűnik, hogy beküldések tűnnek el, nyisd meg az Űrlapok → Bejegyzések oldalt, és nézd meg a Spam nézetet. A bejegyzés jegyzetei megnevezik a szűrőt, amely megjelölte.

A hiba elhárítása

1. Kapcsold ki a Rocket Loadert a Speed › Settings › Content Optimization oldalon, és próbáld újra. Ez a leggyorsabb módja, hogy megerősítsd vagy kizárd. Ha máshol be akarod hagyni, hozz létre egy Configuration Rule szabályt a Rules › Configuration Rules alatt, amely csak az űrlapokat tartalmazó URL-eken kapcsolja ki.
2. Ha a HTML gyorsítótárba kerül, zárd ki az űrlapoldalakat: vagy adj hozzá egy Cache Rule szabályt a Caching › Cache Rules alatt, amely ezeknél az URL-eknél megkerüli a gyorsítótárat, vagy zárd ki őket az APO-ból.
3. Ha a visszaigazolásban vagy más tartalomban az e-mail-címek átalakítottnak látszanak, kapcsold ki az Email Address Obfuscation funkciót, és próbáld újra.
4. Minden változtatás után ürítsd a gyorsítótárat a Caching › Configuration oldalon, majd teszteld privát ablakban.
5. A Development Mode három órára ideiglenesen megkerüli a gyorsítótárazást, ami tesztelésnél hasznos, de magától lejár, ezért nem megoldás. A Rocket Loader független a Development Modetól, külön kell kikapcsolni.
6. Ha kiderült, melyik beállítás a hibás, a többit hagyd bekapcsolva. Ha a gond megmarad, fordulj a Cloudflare ügyfélszolgálatához, vagy a tárhelyszolgáltatódhoz, ha ő kezeli a Cloudflare-fiókodat.

A részletes általános leírást lásd a gyorsítótár és szkriptoptimalizáló fejezetében, a spamnek jelölt beküldésekről pedig a spamvédelem fejezetében.

A külső szolgáltatásokat csak javaslatként említjük: nem teszteljük és nem támogatjuk őket, ezért a megfelelőségükről neked kell meggyőződnöd.