Ugyanaz az oldal, más alapokon

Az oldal közben végig működött

A magazinnál folyamatosan jelennek meg cikkek, és van, amikor ez órákon múlik: egy esti koncert előtt készült interjúnak aznap ki kell kerülnie. Ez a munka legfontosabb kerete — az oldal nem állhatott le, és nem is lehetett „majd egyszer” átkapcsolni egy kész új verzióra.

Az első hónapokban ezért közvetlenül az élő oldalon dolgoztam, kisebb lépésekben. 2025 decemberében ez visszaütött: egy módosítás után az oldal időnként nem töltött be, és két frissen feltöltött cikk eltűnt. Vissza tudtam állítani őket, de a tanulság megmaradt.

A kisebb zökkenők később sem tűntek el teljesen — 2026 júniusában például a képfeltöltés állt meg egy napra, a szerkesztő ezt látta: Hiányzó munkakönyvtár. A különbség annyi, hogy ezek már az élő munkát nem sodorták veszélybe.

Ezután készült egy pontos helyi másolat, és a további munka ott folyt. Az éles oldalra innentől csak kész, letesztelt állapot került ki, külön élesítő szkriptekkel — ezekről lentebb részletesen írok.

Mi változott, és mi maradt ugyanaz

A forma nagy része szándékosan maradt: a látogatók megszokták, hol mit találnak, és a keresők is évek alatt építették fel a képüket az oldalról. Az új téma ezért a régi oldal renderelt eredményét vette mintának, nem a régi kódot — képernyőképeket állítottam egymás mellé, és végigmentem az eltéréseken.

A szerkezet viszont változott, a főszerkesztő kérésére. A műfaji rovatok lekerültek a főoldalról, mert nem mindegyikben volt elég friss anyag; a főoldal lapozhatóvá vált; és a partnereknek hirdetési helyek kerültek ki. A műfaj azóta a cikken belül derül ki, nem külön rovatból.

A szerkesztőség szempontja

Az oldalt nem én töltöm fel, hanem a szerkesztőség. Ez azt jelenti, hogy a rendszer akkor jó, ha nem kell hozzá WordPresst tanulni — a szerkesztő cikket ír, képet választ, és a formával nem foglalkozik.

A szerkesztő menüjében ezért négy menüpont van: Bejegyzések, Média, Oldalak és Profil. Minden más eltűnik, beleértve azokat a bővítményeket is, amik a jövőben települnek. Erről lentebb részletesen írok, mert a megoldás nem az, ami elsőre kézenfekvő.

Mit jelent ez, ha hasonló a helyzeted

Ha van egy régóta működő honlapod, ami még megy, de már nehezen módosítható, abból nem feltétlenül következik, hogy mindent újra kell kezdeni. Ennél a magazinnál a forma nagy része megmaradt, és amit megváltoztattunk, azt a szerkesztőség hiányolta — nem egy újratervezés hozta.

Én három dolgot szoktam megnézni ilyenkor: hány ember dolgozik a felületen, mennyi tartalom van benne, és mi történik, ha valaki elront valamit. Ezekből többet lehet tudni a munka méretéről, mint abból, hogy hány éves az oldal.

A költöztetés

A tartalom két külön oldalon volt

A régebbi cikkek és kritikák nem az élő oldalon éltek, hanem egy külön, „régi” előtagú címen, amit évekkel korábban választottak le. A főszerkesztő maga sem tudta pontosan, mi van ott — nem ő szerkesztette annak idején —, és először az is felmerült, hogy elég lenne egy linkkel odamutatni.

Miután megnézte, mégis a beolvasztás mellett döntött, mert a kritikák szerinte fontosabbak, mint a cikkek. Az anyag mennyisége viszont valódi kérdést vetett fel: ennyi írás egyben olvashatatlan, ha csak egy hosszú listaként áll ott. Ezért került a régebbi anyag az archívum-oldal alá, kategóriák szerint csoportosítva, a friss cikkek pedig a főoldalon maradtak.

Cikkek, amiknek nem volt dátumuk

Az oldalnak több változata volt már, és a metaadatok egy részét valamelyik korábbi költöztetés vitte el: 154 cikk úgy érkezett, hogy nem jött vele megjelenési idő. Ezek az importáláskor egy közös helyettesítő dátumot kaptak, ami így minden érintett cikkben ugyanaz — tehát felismerhető, de nyilvánvalóan nem valódi.

Három lehetőség volt: kitalálni egy dátumot, kitenni a helyettesítőt, vagy nem mutatni semmit. Az első kettő valótlan állítás lett volna egy olyan oldalon, ahol a cikk kelte számít. A téma ezért felismeri ezt a dátumot, és ilyenkor sem a cikklistán, sem a cikkben nem jelenít meg dátumot. A cikk teljes értékű marad, csak nem állít semmit arról, mikor jelent meg.

A régi szerkesztő maradványai a szövegben

A régi oldal vizuális szerkesztővel készült, és a cikkek szövegébe beépültek annak a szerkesztőnek a saját elemei. Ezeket a téma a megjelenítéskor takarítja ki, nem az adatbázisban — így az eredeti tartalom érintetlen marad, és egy hibás mintázat nem tesz visszafordíthatatlan kárt.

A takarítás közben tanultam is egyet. Az üres elemeket eltávolító minta először túl mohó volt, és letörölte azokat az üres elemeket is, amiknek háttérkép volt a tartalmuk — vagyis pont a lényegük. Azóta a feltétel pontosabb: csak akkor töröl, ha az elemen nincs semmilyen hasznos tulajdonság.

Az archívum, ami tíz év alatt háromféle névvel gyűlt össze

Az oldalon 148 lapszám PDF-je érhető el, 1996-ig visszamenőleg. A fájlok viszont évek alatt kerültek fel, több ember kezén, és ez látszik is rajtuk: van köztük évszakos név, sorszámos név, és van elgépelt is.

Emiatt a lapszámok sorrendjét nem lehet a fájlnév ábécérendjére bízni. A megjelenítés a névből próbálja kiolvasni az évszakot vagy a lapszámot, és abból rakja helyes sorrendbe az évfolyamot. Ami egyik mintába sem illik, az megtartja az eredeti helyét — a kivétel így nem okoz hibát, csak kevesebb segítséget ad.

A szerkesztői felület lezárása

Miért nem tiltólistával

A kézenfekvő megoldás az, hogy megkeressük a zavaró menüpontokat, és egyenként letiltjuk őket. Ez működik is — a következő bővítmény telepítéséig. Akkor ugyanis megjelenik egy új menüpont, amiről senki nem szólt, és amit senki nem tiltott le.

Ezért itt fordítva működik. A szerkesztő menüjében négy engedélyezett menüpont van, és minden más automatikusan eltűnik, akkor is, ha holnap kerül fel. A szabály a bővítmények menü-regisztrációja után fut le, tehát nem előzi meg semmi.

add_action( 'admin_menu', function() {
    if ( current_user_can( 'manage_options' ) ) return; // adminok teljes menüt kapnak
    global $menu;

    $allow = [
        'edit.php',                 // Bejegyzések
        'upload.php',               // Média
        'edit.php?post_type=page',  // Oldalak
        'profile.php',              // Profil
    ];

    foreach ( $menu as $m ) {
        $slug = $m[2] ?? '';
        if ( $slug !== '' && ! in_array( $slug, $allow, true ) ) {
            remove_menu_page( $slug );
        }
    }
}, 999999 ); // minden plugin menü-regisztrációja UTÁN fut

ezt az utat nem választottuk · az admin továbbra is mindent lát — a szűkítés csak a többi szerepkörre vonatkozik

Amit a menün túl kellett korlátozni

A menü elrejtése önmagában nem elég, mert a felületek közvetlen webcímen is elérhetők maradnak. Ezért a szerkesztő jogosultsága is szűkült: oldalakat nem szerkeszthet, címkéket nem kezelhet, és ha közvetlenül a vezérlőpultra navigál, a bejegyzésekhez kerül át.

Emellett eltűntek a bővítmények értesítései is, és ezt a főszerkesztő kérte. Az automatikus figyelmeztetésekről — tanúsítvány, tárhely, frissítés — azt írta, hogy nem tudja értelmezni őket, viszont nyugtalanítják. Ezek valóban az üzemeltetőnek szólnak, nem annak, aki cikket ír. A hibaüzenetek és a mentés visszajelzései megmaradtak.

A banner, ami kizárta a látogatót

2026 júniusában érkezett egy jelzés, hogy az oldalon bezárhatatlan ablakok ugranak fel. A sütikezelő bannerről volt szó, és a jelenség elsőre értelmetlennek tűnt, mert a banner látszólag rendben volt.

A testreszabott megjelenés a banner kategória-panelját egy olyan CSS-megoldással rejtette el, ami csak akkor csukja össze a panelt, ha a szkript már lefutott és beillesztett egy segédelemet. Ha a szkript bármi miatt nem futott le, a panel teljes magasságban maradt, viszont átlátszóan: nem látszott, de elnyelte a kattintásokat, és ezzel a gombokat is elérhetetlenné tette.

A javítás három elven készült. Az összecsukott állapot ne függjön szkripttől, tehát tisztán CSS-ből is érvényesüljön. A védőréteg szkriptje külön fájlba került, nem a téma fő szkriptjébe, hogy egy ottani hiba ne tudja letiltani. És ha az állapotjelzők valaha ellentmondanának egymásnak, a banner zárva hibázzon, ne nyitva — mert a zárt banner kellemetlen, a nyitott viszont használhatatlanná teszi az oldalt.

/* Csukott kategória-leírás: a skin display:grid-re kényszeríti,
   ezért CSS-ből újra ki kell vágni — szkript nélkül is. */
.cmplz-cookiebanner .cmplz-category:not([open]) > .cmplz-description {
    max-height: 0 !important;
    overflow: hidden !important;
    pointer-events: none !important;
}

Ami nem nyilvánvaló

A következő négy dolog nincs benne a dokumentációkban, ezek használat közben derülnek ki, és mindegyikbe elég könnyű belefutni.

A változó betűtípus böngészőnként máshogy néz ki

A betűtípusokat a Google szolgáltatásáról is be lehetne tölteni, és ott ma már az újabb, változtatható vastagságú változat érkezik. Ez viszont böngészőnként eltérően renderelődik, és az eltérés az egyik böngészőben kifejezetten feltűnő volt.

Ezért a betűtípusok a szerverről érkeznek, rögzített vastagságokban, a fejlécbe ágyazott hivatkozással. Ennek van egy mellékhaszna is: az oldal nem kér le semmit külső szolgáltatótól, ami a sütikezelés szempontjából is egyszerűbb helyzet.

A lusta képbetöltés kikapcsolása is okozhat akadást

A képek késleltetett betöltése látszólag kikapcsolható, ha azt akarjuk, hogy minden kép azonnal ott legyen. Itt viszont ez visszaütött: a párhuzamosan induló képdekódolás túlterhelte a böngésző fő szálát, és a görgetés emiatt akadozni kezdett.

Ezért itt a késleltetett betöltés végül visszakapcsolva maradt. Egy másik oldalon éppen a kikapcsolása segített, ugyanezen a nyáron — ez a kapcsoló nem önmagában jó vagy rossz, hanem attól függ, hány kép áll sorban és mekkorák.

A cikk oldalsávja nem bír fix elemszámot

A cikkek mellé ajánlott írások kerülnek, és ezekből annyi fér ki, amennyit a cikk hossza megenged. Fix számmal vagy üres hely marad egy hosszú cikk mellett, vagy túlcsordul egy rövid mellett.

A megoldás megosztja a munkát: a szerver bőséges készletet ad, a böngésző pedig annyit mutat belőle, amennyi ténylegesen befér. Így egy rövid cikknél tíz ajánló látszik, egy nagyon hosszúnál akár nyolcvan, és egyik esetben sem kell méretet találgatni.

Az élesítés alapértelmezése az legyen, hogy nem történik semmi

A projekthez hat élesítő szkript tartozik: külön a témára, a bővítményre, a feltöltött fájlokra, az adatbázisra, egy összefogó, és egy visszafelé irányuló. Mindegyik dry-run módban indul, tehát alapból csak kilistázza, mit csinálna.

1. Automatikus mentés a célkörnyezet adatbázisáról, időbélyeggel.
2. A célkörnyezet saját beállításainak feljegyzése — licenc, indexelési kapcsoló.
3. Export a forrásból, átvitel, import a célon.
4. Webcím-csere hét menetben, minden kódolási formára.
5. A feljegyzett beállítások visszaírása.
6. Bővítmény-állapotok beállítása a célkörnyezet szabálya szerint.
7. Kereső-indexelés: fejlesztői környezetben tiltva, élesben engedve.
8. Gyorsítótár-ürítés.
9. A régi mentések takarítása.

Az adatbázis átvitele előtt automatikus mentés készül a célkörnyezetről, és az átvitel után visszaíródnak azok a beállítások, amik környezetenként eltérnek. A fájlok átmeneti könyvtárba kerülnek, és csak a végén cserélődnek ki egyetlen mozdulattal, így nincs olyan pillanat, amikor az oldal félig frissült. A webcímek cseréje pedig hét menetben fut, mert az adatbázisban a hivatkozások többféle kódolásban is előfordulnak — a sima csere ezek felét nem találja meg.

$ wp db query "SELECT post_type, COUNT(*) FROM wp_posts GROUP BY post_type"
post          2370
attachment    2967
page            14
$ wp db query "… WHERE post_date = '2010-01-01 00:00:00'"  # helyettesítő dátum
154

Kérdések erről a munkáról

Összefoglaló

Egy 1996 óta megjelenő klasszikus zenei és jazz folyóirat honlapja elavult alapokon futott, és megújítás közben sem állhatott le. Az együttműködés 2025 őszén kezdődött; az első hónapok élő oldalon végzett munkája 2025 decemberében visszaütött — két frissen feltöltött cikk eltűnt, vissza kellett állítani őket —, ezért a teljes újraépítés 2026 áprilisától pontos helyi másolaton folyt. Két külön rendszerből 2370 cikk és 2967 médiafájl került egy helyre, köztük 154 cikk dátum nélkül, amelyeken a téma nem mutat dátumot; az archívum 148 lapszám PDF-jét adja 1996-ig visszamenőleg. Az új, 9360 soros egyedi téma page builder nélkül dolgozik, a szerkesztői menü négy engedélyezett pontra szűkül, és az élesítés hat, alapértelmezésben dry-run szkripten át történik, atomikus cserével. Egy bezárhatatlanná vált cookie-banner javítása után a biztonságos állapot szkript nélkül is érvényesül. Az üzemeltetés havidíjas.

← Minden esettanulmány