Wordpress: a jó, a rossz és a csúf
Új weboldal fejlesztésekor az első igazán nehéz döntés a megfelelő framework vagy tartalomkezelő rendszer kiválasztása. Figyelembe kell venned a fejlesztés és fenntartás költségeit, a projekt igényeit, és nem utolsósorban azt, hogy melyik CMS mire való. Sok projekt már itt elbukik.
Ebben a bejegyzésben összefoglalom, hogy a WordPress miben jó, miben rossz, és hogy egyáltalán, mikor érdemes használni.
A WordPress gyökerei
A WordPress eredetileg egy blogmotor volt, amely azt a célt tűzte ki magának, hogy egy mindenki számára elérhető publikációs platformot hoz létre. Ez sikerült is neki, egyszerűsége miatt komoly népszerűségre tett szert. Az emberek nagyon kompromisszumos, közepes minőségű blogokon publikáltak, de publikáltak.
Később a változó igények hatására erősödő piaci nyomásnak engedve egyre inkább egy univerzális tartalomkezelő rendszerré alakult az évek során. A visszafelé kompatibilitás érdekében a Core csapat fejlesztői nem építették újra a rendszer alapjait, csak a rá épülő házat vitték más irányba. Emiatt számomra a rendszer felépítése a mai napig egy olyan blogmotor benyomását kelti, amelyre megpróbálnak mindent ráerőszakolni – multinacionális céges weboldalaktól a 60 ezer termékes webshopig.
Ma a legelterjedtebb “olcsó” megoldás kisebb-nagyobb céges weboldalakhoz. Aki olcsó weboldalt szeretne, az általában olcsó webfejlesztővel (vagy anélkül) vág bele, tehát leginkább az úgynevezett kókányolósok tudnak érvényesülni. Ez nem jelenti azt, hogy WordPress -re csak rosszul lehet fejleszteni, ugyanakkor kijelenthetjük, hogy a WordPress fejlesztők jelentős része nem képes vagy nem akar minőségi munkát végezni. Ennek köszönhető, hogy szakmai körökben sokan leírják a rendszert.
Szerencsére vannak jó példák is. Mutatok is párat a teljesség igénye nélkül:
Vedd észre, hogy ezek a siteok
- nem húszezer forintba kerültek,
- nem a szomszéd Pistike munkái, illetve
- arra használják a WordPresst, amire való.
Tehát, mielőtt komolyabban belemegyünk a CMS konkrét előnyeibe és hátrányaiba, szögezzük le: Semmi sem fekete-fehér, WordPress segítségével ugyanúgy lehet high-end weboldalt építeni, ahogyan igénytelen, weblapnak csak nagy jóindulattal nevezhető sz@rkupacokat is. Utóbbiakból van több, mert az sokkal könnyebb.
WordPress, a jó
Bővítmények
A platform legnagyobb előnye egyértelműen az, hogy majdnem mindenre van instant megoldás. Ritkán van szükség olyan egyedi fejlesztésekre, amelyek ténylegesen új funkcióval ruházzák fel a rendszert, általában elég csak beépíteni a már feltalált kerekeket a weboldaladba ahelyett, hogy újra fel kellene őket találni. A hivatalos Plugin Directory -n keresztül több tízezer ingyenes bővítmény érhető el, és szerte az interneten találhatsz fizetős bővítményeket elképesztő mennyiségben. Az esetek döntő többségében a fizetős bővítmények sokkal olcsóbbak, mintha Neked kellene nulláról felépíteni az általuk megvalósuló funkciókat.
Sablonok
A bővítményekhez hasonlóan rengeteg ingyenes és fizetős sablon közül választhatsz. Ezeket már nem feltétlenül ajánlom igényes és magas minőségű projektek esetén, de amikor szerényebb költségvetésből kell gazdálkodni, az ilyen sablonok lehetővé teszik, hogy fillérekből elindulj, a maradék pénzedet elköltheted kiváló tartalomra, marketingre és egyebekre. Ha ügyes vagy, később egyedi, minőségi sablonra is lesz kereted. Ez kompromisszumos megoldás, a semminél jobb, és annál is sokkal jobb, ha a kiváló, egyedi fejlesztésű sablonra épülő weboldalad az igénytelen tartalom miatt kerül a süllyesztőbe. Tehát, ha megteheted, fejlessz egyedi sablont, de ha nem fér bele a keretbe, akkor indulj el egy körültekintően kiválasztott, előre elkészített sablonból.
Használhatóság
A WordPress az egyik legegyszerűbben használható tartalomkezelő rendszer. Igaz, vannak jobbak, egy feladatspecifikus admin felülettel nem veheti fel a versenyt, de a méregdrága, teljesen egyedi rendszerektől eltekintve valóban a legjobbak között van. Ha a Microsoft Office programokkal boldogulsz, akkor a WordPress admin felületén is simán fel tudod tölteni a tartalmakat, ki tudsz cserélni egy képet, ki tudsz tenni egy új menüpontot, és az ezekhez hasonló egyszerű, mindennapos feladatokat el tudod végezni.
Közösség
A WordPress közel 70 millió weboldal mögött fut (leírom mégegyszer: 70 millió weboldal!), ilyen számok mellett nem meglepő, hogy népes közösség épült köré.
Könnyen találsz fejlesztőt
Mivel ilyen sokan használják, rengeteg szabadúszó fejlesztő és nagy webügynökség foglalkozik WordPress fejlesztéssel. Ez azt jelenti, hogy kevésbé vagy kiszolgáltatva a fejlesztődnek, mint egy egyedi rendszer vagy egy kevésbé népszerű CMS használata esetén. Azért légy óvatos: ahogy már volt róla szó, nagyon könnyen kifoghatsz egy rossz WP fejlesztőt.
Komoly cég áll mögötte
A WordPress, bár nyílt forráskódú szoftver, meglehetősen komoly háttérrel rendelkezik. A közösséget összefogó és a fejlesztést irányító vállalat az Automattic. Nem kell tehát attól félned, hogy egyik napról a másikra megszűnik a rendszer támogatottsága.
Költséghatékony
A fentiekből következik, hogy a WordPress a legköltséghatékonyabb megoldások egyike. A bővítmények formájában elérhető, olcsó vagy ingyenes instant megoldásoknak köszönhetően a weboldal funkciói jó eséllyel nem igényelnek semmilyen egyedi fejlesztést, és adott esetben akár a sablon fejlesztését is megspórolhatod. Teljesen átlagos hosting körülmények között kiszolgálható, nem igényel semmilyen extrát.
WordPress, a rossz
Sebesség
A WordPress lassú. A leggyakoribb válasz erre az szokott lenni, hogy komolyabb hosting körülmények között sokat lehet javítani a teljesítményén. Ezzel nehéz vitatkozni, de sajnos teljesen irreleváns dolog. Ha a WordPress egy átlagos tárhelyeken lassabb a társainál, értelemszerűen villámgyors tárhelyen is lassabb lesz náluk, ha azokat is ilyenre tesszük fel. A WordPress tényleg nagyon lassú tud lenni már alapból is, nem beszélve arról, amikor jelentős mennyiségű tartalmat kell kiszolgálnia (több tízezer bejegyzés). A page cacheing is csak félmegoldás: túlbonyolított kerülőúton keresztül jutunk el a statikus site generátorokhoz ahelyett, hogy eleve azt használnánk.
Biztonság
Ez egy igen érzékeny téma szakmai körökben, ezért gyorsan leszögezem, hogy a WordPress nem azért kevésbé biztonságos más rendszereknél, mert több rés van a forráskódban, hanem a népszerűsége miatt. Egyedi fejlesztésű vagy kevésbé ismert tartalomkezelő rendszerek ugyanúgy hemzsegnek a sérülékenységektől, de ezek feltárásához sokkal kevesebb érdek fűződik, így akár sosem derülnek ki.
A legtöbb támadást olyan robotok hajtják végre, amelyek kimondottan egy-egy WordPress sérülékenység kihasználására specializálódva, válogatás nélkül próbálják feltörni az útjuk során eléjük kerülő weboldalakat.
Erről külön írok majd egy cikket, amelyben alaposan kivesézem a témát, egyelőre legyen elég annyi, hogy egy jó fejlesztővel és folyamatos, szakértő által végzett karbantartással az támadások 99.99 százaléka kivédhető.
Csomagkezelés hiánya
Egy WordPress plugin vagy sablon fejlesztésekor állandó problémát okoz, ha egy széles körben használt PHP könyvtárat szeretnék használni. Addig nincs gond, amíg csak az én bővítményem tartalmazza a könyvtárat, azonban ha máshol is előfordul, ütközéshez vezet. Különböző lehetőségek közül választhatok.
Megnézem, hátha más plugin már betöltötte a könyvtárat. De mi van, ha eltérő verziót szeretnék használni, vagy ha a másik bővítmény fejlesztője nem volt ilyen körültekintő, és nem ellenőrzi ugyanezt?
Külön névtérbe helyezem a könyvtárat. Ebben az esetben minden egyes frissítéskor újra módosítanom kell a névtereket, ráadásul ha más bővítmény is betölti a saját verzióját, pazarló módon kétszer töltődik be lényegében ugyanaz a kód.
Én és a többi fejlesztő tekinthetnénk a bővítményekre úgy is, mint csomagokra, de ez sem az igazi. A WordPress nem rendelkezik olyan funkcionalitással, amely lehetővé tenné, hogy a bővítmények más bővítményektől függjenek, esetleg – pl. a Composerhez hasonlóan – minimum-maximum verziószámokat határozhassanak meg. Létezik erre megoldás, a TGM Plugin Activation, de ugye ez is egy külső library, amelynek minden egyes bővítményben jelen kellene lennie, ha ilyen módon szeretném megvalósítani a csomagkezelést.
Gyenge minőségű forráskód
A WordPress forráskódja elsőre egy félig megemésztett spagetti benyomását kelti. Sőt, másodjára, harmadjára és sokadjára is. Ennek az oka, hogy a kódbázis egy része még az időszámításunk előtti WordPress verziókból származik, és ahelyett, hogy a 3. vagy 4. főverziónál – akár dobva a kompatibilitást a korábbi verziókkal – újraírták volna az egészet, inkább folyamatosan hozzáírták az aktuális változtatásokat, míg végül az évek során egy hatalmas, átláthatatlan katyvasszá nőtt az egész. Nem lennék a Core fejlesztők helyében, mert a kompatibilitás eldobása beláthatatlan következményekkel járna, az összes bővítményt és sablont is újra kellene írni, a jelenlegi rossz kódminőség és az elavult megközelítés viszont egyre nagyobb hibalehetőséggel, így több problémával jár.
A bővítmények “összeveszhetnek”
Részben a csomagkezelés hiányából, részben pedig a kissé gyenge kódminőségből adódóan előfordul, hogy látszólag minden különösebb ok nélkül bizonyos bővítmények “összeakadnak” más bővítményekkel. A meta_query használata esetén például előfordulhat, hogy a bővítmények felülírják egymás módosítását az aktuális lekérdezésben, így hibákhoz vezet. Ilyen és ehhez hasonló tervezési hibákból eredő problémákkal kell időnként szembenéznünk WordPress alatt.
Frissítéskor gondok lehetnek
Időnként a bővítmények frissítésekor problémákba ütközhetünk. Részben ezt is ráfoghatjuk a fentiekre, a kódminőségre és a csomagkezelés hiányára, de nem kenhetünk mindent az alaprendszerre. Ez a probléma sokszor amatőr fejlesztők hibájából következik be, akik gyakran prémium sablonok szétkókányolásával “fejlesztenek” weboldalakat, így a sablon frissítésekor a változások elvesznek.
Egy professzionális weboldalnál nem engedhetjük meg magunknak azt a luxust, hogy az éles oldalon kockáztassunk, ezért a bővítmények frissítését először staging környezetben kell elvégezni, tesztelni, és ha minden rendben ment, az éles oldalon is rányomhatunk a frissítés gombra.
Egy staging környezet kialakítása megoldható WordPress alatt, de a rendszer felépítése nem szerencsés ilyen szempontból, hivatalos megoldás pedig – tudtommal – nincs rá. Ígéretes kezdeményezések vannak bővítmények formájában.
Muszáj MySQL -t használnod
Bizonyos tartalomkezelő rendszerek több adatbázis driverrel érkeznek, így lehetővé teszik, hogy a projekt igényeihez leginkább passzoló backendet használd. A WordPress nem tartozik közéjük, mindenképpen MySQL -t kell használnod – még ha teljesen felesleges is.
Hard linkek
A rendszer a tartalmakban elhelyezett linkek és képek URL -jét abszolútként tárolja az adatbázisban, ezzel megnehezítve a site költöztetését. A hivatalos megoldás szerint egy SQL search-replace megoldással kell áthidalni a problémát, ami kissé komolytalan – legalábbis a világ legnépszerűbb platformjának viszonylatában.
WordPress: A csúf
A kereső
Bizonyos rendszerek, mint például a Drupal, évekkel ezelőtt is full-extrás keresővel rendelkeztek. A Drupal gyári keresője szavanként indexeli a tartalmakat, még ha nem is olyan robosztus algoritmussal, mint amilyet egy Google használ, de egészen jó eredményeket ad, méghozzá gyorsan. A WordPress azonban egy már-már viccnek is beillő keresővel rendelkezik, amely egy egyszerű MySQL lekérdezéssel oldja meg a dolgot. Minél több tartalmad van, annál lassabban. A megoldás további hátránya, hogy például az “img” szóra keresve kidobja az összes bejegyzést, amelyben van kép. Más HTML tagekkel és shortcodeokkal is előidézhető ez a jelenség.
Nem egy elképesztően nagy hiányosság, de mégis nívótlan a világ legnépszerűbb publikációs platformjához, és nem értem, hogy az elmúlt 10 évben hogyan maradhatott ez így.
Összegzés
A WordPress alapvetően egy jó CMS, egészen addig, ameddig arra használod, amire tervezték.
Jó választás, amikor gyorsan és költséghatékonyan kell felhúzni egy kisebb céges weboldalt vagy blogot, esetleg néhány termékből álló webshopot. Jó választás lehet startup jelleggel akkor is, ha előre tudod, hogy idővel le kell majd cserélni. Ilyen esetben is érdemes szakértőre bízni a site felépítését.
Ne használd nagyobb weboldalaknál és webshopoknál, főleg ha több ezer terméked van, mellettük sok egyéb aloldal, ráadásul mindez több nyelven… Ha nem arra használod, amire való, a WordPress nem csak a Te életedet fogja megnehezíteni az oldal kezelésekor, de a látogatóidét is a félperces lapgenerálásokkal.
