JetFormBuilder – Hierarchical Select (PRO)

A Hierarchical Select akkor kerül elő, amikor többszintű kategóriát kell választatnod, és eleged van abból, hogy:
– több külön Select mezőt drótozol össze
– JavaScriptet írsz csak azért, hogy a „Márka” után a „Modell” frissüljön
– a felhasználók rossz kombinációkat választanak

Ez az addon pont azt a problémát oldja meg, hogy a választás logikája ne a user fejében legyen, hanem az űrlapban.

Egy hierarchikus taxonómiából dolgozik, és szülő–gyerek logikával vezeti végig a kitöltést.

Hogyan működik support szemmel
Fontos alapelv: ez nem több mező, hanem egy mezőtípus több szinttel.

Te kiválasztasz egy hierarchikus taxonómiát.
A mező:
– először csak a legfelső szintet mutatja
– majd a választás alapján tölti be a következő szintet
– és így tovább, ameddig felépítetted a szinteket

A felhasználó nem tud „rossz sorrendben” választani, mert nincs mit.

Ha valami nem jelenik meg, a hiba szinte mindig a taxonómia struktúrában van, nem az űrlapban.

A leggyakoribb elakadás: „üres a második szint”
Ez 90%-ban nem bug, hanem adatprobléma.

Ezt ellenőrizd sorban:
– valóban hierarchikus taxonómiát használsz
– vannak-e ténylegesen child termek a kiválasztott szülő alatt
– nem üres-e a taxonómia (backendben nézd meg)

Ha egy szülőnek nincs gyereke, a mező nem „romlik el”, hanem helyesen nem mutat semmit.

Mit ments, és miért a Term ID a jó választás
A Hierarchical Select tud:
– Term ID-t
– Slugot
– Nevet
– vagy Meta értéket menteni

Support és hosszú távú stabilitás szempontból a Term ID a biztos alap, mert:
– nem változik átnevezésnél
– nem függ nyelvtől
– nem törik multisite vagy fordítás esetén

Ha később Query Builderrel, Visibilityvel vagy Calculated Fielddel akarsz dolgozni, magadnak köszönöd meg.

Szerkesztés meglévő tartalomnál – miért nem töltődik minden ág
Ez nem hiba, hanem tervezési döntés.

Ha egy bejegyzés:
– több kategóriaághoz van rendelve

akkor frontend szerkesztésnél:
– csak egy ágat tud előtölteni a mező

Ez azért van, mert a Hierarchical Select útvonalat jelenít meg, nem teljes taxonómiahalmazt.

Ha több ág kezelése kell, akkor nem ez a mező a jó választás, hanem:
– külön taxonómia mezők
– vagy checkboxos megoldás

Új termek létrehozása – mikor hasznos, mikor veszélyes
Be lehet kapcsolni, hogy a user új child termet hozzon létre.
Ez akkor jó, ha:
– piacteret építesz
– felhasználók bővítik a katalógust

De support szemmel:
– csak akkor tedd, ha van moderáció
– és pontosan érted, mi történik a taxonómiában

Ha Calculated Fieldből számolsz term metát, az új term létrehozás kikapcsolódik – ez nem bug, hanem ütköző logika.

Mentés Post Submit Actionökkel
A mező önmagában nem ment sehova.

A mentés mindig itt dől el:
Insert / Update Post action

Itt kell:
– kiválasztani a megfelelő taxonómiát
– megadni, hogy mit mentsen (ID / slug / name)

Ha a választás „eltűnik” beküldés után, akkor:
– vagy nincs Post Submit Action
– vagy nem erre a mezőre mutat

Ez az első hely, ahol supportként megnézném.

Mire használható igazán jól
– autó, ingatlan, termék modellezés
– több lépcsős kategorizálás frontend beküldésnél
– adminisztrációt kiváltó űrlapok
– olyan esetek, ahol nem engedhetsz hibás kombinációt

Mire nem való
– tagek kiválasztására
– lapos (nem hierarchikus) adatstruktúrára
– „bármit bepipálok” jellegű szűrésre

Összefoglalás support szemmel
A JetFormBuilder Hierarchical Select nem csak kényelmi funkció, hanem adatminőség-védelem.

Ha:
– a taxonómiád rendben van
– Term ID-t mentesz
– korrekt Post Submit Actiont használsz

akkor:
– eltűnnek a rossz kategóriák
– egyszerűbb lesz a frontend beküldés
– és a felhasználó nem tud rosszat választani, még ha akarna sem

Ha szeretnéd, a következő körben végig tudjuk bontani:
– egy konkrét taxonómia felépítését
– preset + szerkesztő űrlap mintát
– vagy egy „autó > márka > modell” teljes bekötést hibapontokkal együtt