Yearly Archives :

2025

Gravity Forms űrlap küldés utáni anchor scroll hiba és megoldás

Gravity Forms űrlap küldés utáni anchor scroll hiba és megoldás 1200 630 bacsoa

Teljesen véletlenül találkoztam egy hibával és ha már az lett belőle, megoldást is keresnem kellett hozzá. És mivel találtam, gondoltam leírom ebben a cikkben, hátha másnak is segít.

A Gravity Forms az egyik legrégebbi űrlapkezelő WordPress bővítmény, kb. azóta használom, amióta megjelent. Nem ingyenes, de a Contact Form 7-nél (jó az is) sokkal többet tud és már egy átlagos feladathoz is többféle megoldást nyújt. Van hozzá bőséges dokumentáció és számtalan kiegészítő, amivel akár egy egész komplex felhasználó adatbázist és a hozzá tartozó viselkedésmintákat is fel lehet építeni.

Vannak hivatalos, „házon belüli” kiegészítők (ún. add-on-ok), és külsős cégek által fejlesztettek (pl. Gravity Perks, Gravity Flow). Egy ilyen hivatalos kiegészítő a Gravity Quiz, amivel egyszerűbb kvízjátékokat lehet készíteni. Nincs annyira túlbonyolítva, inkább csak ilyen kérdezz-felelek típusú űrlapokat lehet vele készíteni. Az űrlap kitöltése után a benne lévő adatokat el lehet küldeni POST kéréssel, vagy a háttérben AJAX-hívással. A kettő között az a különbség, hogy a POST kérésnél az oldalt ahova az űrlapot beintegráltuk küldés után elhagyjuk és átkerülünk egy másik oldalra, azaz újratöltődik minden. Az AJAX-hívásos módszerben az űrlapkezelő a szerverre küldi el az adatokat, majd onnan visszajön a válasz.

Most egy Gravity Quiz űrlapot csináltam, de az AJAX-kérés nem működött, hiába nyomogattam a Küldés gombot, nem történt semmi, az űrlap nem lett elküldve. Számtalan lehetséges megoldás van rá (most nem írom le az összeset), de nekem most egyik sem működött.

Így átváltottam normál, POST kérésre, amivel egyből jó lett. A probléma nem is ez volt, hanem az, hogy a küldés után nem ugrott, azaz görgetett oda a „Köszönjük, hogy elküldted az űrlapot” üzenethez. Az üzenet megjelent, de a böngésző a fejlécet mutatta, tehát a body elemnél állt. Itt is végigpróbáltam aztán több módszert, de az volt az érdekes, hogy az URL-be semmilyen paramétert nem adott át, csak egy kérdőjel jelent meg, üresen. Se GET paraméterek, se anchor / hashtag, se semmi.

Aztán rátaláltam a gform_confirmation_anchor hookra, ami egy csapásra megoldotta. Hogy pontosan mi is volt a hiba, azt egyelőre nem tudom (végigtúrom majd a Gravity Forms saját hibanaplóját, abban talán találok valamit), de ez a one-liner megoldotta a problémát:

add_filter( 'gform_confirmation_anchor', '__return_true' );

Mindenkinek eredményes kódolást és hibakeresést kívánok!

WooCommerce mini kosár (minicart) frissülési hiba javítása

WooCommerce mini kosár (minicart) frissülési hiba javítása 2000 1200 bacsoa

Valószínűleg mindenki látott már webáruházak fejlécében kosár ikont számokkal, melyek a kosárban lévő tételeket mutatják.

Erre a WooCommerce-ben van egy dedikált hook, amely kosár frissítésekor az ajax hívás befejezésekor bizonyos DOM elemeket – pl. a fejlécben egy konténerben a kosarat – frissítsen (ld. Mike Jolley eredeti gist bejegyzését). Ha valaki lusta kattintani, akkor itt van egy hasonló:

<?php
add_filter('woocommerce_add_to_cart_fragments', 'custom_header_cart_fragment');
function custom_header_cart_fragment( $fragments )
{
  ob_start();
  ?>
  <div class="header-cart-wrapper">
      <a class="header-cart-link" href="<?php echo esc_url(wc_get_cart_url()); ?>">
          Kosár (<?php echo WC()->cart->get_cart_contents_count(); ?>)
      </a>
  </div>
  <?php
  $fragments['div.header-cart-wrapper'] = ob_get_clean();

  return $fragments;
}

?>

A „párja” pedig, amit a fejlécbe kell tenni, az pedig így néz ki:

<div class="header-cart-wrapper">
    <a class="header-cart-link" href="<?php echo esc_url(wc_get_cart_url()); ?>">
        Kosár (<?php echo WC()->cart->get_cart_contents_count(); ?>)
    </a>
</div>

Fontos, hogy a <div class="header-cart-wrapper">-rel kezdődő sor mindkét kódban ugyanaz maradjon, mivel a WooCommerce hook a $fragments objektumban erre a class-ra fog hivatkozni, tehát ha átírjuk a fejlécben lévő header-cart-wrapper CSS osztályt, akkor nem fogja megtalálni.

Ez volt eddig az egyszerű rész, évek óta használom, sose volt vele gond. Most azonban mégis belefutottam egy hibába, ami egy kis utánanézést és magyarázatot igényel. Pár napja az egyik ügyfélnek be kellett tenni a fejlécébe egy kosarat (nem voltak neki előtt WooCommerce az oldalában), de valamiért hiába tettem be a fenti woocommerce_add_to_cart_fragments kódot, az nem akarta frissíteni a kosarat.

Még a ChatGPT-t is megkérdeztem, de nem talált megoldást, én viszont igen. Elkezdtem debuggolni és észrevettem, hogy a /wp-content/plugins/woocommerce/assets/js/frontend/cart-fragments.min.js JavaScript nincs inicializálva. Egy WP Rocket-hoz (cache plugin) kapcsolódó WooCommerce github bejegyzés világított rá a megoldásra. A lényeg, hogy a WooCommerce 7.8-as verzióban kivezették a mini cart scriptet, mert túl sok felesleges ajax kérérst generált, ami lassította nemcsak a WooCommerce, de az egész weboldal működését, ahol WooCommerce volt telepítve. Akit érdekelnek a részleteket, az elolvashatja a WooCommerce fejlesztői blogban az erről szóló bejegyzést is.

Tehát ha a WooCommerce 7.8 vagy újabb verzió után szeretnénk használni ezt az automatikusan frissülő mini kosár funkciót, akkor nekünk kell azt engedélyezni, mégpedig a következő PHP kóddal (functions.php-ba, vagy külön pluginba szervezve kell tenni ezt is):

add_action('wp_enqueue_scripts', 'enable_wc_cart_fragments_script', 100);
function enable_wc_cart_fragments_script()
{
  if (is_woocommerce() || is_cart() || is_checkout()) {
    wp_enqueue_script('wc-cart-fragments');
  }
}

És működik, voilá!

HTML sitebuild, CSS és saját grid rendszer

HTML sitebuild, CSS és saját grid rendszer 2000 1333 bacsoa

Mi az a grid rendszer? A sitebuilderek (erre aztán tényleg nincs egy normális magyar szó, a weboldal készítő nem igazán fedi le ezt) weboldalak szélességét általában a gyakran használt képernyőméretekhez igazítják. Eleinte a képernyők felbontása 1024×768 pixel volt. Aztán jött az 1200×800, majd az 1366×768. Meg persze a full HD (1920×1080) és minden más. A Macbook Air megjelenésével elkezdtek megjelenni a 16:9-től eltérő képarányok is, mint pl. az 1440×900. Egy idő után már annyira sokféle volt, hogy kellett valami olyan szabvány, ami a kijelzők felbontásának nagyrészén elfér, azaz a maximális szélességnél kisebb. Ez 1140 pixel lett.  Tehát az 1140 pixel széles grid rendszer azt jelenti, hogy a weboldalak látható maximális szélességét 1140 pixelben maximalizálja a fejlesztő. Ez azért jó, mert ha egy 1200 pixel széles kijelzőn nézi valaki az adott weboldalt, ott el fog férni a teljes tartalom, tehát nem fog kilógni és nem kell horizontálisan scrollozni. Persze van, aki 1160 vagy 1200 pixel szélességet használ attó függ.

Mivel ma már nem kell szenvedni az Internet Explorer miatt (mivel a Microsoft Edge böngészője is a Chromium engine-t használja), ezért a modern böngészők elterjedése miatt gyakorlatilag bármilyen grid rendszert használhatunk, mert vannak többek között olyan CSS defínciók, mint a max-width, vagy olyan mértékegységek, mint a vw ami lehetővé teszi, hogy az adott böngészőhöz dinamikusan igazítsuk a megjelenítést. Sokáig az Internet Explorer miatt, nekünk fejlesztőknek olyan trükkökhöz kellett folyamodni, mint hogy külön Internet Explorer CSS-t kellett írni, mert sok amúgy teljesen szabvány HTML paramétert vagy defíníciót, (mint pl. az inline-block!), az IE nem támogatott. Ez a probléma rengeteg olyan dolgot termelt ki magából, mint pl. a Can I Use?, ahol ellenőrizhetjük, hogy az adott definíciót, paramétert mi támogatja.

Ma már sok weboldalhoz arányosított CSS defíníciókat is készíthetünk, emiatt a pixelben megadott széles grid rendszerek már csak iránymutatók, kb bármilyen képernyőszélességhez írhatunk külön megjelenítést. A sokfajta mobileszköz miatt erre szükség is van. Az arányosított CSS defíníciók, mint az 1em (az alapértelmezett pixelben megadott értékhez képesti 1 egység) , vagy 100vw (a böngésző 100% szélessége) és a betűk méretére megadható százalékos arányokkal (font-size: 1.2vw, ami az adott szélességhez 1.2x-es méretet jelent) meg tudunk csinálni egy teljesen reszponzív, nem is pixelben megadott szélességű oldalt is.

A grid rendszerekből sokféle elérhető van, pl. az 1200px , vagy az 1400, de ezt felsorolni is nehéz. Aztán ott van a legelterjedtebb a Bootstrap, ami már nem is grid rendszer, hanem egy régóta létező CSS keretrendszer (framework), aminek előnye, hogy pillanatok alatt meg tudsz csinálni egy weboldalt, a „beépített” azaz előre megírt grid rendszerrel. Itt nemcsak az felosztott konténerméreteket tudod egy CSS class-szal megadni (pl. 1/3 – 1/3 – 1/3 szélességű háromra osztott elemek egymás mellett), hanem űrlapok, lenyílók, gombok, menük stílusa és sok minden előre meg van írva. Hátránya, hogy neked kell alkalmazkodnod egy meglévő rendszerhez és rengeteg olyan dolgot is kapsz mellé, amire nincs szükséged (van hozzá rengeteg Javascript is), emiatt lassabb mint egy meglévő rendszer. A másik, amit nem szeretek benne, hogy minden weboldal, amit Boostrappel csinálsz nagyon hasonló kinézetű és működésű lesz, hiszen ugyanazokat a definíciókat használod, max más színekkel.

Valójában ma már nem igazán éri meg a nulláról lebuildelni egy oldalt saját grid alapon. Előnye, hogy gyors, hátránya, hogy sok idő, ami sok pénz. Így inkább valamelyik jól bevált sablonnal, az abba beépített valamelyik népszerű page builderrel (WP Bakery, Elementor, Gutenberg, stb.) csinálom meg az ügyfél által megálmodott weboldalt. Ő ugyanazt kapja, csak gyorsabban és költséghatékonyabban.