MB Revision

Strukturált tartalomnál ritkán az a kérdés, mi legyen az aktuális érték. Sokkal inkább az, hogy mi volt előtte, és hogyan jutsz vissza oda, ha valami félremegy. A WordPress alap revíziórendszere erre csak félig válasz: a cím és a fő tartalom visszaállítható, a valódi adat – az egyedi mezők – viszont nem.

Az MB Revision pontosan ezt a vakfoltot szünteti meg. Nem új workflow-t hoz be, nem külön verziókezelést épít, hanem ugyanabba a revíziólogikába emeli be az egyedi mezőket, amit a WordPress már eleve használ.

Beállítási szemlélet: ezt a bővítményt nem azért aktiválod, mert „jó, ha van”, hanem mert nem engedheted meg magadnak az adatvesztést strukturált mezőknél.

Mit jelent ez a gyakorlatban, nem technikailag?

Amikor egy bejegyzést frissítesz, a rendszer eddig is készített revíziót. Az MB Revision annyit tesz hozzá, hogy nem hagyja ki belőle az adatmodell 90%-át. A mezők, csoportok, kapcsolt értékek ugyanúgy verziózódnak, mint a szöveg.

Ez nem export, nem snapshot, nem backup. Ez folyamatos, beépülő változáskövetés.

Tanács: ha a szerkesztő „nem emlékszik, mit állított el”, az nem fegyelmi kérdés, hanem rendszertervezési hiányosság. Itt oldod meg.

Hogyan „gondolkodik” a rendszer a változásokról?

A revízió nem mezőszinten él önmagában, hanem állapotként. Egy mentés = egy teljes állapot. Amikor összehasonlítasz, nem csak azt látod, hogy „változott”, hanem hol és miben.

A tömbös, csoportos adatok JSON-ként jelennek meg. Ez elsőre technikainak tűnhet, de valójában ez az egyetlen őszinte módja annak, hogy lásd, egy komplex mezőstruktúra pontosan hogyan módosult.

Beállítási tanács: ha sok csoportmezőt használsz, érdemes konzisztens mező-ID-ket és logikus csoportosítást alkalmazni – a diff nézet csak akkor lesz gyorsan értelmezhető.

Visszaállítás: mi történik valójában?

Amikor egy korábbi revíziót visszaállítasz, nem „egy mezőt”, hanem a teljes bejegyzés adatállapotát hozod vissza. Ez fontos mentális váltás.

Ezért:

• nincs részleges rollback
• nincs „csak ezt az egy mezőt”
• viszont van garantált konzisztencia

Tanács: szerkesztőségi környezetben érdemes kommunikálni, hogy a visszaállítás felülír mindent. Így elkerülhető a véletlen adatvesztés.

Mikor életmentő, nem csak kényelmes?

Akkor, amikor:

• landing oldalak mezőkből vannak összerakva
• kampány közepén módosítanak CTA-t, árakat, kapcsolókat
• több ember dolgozik ugyanazon az oldalon
• auditálni kell, ki mit változtatott

Ilyenkor az MB Revision nem „extra”, hanem biztonsági háló.

Beállítási tanács: kritikus CPT-knél (pl. termék, landing, projekt) mindig ellenőrizd, hogy a revisions támogatás ténylegesen engedélyezve van a post type-nál – ez gyakori kihagyás.

Amit nem tud – és fontos tudni róla

Ez a bővítmény:

• nem kezeli a user meta vagy term meta revíziókat
• nem verziózza a beállítási oldalakat
• a WordPress revíziókorlátait örökli (darabszám, DB-méret)

Ez nem hiba, hanem hatókör.

Tanács: ha sok meződ van és gyakori a mentés, érdemes átgondolni a revíziók számának globális korlátozását, hogy ne nőjön feleslegesen az adatbázis.

Kapcsolódás más Meta Box elemekhez

Az MB Revision akkor igazán erős, ha:

• MB Group-pal együtt használod (összetett modulok)
• strukturált, nem „szabad szöveges” adatmodelled van
• tudatosan tervezed, mi mező, mi tartalom

Ha custom table-t használsz, mindig teszteld stagingen a visszaállítást – a kompatibilitás jó, de a lekérdezési logikádon múlik, mit látsz viszont.

Mikor jó döntés az MB Revision?

Ha:

• a mezők nem díszítések, hanem üzleti adat
• fontos a gyors hibajavítás
• több ember szerkeszt
• nem akarsz „kézzel visszaépíteni” egy korábbi állapotot

És mikor nem?

• ha a Meta Boxot csak 1–2 dekoratív mezőre használod
• ha nincs szükséged visszanézhető előzményekre
• ha a tartalom jelentős része nem mezőkben él

Záró gondolat

Az MB Revision nem csinál látványos dolgokat. Nem gyorsítja fel az építést, nem ad új UI-elemet. Viszont megbízhatóvá teszi azt, amit már felépítettél.

És strukturált tartalomnál ez a különbség a „működik” és a „biztonságosan működik” között.