Az utóbbi időszakban gyakran kerülök egészen intim közelségbe a Wordpres-szel.
Itt most nem arra gondolok – mint például ennek a blognak az esetében – hogy felpattintom, rakok rá valami minimálisan dekoratív sablont, felrakok alá pár plugint, és használom arra amire ki van találva: blogolásra.
Az intim közelség alatt azt értem, hogy már komolyabban bele kell nyúlni, akár a sablonokba, akár a bővítményekbe. De van olyan WooCommerce webáruház is amit ki kell rángatni a 💩 tengerből, mert aki elkezdte csinálni nem igazán értett hozzá. Aztán a megrendelők próbálták befejezni a félbehagyott munkát, de mivel nem értettek hozzá ezért a káosz csak nőtt az oldalon.
Eddig sem voltam oda a WordPress-szért, de az utóbbi időben nagyon kezd elegem lenni belőle, és a köré kialakult egészen gusztustalan módon lehúzós iparágból.
Félreértés ne essék: a WordPress jó, ha a fent leírt első szkenárió szerint használod, és nem nézel mélyebben a motorháztető alá. Teljesen jó, ha nem akarod mélyebben megérteni a működését. Hiszen azt el kell ismernem, hogy könnyen, gyorsan lehet benne létrehozni blogot, vagy bemutatkozó oldalt a saját tárhelyeden, amire forgalmat tudsz hozni a keresőből.
Viszont, amikor elkezdesz mélyebben belenézni, és a csinos sablon megoldások mögé kukkantani, bizony kijön, hogy egy-egy akár fizetős bővítmény nem úgy működik, ahogy elvárnád.
Hogy a drága pénzen megvásárolt sablonod hemzseg a hibáktól, amik pedig egy egyszerű Lighthouse mérésből kiderülnének, ráadásul ezek a hibák befolyásolják a SEO teljesítményedet.
Kiderül, hogy csak kínkeservesen tudod optimalizálni az oldaladat. Ha pedig valami nagyon egyedit szeretnél, akkor meg vagy lőve, és így vagy úgy, de szakértőre lesz szükséged.
A hosszúra nyúlt bevezető után kanyarodjunk rá a problémákra.
1. Abszolút URL-ek tárolása
Teljesen érthetetlen módon a WP letárolja a teljes URL-t az adatbázisában, ami külön nyűg tud lenni egy oldal élesítésénél vagy költöztetésénél. Hiába állítod be a felületen az oldal URL-ét, mégis letárolja az adatbázisban egy csomó helyen, ahelyett, hogy abból a beállításból dolgozna.
Képzeld el a szituációt: van egy WP oldalad, amit a saját gépeden http://localhost alatt fejlesztesz. A megrendelő megveszi a domaint amire felrakod a teljes oldalt adatbázissal együtt, és hopp. Nem működik.
Nem nagyon marad más választásod, valamilyen úton-módon le kell cserélned a teljes adatbázisodban az abszolút elérési utakat. Persze vannak erre bővítmények meg megoldások, de én mindig azt mondom, hogy a kevesebb, néha több.
2. Adatbázis struktúra
Bizony elkerekedik az egyszeri programozó szeme, mikor meglátja, hogy egy WordPress alapú oldalnál minden, de tényleg minden néhány táblában van letárolva. A legtöbb dolgot a wp_posts és wp_postmeta nevezetűekben találod. Oldalak, bejegyzések, egyedi mezők, vázlatok, csatolmányok? Mindent ezekben kell keresned.
Komplexebb, jobban struktúrált adatbázis szerkezetről, idegen kulcsokról, kapcsoló táblákról ne is nagyon álmodozzunk. Minden be van hányva pár táblába, JSON-ban vagy plain text-ben és csókolom.
Külön ironikus, hogy az ajánlott adatbázis motor,a MySQL/MariaDB struktúrált adatbázis létrehozását támogatja, de eközben teljesen struktúrálatlanul tárolnak benne adatokat.
3. Forráskód minőség
Ha belenézel a forráskódba elképesztő dolgokat látsz, és nem jó értelemben véve. Olyan megoldások vannak benne, amiktől minden jobb érzésű programozót ha nem is a hányinger, de minimum egy kellemetlen érzés fogja el.
Nevetséges, hogy még egy fejlesztőcsapatán belül sincs egységes szemlélet és megoldás arra, hogy például hogyan kérjék ki egy bejegyzés ID-ját. Van aki $postid változót használ, más $post_id-t. Egy harmadik $postId-t egy negyedik $postID-t.
De van, aki úgy kelt fel, hogy a get_the_ID() függvényt hívja meg ugyanerre. Van aki a global $post változón hívja meg, más függvényparaméterben adja át neki és azon keresztül oldja meg a feladatot.
Rendben, hogy több lehetőségünk is van, de attól, hogy van erre lehetőségünk nem kell mindet felhasználni.
A forráskód rossz minősége, akkor válik teljesen nyilvánvalóvá, amikor gyereksablont csinálsz, és felül akarod írni a függvényeket. A mindenhonnan összemásolt kód nem fog egységes képet alkotni.
Globális változók használata
Szintén ide tartozik, hogy előszeretettel használják a globális változókat, pedig ettől azért aki tud, az próbál szabadulni.
Nem mindig tetten érhető a globális változók negatív hatása, de az egyik sablonunknál kibújt a szög a zsákból.
A lényeg röviden: a global $wp_query változó menetközben valahol megváltozott (lehet egy plugin köpött bele a levesbe) és egyszerűen nem azt adta vissza értéknek, amit vártam.
Kiderült, hogy míg a sablon többi blokkjában jól oldották meg a feladatot és a $wp_query-n hívták meg a metódusokat, addig abban az egy blokkban a globális változó értékét próbálták kiolvasni.
Az említett kódrészlet a beavatkozás előtt, majd utána.
4. functions.php
A legtöbb tutorial úgy kezdődik, hogy ezt és ezt másold be a functions.php fájlba. Ami már alaphangon sem kicsi, néha többszáz sor, de ha sok egyedi dolgot szeretnél használni, akár ezer soros nagyságra is duzzadhat.
Teljesen átláthatatlan katyvasz lesz egy idő után az egész, és akárhogy is igyekszel, nem fogod tudni jól karbantartani a kódot.
Modularitás, kódhordozhatóság? Ugyanmár, errefelé nem szeretik az eféle úrihuncutságokat. Ezeket hagyjuk meg a hanyatló nyugat ópiumának.
Az egész WP egy monolitikus felépítésű szoftver, amik felett már javarészt eljárt az idő.
5. Nincs egységes szemlélet
A 3. pont nem csak a kódbázisra vonatkozik, hanem a mappaszerkezetre is. Három kötelező része van egy sablonnak: index.php, functions.php, styles.css. Az, hogy a többit hogyan oldod meg, milyen mappa-, és fájlszerkezettel teljesen rád van bízva.
A szabadság persze jó is tud lenni, de nem véletlenül vannak keretrendszerek különböző szabályokkal, style guide-k, hogy milyen megoldást érdemes használni. Így most sugalmazások és javaslatok vannak, de igazából mindenki a saját feje után megy.
6. Template keretrendszer hiánya
Szinten a 3. ponttal függ össze, de külön szedtem, hogy ne legyen olyan hatalmas: ha megnézed a forráskódot azt látod, hogy minden, de tényleg minden bele van hányva a PHP fájlokba: inline CSS, inline JS kódok keverednek HTML és PHP kódokkal, menetközbeni SQL lekérdezések majd feldolgozások.
Utoljára ilyet tizen+ éve láttam a PHP-Fusion-ben, de már legalább az is megpróbál túllépni rajta és próbálja behozni a templateket.
Persze van rá lehetőség most is, hogy úgy kezdj egy teljesen új projektet, hogy felpattintod a Twig rendszert behozó Timbert, de nagyon jó lenne, ha alapból natívan is tudná a WP.
7. Mennyiség győzelme a minőség felett
Ezekből következik, hogy mind a sablonok, mind a bővítmények minősége és megvalósítása erősen hullámzó képet fest.
Gyakori, hogy nem figyelnek oda a Lighthouse elemzésre, és olyan hibákat hagynak bennük, amiket könnyűszerrel ki lehetne javítani. Legutóbb egy Insta Feed Story jellegű pluginnál derült ki, hogy a képeken nincs alt tag, amire a Google úgy harap, mint éhes Foxy a lábtörlőre.
Ha ezt javítani szeretnéd magadnak akkor lényegében leforkolod a plugint és megoldod, de onnantól kezdve viszlát frissítések.
Vagy ott van ugye amiről írtam korábban, hogy egyszerűen annyi requesttel bombázta a szervert, hogy a tárhelyszolgáltatóm azt hitte, hogy gyanús tevékenység folyik az oldalon és hogy robot vagyok.
Nincs egy központi minőségellenőrzése sem a sablonoknak, sem a pluginoknak, ami hatalmas probléma, hiszen már csak akkor derül ki, ha egy plugin rossz, amikor használni akarod.
És persze egyfelől vannak nagyon hasznos bővítmények, amik rengeteg terhet levesznek még egy fejlesztő válláról is, gondolok itt például az online fizetés lehetőségről, de eközben van egy csomó másik, ami épp ellenkező hatással bír.
8. Az admin felület őskáosza
Mivel nincs egységes szemlélet, és nincs QA ezért az admin felületen is mindenki oda pakolja a menüpontjait és úgy alakítja ki az egyes felületeket, ahogy az neki tetszik.
Az egyik bepakolja magát a főmenübe, egy másik a Beállítások alatt bújik meg.
Az egyik próbál modernebb, Bootstrap-esebb kialakítást alkalmazni, a másik klasszikusabb WP-sebb kinézettel rendelkezik.
Az említett webáruházon konkrétan problémát jelent még számomra is néha megtalálni, hogy mi és merre található, ami az alábbi képen látható menüt elnézve szerintem nem csoda, és ez csak a főmenü, az almenüket szándékosan nem is nyitottam ki, pedig abból is van pár.
Képzelhetitek, hogy akkor egy átlag ember mennyire elveszhet benne.
9. Lehúzós “programozók”
Ez már nem a WordPress hibája feltétlenül, inkább azoké, akik ebből próbálnak pénzt csinálni.
Itt több problémával is találkoztam már: az egyik fizetős pluginban, ami a képek optimalizálásáért felelne, van egy lazyload funkció, ami késleltve tölti be a képeket. Ez fontos, hiszen ki szeretne több megabájtnyi olyan képet letölteni, ami nincs is a képernyőjén. Igen ám, de az oldalunkon nem működött.
Kiderült, hogy csak img tagekre működik, ha egy div-en style:background-image tulajdonsággal van betöltve a kép, azt nem tudja kezelni. Hozzáteszem: nem ördőngösség megoldani ezt se, tehát nem rakétatudományról van szó.
Másnak is feltűnt ez a hiba, és beírt a fejlesztő csapatnak, akik egy 🙂 kíséretével annyit javasoltak, hogy hát akkor használja azt, amelyik működik. 30$ a plugin, és egy kb. “ha nem tetszik, akkor használj másikat” választ érdemelsz, mint vásárló. Ez egyszerűen felháborító.
Másik kedvencem: a korábban említett webáruház esetén szerettek volna egy reCaptcha-t a megrendelés végére, ha nincs bejelentkezve a felhasználó, akkor legyen ott a Google reCaptcha, és bizonyítsa, hogy nem robot. Gondoltam magamban, hogy “ez csak egy if”… Tévedtem. 29$/év-ért megvásárolható WooCommerce-hez az a bővítmény, ami azt a kb 3 sort berakja a kódba.
Ha ilyen árakon dolgoznék én is, valószínűleg már milliomos programozó lennék.
Itthoni viszonylatban se sokkal jobb a helyzet: találni olyan ajánlatot, hogy 300 000Ft-ért a megrendelő kap egy pár aloldalból álló, reszponzív WordPress oldalt, amit persze nem tud szerkeszteni. Statikusként van hirdetve, lényegében nem adnak a megrendelőnek felhasználót. Ha szerkeszteni is szeretné a tartalmat (aka dinamikus oldalt szeretne), 500 000Ft.
Mondanom se kell, hogy 500 000Ft-ért már webáruház is kapható, sőt egyes szolgáltatók bérbe adnak ilyet.
Szerencsére nem mindenki ilyen, de azért a pár százezer forintért elkészített, Elementorban összekattintgatott WordPress alapú oldalnál is kinyílt a bicska a zsebemben. Semmi garancia nincs rá, ugyanis hogy SEO-ban jól fog teljesíteni, optimalizáltságról meg ne is nagyon beszéljünk szerintem.
Szépen fog kinézni, sőt biztos vagyok benne, hogy gusztusosabb lesz az egész, mint amit én összerakok, de probléma esetén baromi macerás a javításuk, és a szakember megint rengeteg pénzt elkérhet a feladatokért.
10. Ami mindenre jó, az valójában semmire se
Szintén a programozók hibája, hogy a WordPress az lett, ami. Eleinte egy ingyenes, blogolásra szánt platform volt, és sose terveztek vele úgy, hogy hatalmas, akár többezer terméket kezelni tudó e-commerce oldalak kiszolgáló rendszere legyen.
Attól, hogy ismert programozási nyelveket használ (PHP, Javascript, CSS, HTML) még nem jelenti azt, hogy ebben mindent meg kell és meg lehet csinálni. Vannak erre sokkal jobb megoldások.
Ráadásul a legszomorúbb az egészben, hogy sokan tényleg ezt tekintik webprogramozásnak, és a WP-ben látott mintázatokat fogják követni, azt gondolják, hogy ezek a jó megoldások, holott ezek már réges-régen elavultak.
Értem én, hogy egyszerűbb mindenféle kötöttségek nélkül programozni, csakhát ez egy idő után lényegében szakmunkás szintű tömeges weboldal gyártásba fullad, amiből ugyan van pénz, de szakmailag a programozó lenullázódik eközben.
Mindenesetre a WP megállíthatatlanul tör előre, és egyes előrejelzések szerint ~2 éven belül a világ weboldalainak 50%-át is adhatják a különböző WP alapú oldalak.