Miért építettem újra egy működő weboldalt?
A helyzet egyszerű volt: technikai szempontból minden rendben volt az oldallal, de amint beléptem a WordPress adminba, elment a kedvem bármihez nyúlni.
Az oldal jól teljesített a keresőkben, felhasználóbarát volt, de a backend – itt a WordPress admin felületére gondolok – maga volt a katasztrófa. A mondás úgy tartja, hogy a suszter cipője mindig lyukas. Az én esetemben sem volt ez másként.
A probléma? 36 aktív plugin, átláthatatlan kódbázis, és egy olyan admin felület, ahol már féltem hozzányúlni bármihez, nehogy leszakadjon az egész.
Az ötlet: Teljes újjáépítés
Szerettem volna több cikket írni az oldalra, rendszeresen friss tartalmakat készíteni, és egyáltalán többet jelen lenni. De amint beléptem az adminra, elment a kedvem.
Tagja vagyok néhány WordPress közösségnek, ahol sokan azzal villognak, hogy milyen minimális pluginszámmal oldották meg egy-egy oldal létrehozását. És bár tudom, hogy az ügyfél szempontjából ez lényegtelen (az ügyfél azt nézi, hogy működjön, nem azt, hogy hány pluginnal), a saját munkafolyamatom szempontjából óriási különbség.
Ezért döntöttem úgy: Kitakarítom az oldalt. Tiszta lappal indulok.
A plugin dzsungel problémája
36 aktív plugin volt az oldalon. Ez számomra tarthatatlan volt.
Mi történt? Mivel általában az embernek a saját dolgaira nincs ideje, sokszor én is „on the fly” oldottam meg a dolgokat. Ennek eredménye az lett, hogy amit egy kis időráfordítással custom kóddal meg lehetett volna csinálni, arra bedobtam egy plugint.
Kettős mérce
Természetesen az ügyfeleknél nem így járok el – ők fizetnek érte, minden projektet alaposan megtervezek. De a saját oldalam elkészítéséért nem fizet senki.
A probléma viszont az, hogy ez az oldal az, amit először látnak. Ha ez rossz, akkor már nem is szavaznak bizalmat.
Ezért kényszerítettem magam, hogy minden apróságon végigmenjek és kitakarítsam az oldalt alaposan.
A megfelelő stack kiválasztása
A végeredmény? 36 pluginről 21-re csökkentettem a számot – és a jövőben ezt tovább akarom mérsékelni.
Mit tartottam meg?
Csak azokat a pluginokat, amelyek:
- Valódi funkcionalitást adnak (nem pótolhatók egyszerű kóddal)
- Aktívan fejlesztettek és támogatottak
- Teljesítmény szempontból optimalizáltak
Mi maradt?
Ebből a 21-ből például 6 olyan, aminek van egy free és egy pro verziója. A free verzió kell a pro működéséhez – sakk matt. De a lényeg, hogy amit tudok, azt még likvidálom.
Kód takarítás: BEM-től Utility osztályokig
Többször is nekifutottam a „hogyan”-nak – a célom az volt, hogy a kód is annyira tiszta legyen, amennyire csak lehet.
CSS keretrendszer váltás: Automatic CSS → Core Framework
Korábban minden projekten Automatic CSS-t használtam. Most viszont a Core Framework-re váltottam. Miért?
- Szerettem volna elmélyedni benne – tudatosan gyakorolni
- Egyszerűbb beállítani a fontos dolgokat
- „Könnyebbnek” tűnik – tisztább struktúra
BEM naming konvenció
Követtem a fejlesztés során a BEM naming konvenciót (getbem.com/naming), ami nagyon bevált az első két oldalnál.
De a harmadik oldal után rájöttem: rengeteg ismétlődő elem lesz az oldalon, mert kicsit sales-esebbre akartam a szövegezést – sok visszatérő formula, ugyanazok a layoutok, ugyanazok a szakaszok.
Utility Class szemléletmód
Ezért váltottam: elkezdtem Utility osztályokban gondolkodni (Tailwind CSS filozófia).
Miért jó ez?
A Core Framework megadja az alap beállításokat:
- Spacing (távolságok)
- Padding, margin
- Font-size (betűméretek)
- Colors (színek)
- stb.
De az én visszatérő elemeimhez nem kellenek külön osztályok minden oldalon.
Template Bundle megközelítés
Csináltam egy template bundlet, ami gyakorlatilag azt jelenti:
- Egy oldalon létrehoztam minden layoutot (elrendezést), ami kell a teljes weboldalon
- Class szinten beállítottam mindent – színek, méretek, spacingek
- Ez adta azt a készletet, amivel a teljes oldalt „összelegóztam”
A globális Utility class-oknak köszönhetően ezután már ha valamit módosítani akartam, azt csak 1 helyen, class szinten írtam át – és voilà, kész is volt a varázslat.
Eredmény: 107 Utility class
Ugyan minden oldalt ezzel a szemlélettel építek, de itt a cél az volt, hogy minimalizáljam az összes CSS osztályt és ezáltal a kódbázis méretét is.
A végére 107 Utility class-om lett, amivel lefedtem az egész oldalt.
A munka végeztével pedig simán lekérdeztem és töröltem az unused (nem használt) CSS osztályokat – így még tisztább lett a kód.
Custom Post Type-ok rendrakása
Természetesen az én oldalamon is használok custom post type-okat:
- Referenciák
- Partnerek
- Információs oldalak
- Fogalomtár
Ezeket is rendbe raktam. Csak az maradt, ami tényleg kell.
Adatbázis optimalizálás – A nem látható munka
Mivel ez egy közel 6 éves oldal (egyébként 2016-os, csak volt, hogy teljesen újrahúztam), sok bővítmény, beállítás, téma, kód, cache file meg minden egyéb jött és ment.
Ezért az adatbázis eléggé „telített” volt.
Manuális takarítás
Sok esetben a takarítás egy-egy bővítménnyel megoldható, de vannak esetek, amikor az adat úgy beeszi magát az adatbázisba, hogy manuálisan kell onnan kitakarítani.
Na, ez a munka még most is folyik.
Gondolok itt olyanra, hogy:
- A Website Auditor talált még CDN broken linkeket, amelyek valami régi cache-lésből maradtak vissza
- Ezeket manuálisan kellett kibányásznom és takarítanom
- Rengeteg bővítmény hoz létre mappákat kénye-kedve szerint – ezeket is fel kellett derítenem és kiiktatnom
A munka még most is zajlik. Aprólékos, de szükséges.
Az emoji-k esete – SVG konverzió
Gyűlölöm az emoji-kat. Vagy legalábbis gyűlöltem, amíg meg nem értettem a szerepüket.
Sokan ismerik, szeretik és használják. A weboldal (technikai szempontból) viszont nem szereti.
Miért akartam mégis használni őket?
Mert az emberek ismerik és azonnal felismerik – ha feljönnek az oldalra, akkor az emoji-k miatt már egyből egy ismerős látvány fogadja őket, ami jó bizalmi alap lehet.
A technikai probléma
Igen ám, de az összeset SVG-ként kell feltölteni, mert különben:
- Lehet, hogy tiltva lesznek
- Egyes nyelvi bővítmények nem szeretik őket fordítani
- Hiába írod be a megfelelő HTML entity-vel (W3Schools emoji referencia)
Szóval egyesével mindegyikből kellett egy SVG verziót feltölteni az oldalra.
A pipák ✓, X-ek ✗, kérdőjelek ❓ még nincsenek mindenhol cserélve… Jó kis munka.
Nyelvesítés: Polylang → Web-T
Itt kanyarodnék rá a nyelvesítés témakörére.
Ugyan elsősorban magyar piacra dolgozom, de szeretnék nagyobbat nyitni a külföldi piac felé is. Éppen ezért – ahogy korábban is – most is fontosnak gondoltam, hogy angol nyelven is elérhető legyen az oldal.
Miért váltottam a Polylang-ről?
Korábban a Polylang bővítménnyel oldottam ezt meg, de azért nem szeretem a „klasszikus” nyelvi bővítményeket, mert duplikátumok keletkeznek.
Optimális esetben mindenből kettő kell egy magyar-angol nyelvű oldal esetén:
- 2 oldal
- 2 kép
- 2 template
- 2 form
- 2 minden
Baromi melós. Ha meg is csinálod szépen, akkor még le kell fordítani a tartalmakat. Baromi unalmas és időigényes.
Megéri?
Ki tudja. Ha hirtelen bejönne két külföldi megrendelés, ami nem a magyar piaci trendek szerint fizet, akkor talán. De így nem.
SEO szempontból? A magyar piac így is telített, a külföldi pedig burjánzik. Tehát a SEO-t ebből a szempontból el is engedtem.
Inkább arra koncentrálok, hogy ha kapcsolat útján bejön egy külföldi érdeklődő, az meg tudja nézni, mivel és hogyan foglalkozom.
Web-T: Az Európai Unió megoldása
Ezt azért is írtam le így, mert az Európai Unió által fejlesztett Web-T nevű bővítményt használom az oldalon a Polylang helyett.
Mit csinál?
- Automatikusan lefordítja az oldalt
- Ráadásul a metaadatokat is lefordítja
Mit NEM fordít?
- URL-ek
- Árak
- Emoji-k
De nem is olyan rosszul csinálja. Arra elég, hogy megértessem magam egy érdeklődővel – szóban úgy is jobb vagyok.
Éppen ezért és mert kevés időm volt, az auto translate-et használtam, ami rengeteg időt spórolt.
Még vannak apróságok az oldalon (pár emoji és forintos ár, form), amit meg kell oldanom, de a megoldás megvan rá. Most egyelőre jó lesz így.
Tanulságok és következő lépések
Összességében kemény menet volt, de most már van kedvem csinálni.
Mit tanultam?
- A saját projektet is komolyan kell venni – ha az ügyfeleknél rendesen csinálod, miért ne tennéd meg magadnak is?
- Kevesebb plugin = tisztább kód – nem kell minden funkcióhoz új bővítmény
- Utility classes rugalmasságot adnak – gyorsabb fejlesztés, könnyebb karbantartás
- Adatbázis tisztítás rendszeres feladat – ne hagyd elburjánzani
- Automatizálás (pl. auto translate) időt spórol – használd okosan
Mi a következő?
Valószínű, hogy a jövőben további részletekkel érkezem majd a projekttel kapcsolatban:
- Teljesítmény mérések (előtte/utána)
- Plugin lista részletesen
- Core Framework beállítások
- Template bundle részletes bemutatása
Én nagyon élveztem, még ha olykor nehéz is volt.
Kérdésed van a WordPress oldal optimalizálással kapcsolatban? Hasonló helyzetben vagy te is? Írj nekem!
Technikai összefoglaló:
Eredmények:
- ✅ 36 → 21 plugin
- ✅ Tisztább kódbázis (107 Utility class)
- ✅ Gyorsabb admin felület
- ✅ Könnyebb karbantarthatóság
- ✅ Többnyelvű (magyar/angol) automatikus fordítással
Felhasznált technológiák:
- Core Framework (CSS keretrendszer)
- BEM naming → Utility osztályok
- Web-T (többnyelvűsítés)
- Custom Post Types
- Template Bundle megközelítés
