A klinika ma már maga szerkeszti az oldalát
Egy budapesti magánklinika honlapja: 22 szakterület, száznál több szolgáltatás árral, húsz munkatárs. A munka lényegét a szerkeszthetőségben kerestem.
- A helyzet
- Klinikát vezetsz, és az oldaladon minden apró módosításhoz fejlesztő kell — egy ár, egy rendelési idő, egy új orvos. A tartalom pedig sok: szakterületek, szolgáltatások, árak, időpontok.
- A megoldás
- Táblázatos szerkesztő-lapok a WordPress adminba, kétirányú szinkronnal a publikus oldalakra; időpontfoglalás négy szinten bekötve; a vezetőnek saját, letisztult felület.
- Az eredmény
- A tartalmat a klinika maga gondozza — árat, időpontot, hírt, képet —, fejlesztő nélkül. Az együttműködés havidíjas karbantartással fut tovább.
A munka számokban
| Az együttműködés kezdete | 2024 — a korábbi honlap átültetésével |
|---|---|
| Az új honlap | 2026, a klinika grafikusának tervei alapján |
| Szakterület | 22, húsznál több egyedi aloldallal |
| Szolgáltatás árral | 104 élő tétel |
| Munkatárs az oldalon | 20 — orvosok, asszisztensek, recepció |
| Szerkesztő-lap az adminban | 8 — áraktól a galériáig |
| Foglalás-bekötés | 4 szinten |
| Üzemeltetés | havidíjas karbantartás |
- Projekt
- magán-egészségügyi rendelő
- Szerep
- Honlap-átültetés és -újraépítés, szerkesztőségi rendszer, foglalás-integráció, üzemeltetés
- Együttműködés
- Havidíjas karbantartás
- Szerkesztő-lap táblázat az adminban soronkénti mentés, jelzés
- Árlista-oldal az ár a saját sorában frissül
- Szakterület-aloldal a vizsgálat-lista és az ársávok
- Orvos-oldal rendelési idő, foglalógomb
- Kapcsolat-oldali időtáblázat naponkénti bontás, magától épül
mentés · az oldalszerkesztőhöz a szerkesztés során senki nem nyúl
A tartalom volt sok, nem a látvány kevés
Ez az én döntésem volt, nem kérés: a napi apróságokat — egy ár, egy rendelési idő, egy új orvos — sokkal olcsóbb ott intézni, ahol keletkeznek. A klinika gyorsabban változtat, én pedig nem apró módosításokkal töltöm a karbantartási időt. A klinikával 2024 óta dolgozom együtt: a korábbi honlapját én ültettem át WordPressre, és utána két évig gondoztam. A klinika a kezdetektől maga akarta szerkeszteni a tartalmat, és tartottam hozzá képernyőmegosztásos bemutatót is. Az oldalszerkesztő viszont nem erre a munkára való: benne egy ár nem adat, hanem egy doboz az oldal szerkezetében — az átírásához a felépítésbe kell belenyúlni. A napi módosítások így két éven át visszakerültek hozzám.
Az új honlapot 2026 elején építettem fel, a klinika grafikusának tervei alapján. Onnantól a kérdés nem a látvány volt, hanem hogy 22 szakterület, száznál több áras szolgáltatás és húsz munkatárs tartalmát ki fogja gondozni — és a válasz a klinika maga lett.
Táblázat, nem oldalszerkesztő
Az adminba nyolc táblázatos szerkesztő-lap épült: árak, rendelési időpontok, szakterületek, kollégák, karrier-pozíciók, hírek, vélemények, galéria. Sorok és oszlopok, mint egy táblázatkezelőben — szűrőkkel, rendezéssel, soronkénti módosítás-jelzéssel és csoportos mentéssel.
A lényeg a mentés utáni rész: amit a vezető átír, az magától frissül minden publikus megjelenésén. Az ár az árlistán és a szakterület-aloldalon, a rendelési idő az orvos oldalán és a kapcsolat-oldali táblázatban. Az átadás utáni első hétvégén, késő este jött a jelzés, hogy a klinika elkezdte az adminban szerkeszteni az oldalt, és aznap este feltöltötte a szakterületek képeit.
Ugyanezekben az esti levelekben kérdés is jött — például hogy a szakterület-leírásokat hol lehet átírni. Hogy a felületről mi hiányzik még, azt ezekből a kérdésekből tudtam meg.
Foglalás négy szinten
A foglalórendszer kiválasztása is a közös munka része volt: a vezető előbb Google Naptárral kísérletezett, aztán egy egyedi fejlesztés lehetőségét mértük fel, végül a klinika által korábbról ismert Medio mellett döntött.
Az időpontokat azóta a Medio kezeli, a honlap pedig négy szinten kapcsolódik hozzá: szakterület-, orvos- és szolgáltatás-szintű linkekkel, meg beágyazott foglalófelülettel. A gombok maguktól a jó helyre visznek — és ahol nincs link, ott a gomb meg sem jelenik.
Mit jelent ez, ha hasonló a helyzeted
Ha rendelőt vagy klinikát viszel, a honlapod legdrágább része nem az építés, hanem az elavulás: a tavalyi ár, a már nem dolgozó orvos, a rossz rendelési idő. Ennél a klinikánál a válasz az lett, hogy a szerkesztés került közel a vezetőhöz, nem a vezető a technikához.
A fejlesztő ettől nem tűnik el — az egyedi aloldalak, az integrációk és az üzemeltetés nálam maradtak, havidíjas keretben. Ami átkerült, az a napi tartalom: az, aminek a klinikánál van a helye.
Ha egészségügyi vagy más, sok-tartalmú szolgáltatást viszel, és az oldalad minden módosítása fejlesztőre vár, írj pár mondatot arról, mi változik nálatok a leggyakrabban. Egy levélváltásból általában kiderül, mennyit adna egy saját szerkesztő-felület.
kristof@kristofkarner.comInnentől a részletek: a szerkesztő-lapok felépítése, a vezető saját adminja, az ármigráció rollback-védelme, egy éles incidens és a helyreállítása, meg a költöztetés álcázott hibaüzenetei.
A megvalósítás mérete
| Saját modulok | 78 fájl, 19 586 sor |
|---|---|
| Ármigráció | 91 tétel bejegyzéssé, 95 archívba — rollback-pillanatképpel |
| Egyedi szakterület-aloldal | 20+, a megrendelő tervei alapján |
| Környezetek | local → dev → éles, WP-CLI-vel |
$ ls mu-plugins/mfk-*.php | wc -l ; wc -l mu-plugins/mfk-*.php | tail -1
78
19586 total
A szerkesztő-lapok
Amitől egy táblázat szerkesztőségi eszköz lesz
A nyolc lap közös alapon áll: rögzített fejléc görgetésnél, kombinálható szűrők, rendezhető oszlopok, hosszú szövegekhez felugró szerkesztő. A módosított sorok jelzést kapnak, amíg nincsenek mentve, a mentés csoportos, az eredményről pedig rövid visszajelzés jön — zöld vagy piros.
A sorrend is a lapokon dől el: a szolgáltatások szakterületenként húzd-és-ejtsd módon sorrendezhetők, és ez a sorrend jelenik meg az árlistán meg az aloldalakon. A kapcsolatok kétirányúak — ha egy kollégához szolgáltatást rendelsz, a szolgáltatás oldalán is megjelenik a kolléga.
A vezető saját adminja
A vezető nem a teljes WordPress-adminba lép be, hanem egy arra szabott változatba. Saját szerepkört kapott, szűk jogosultsággal: tartalmat szerkeszthet, de beállításokhoz, bővítményekhez, frissítésekhez nem fér hozzá. A bal oldali menü el van rejtve, minden a felső sávban van: a nyolc lap füle, meg egy „Weboldal frissítése” gomb, ami érthető nyelven üríti a gyorsítótárat.
/** A szerkesztő-lapok: slug => cím — az admin-sáv fülekhez + a whitelisthez. */
function mfk_editor_sheets() {
return [
'mfk-rendelesek' => 'Árak',
'mfk-rendelesi-idok' => 'Rendelési időpontok',
'mfk-szakteruletek' => 'Szakterületek',
'mfk-orvosok' => 'Kollégák',
// … karrier, hírek, vélemények, galéria
];
}
/** Scope guard: az egyszerűsítés CSAK a szerkesztő-szerepkörre érvényes. */
function mfk_editor_is() {
if ( ! is_user_logged_in() ) return false;
$u = wp_get_current_user();
return $u && in_array( MFK_EDITOR_ROLE, (array) $u->roles, true );
}Ha a vezető bármilyen más admin-oldalra tévedne — akár közvetlen webcímen —, a rendszer visszairányítja a szerkesztő-lapokra. És van egy hibabejelentő gomb is: egy üzenetmező, ami emailt küld nekem. A támogatási út egy kattintás, nem egy elveszett telefonszám.
A szakterületi aloldalak
Az oldal fő arculata a klinika grafikusától érkezett, Figma-tervekben. A szakterület-aloldalak terve viszont magától a vezetőtől jött: AI-val készített látványterveket, és a legjobban sikerültet jelölte ki alapnak — „a dietetika lett a legjobb, annak kéne az alapnak lenni”. Az lett a közös váz; az eltérések szakterületenként épültek rá.
A kérések szakaszonként érkeztek, levélben. Volt vasárnap, amikor kilenc szakterület módosításai kilenc külön levélben jöttek meg — az utolsó összefoglaló már hétfő hajnalban. Tünetlista ikonokkal, lépésekre bontott folyamat, lenyíló szolgáltatás-leírások, dinamikus ártábla: ami közös, az a sablonból jön; amiben eltérnek, azt ezek a levelek döntötték el.
Az ármigráció, rollback-védelemmel
Az árlista eredetileg kézzel épített oldalszerkesztős szerkezet volt — 116 sor, egyetlen konténerben. Ahhoz, hogy a lapokról szerkeszthető legyen, minden tételnek bejegyzéssé kellett válnia: 91 tétel vált szolgáltatás-bejegyzéssé, 95 elárvult régi tétel pedig archívba került — nem törlődött.
- Pillanatkép minden érintett bejegyzésről a migráció előtt.
- Minden adatbázis-művelet naplózva, visszajátszható formában.
- A tételek átvezetése szakaszokban, ellenőrzéssel szakaszonként.
- Az árvák archívba, nem kukába — a régi adat maradjon előhívható.
- Helyreállító szkript, ami a pillanatképből bármikor visszaállít.
A helyreállítóra végül nem volt szükség. De nem ez a lényeg — hanem hogy a migráció alatt végig volt visszaút.
Az incidens, amit a saját folyamatom okozott
2026 júniusában, egy fejlesztői másolat készítése közben az éles oldalon lecsatolódott a szolgáltatásokat a szakterületekhez kötő mező. A tünetet az ügyfél vette észre: az árlistán minden tétel az „Egyéb díjak” alá csúszott. A legvalószínűbb ok egy rövid ablak volt, amíg a másolat beállítása még az éles adatbázisra mutatott.
A helyreállítás sebészi volt. A fejlesztői másolat őrizte az ép kapcsolatokat, de más mezői már elavultak voltak — a vak visszaírás kárt okozott volna. Ezért mentés után kizárólag ez az egy mező állt vissza, kereszt-adatbázis művelettel, és az eredmény ellenőrizve: nulláról százegy kapcsolat tért vissza, minden más érintetlen maradt.
Ezt az esetet nem hallgatom el, mert két dolgot megmutat. Egy: éles és fejlesztői környezet között a másolás pillanata is kockázat. Kettő: a helyreállítás értéke nem a gyorsaságban van, hanem a hatókör fegyelmében — csak azt visszaírni, ami bizonyítottan elveszett.
A fejlesztői másolat itt egy incidens forrása lett; máshol éppen ez a felállás mentett meg mindent, amikor egy kész oldal végül nem ment élesre — ugyanaz az eszköz, két kimenetellel.
Ami nem nyilvánvaló
A következő négy dolog a költöztetésnél derült ki, és mindegyik álcázta magát valami másnak.
A „időtúllépés”, ami betelt tárhely volt
Az ügyfél böngészős feltöltése rendre elakadt, és mindenki időtúllépésre gyanakodott. A valódi ok: az éles tárhelyen 784 kilobájt szabad hely maradt — a kvóta betelt. Takarítás után a feltöltés magától működött. Azóta a kvóta az első, amit költöztetés előtt megnézek.
A „sérült archívum”, ami verzió-eltérés volt
A visszatöltés „corrupted archive” üzenettel állt le — az archívum pedig ép volt. A helyi gépen újabb migrációs bővítmény készítette a csomagot, mint ami élesben kibontotta volna. A bővítmény frissítése után a visszatöltés változtatás nélkül lefutott.
A „régi oldal”, ami egy leállított gyorsítótár volt
A sikeres költöztetés után az éles oldal helyenként a régi megjelenést mutatta. Az ok egy rég leállított gyorsítótár-bővítmény hátrahagyott fájljai voltak, amik tovább szolgálták a 2025-ös oldalakat. A cache-mappa ürítése után a friss tartalom jött mindenhol.
A jelszavak, amik a titkosítási kulccsal együtt járnak
A költöztetés után a levélküldés hitelesítése tört el. A tárolt jelszavakat a WordPress a telepítés saját kulcsaival titkosítja — a költöztetés a tartalmat viszi, a kulcsok viszont az éles oldalé maradnak, így a titkosított jelszó ott olvashatatlan. A megoldás nem trükk: a jelszavakat élesben újra meg kell adni.
Kérdések erről a munkáról
Hogyan tudja egy klinika saját maga szerkeszteni a honlapját?
Úgy, ha a szerkesztés nem az oldalszerkesztőben történik, hanem egy arra épített felületen. Ennél a klinikánál táblázatos szerkesztő-lapok készültek a WordPress adminba — árak, rendelési időpontok, szakterületek, kollégák, hírek, vélemények —, soronkénti szerkesztéssel, csoportos mentéssel és módosítás-jelzéssel. Amit a vezető ott átír, az magától frissül a publikus oldalakon: az ár az árlistán és az aloldalakon, a rendelési idő az orvos oldalán és a kapcsolat-oldali táblázatban. Az oldalszerkesztőhöz hozzá sem kell nyúlnia.
Hogyan lehet időpontfoglalást beépíteni egy orvosi rendelő honlapjába?
Ennél a klinikánál a Medio foglalási rendszer adja az időpontokat, és a honlap négy szinten kapcsolódik hozzá: szakterület-szintű link, orvos-szintű link, szolgáltatás-szintű link, és beágyazott foglalófelület. A linkeket mezőként tárolja a rendszer, így a foglalógombok maguktól a jó helyre visznek — és ha egy szolgáltatásnak nincs saját linkje, a gomb el sem jelenik meg. A linkek karbantartása ugyanabban a táblázatos adminban történik, ahol minden más.
Mi kell ahhoz, hogy egy nem műszaki vezető biztonságban dolgozzon a WordPress adminban?
Saját szerepkör, szűk jogosultsággal, és egy felület, ami csak azt mutatja, ami rá tartozik. Itt a vezető külön szerepkört kapott: tartalmat szerkeszthet, de beállításokhoz, bővítményekhez, frissítésekhez nincs jogosultsága. A bal oldali admin-menü el van rejtve, minden a felső sávban van: a szerkesztő-lapok fülei és egy „Weboldal frissítése” gomb, ami érthető nyelven üríti a gyorsítótárat. Ha bármi másra tévedne, a rendszer visszairányítja a szerkesztő-lapokra.
Hogyan lehet biztonságosan migrálni százas nagyságrendű árlistatételt?
Rollback-védelemmel: a migráció előtt pillanatkép készül minden érintett bejegyzésről, és minden adatbázis-művelet naplózódik, hogy az egész visszajátszható legyen. Ennél a klinikánál 91 árlistatétel vált bejegyzéssé így, 95 elárvult régi tétel pedig archívba került — nem törlődött. A helyreállító szkript a pillanatképből és a naplóból bármikor vissza tudta volna állítani az eredeti állapotot. Nem kellett — de nem ez a lényeg.
Mi történik, ha egy éles oldalon adatkapcsolatok vesznek el?
Az történt: egy fejlesztői másolat készítése közben az éles oldalon lecsatolódott a szolgáltatásokat a szakterületekhez kötő mező — az árlista minden tétele az „Egyéb díjak” alá csúszott. A helyreállítás sebészi volt: mentés után kizárólag ez az egy mező állt vissza a fejlesztői másolat ép adataiból, mert más mezők ott már elavultak voltak, és a vak visszaírás kárt okozott volna. Az eredmény ellenőrizve: nulláról százegy kapcsolat tért vissza, és semmi más nem változott.
Miért mondhat egy migráció „sérült archívumot”, amikor nem sérült?
Mert a hibaüzenet nem mindig az okról szól. Ennél a költöztetésnél a „corrupted archive” üzenet mögött verzió-eltérés állt: a helyi gépen újabb migrációs bővítmény készítette a csomagot, mint ami az éles oldalon ki akarta bontani. A bővítmény frissítése után a visszatöltés lefutott. Előtte egy másik álca is volt: a feltöltés nem időtúllépés miatt akadt el, hanem mert az éles tárhelyen 784 kilobájt szabad hely maradt — a kvóta betelt.
Megéri-e egyedi aloldalt építeni minden szakterületnek?
Ott éri meg, ahol a szakterületek valóban különböznek. Ennél a klinikánál húsznál több szakterület kapott egyedi aloldalt — tünetlistát ikonokkal, lépésekre bontott folyamatot, lenyíló szolgáltatás-leírásokat, dinamikus ártáblát —, mert egy bőrgyógyászat és egy labordiagnosztika nem ugyanazt a szerkezetet kívánja. A közös alap sablonból jön, az eltérés pedig szakterületenként épült, az ügyfél kéréseit követve.
Összefoglaló
Egy budapesti magán-egészségügyi rendelővel az együttműködés 2024-ben indult a korábbi honlap WordPressre átültetésével; az új, a klinika grafikusának Figma-tervei alapján épült honlap 2026 elején állt fel. Mögé szerkesztőségi rendszer épült: nyolc táblázatos szerkesztő-lap a WordPress adminban — árak, rendelési időpontok, szakterületek, kollégák, karrier, hírek, vélemények, galéria — soronkénti módosítás-jelzéssel, csoportos mentéssel és kétirányú szinkronnal a publikus oldalakra. Az időpontfoglalást a Medio rendszer adja, négy szinten bekötve; a klinika vezetője saját szerepkört és letisztult, brandelt admin-felületet kapott, egyetlen érthető gyorsítótár-ürítő gombbal és beépített hibabejelentővel. A 91 tételes ármigráció rollback-pillanatképpel és művelet-naplóval futott; egy éles incidens — a fejlesztői másolat készítése közben lecsatolódott szakterület-kapcsolatok — mentés utáni, egyetlen mezőre szorított kereszt-adatbázis visszaállítással rendeződött. A megvalósítás 78 saját modul, 19 586 sor; húsznál több szakterület kapott egyedi aloldalt, a megrendelő AI-val készített látványtervei alapján. Az üzemeltetés havidíjas, a napi tartalmat a klinika maga gondozza.