Miért az egyedi fejlesztéseket preferálom elsősorban?

Attól függetlenül hogy foglalkozom Wordpressel és más rendszerekkel is, mégis az egyedi fejlesztésre hajlok inkább. Miért van ez?    

A Wordpress weboldal (továbbiakban csak WP) készítő és az egyedi fejlesztéssekkel foglalkozó fejlesztő is az egyszerűségre törekszik.     
Amit sokan nem vesznek észre ezen a területen, hogy mind a két típus mást ért az egyszerűség alatt!

A WP oldalakat létrehozó emberek magát a létrehozás folyamatát élik meg egyszerűbbnek és könnyedebbnek. Wordpress oldalaknál kapunk egy általános megoldásként egy “klikkelgetős” felületet amivel összeállíthatunk egy weboldalt.    
Az egyedi fejlesztéssel foglalkozó emberek az egyszerűséget a programkód és megoldások szintjén fogalmazzák meg legtöbbször. A létrehozás itt sem feltétlenül bonyolultabb. Ilyenkor nem egy “klikkelős” felületen hozzuk létre a weboldalt, hanem programkódokat gépelünk be. Gyakorlatilag mi ilyenkor legépeljük a weboldalt. :)

De ez miért jobb?    
A klikkelős felületek egyfajta generált programkódot hoznak létre. Mutatok két példát, aki nem programozó az is látni fogja a különbséget ránézésre. PL az Elementornak így néz ki egy átlagos kódja:    
 

Ugyanez a megoldás így néz ki egyedi fejlesztésben:

Látható hogy az egyedi fejlesztés egyszerűsége itt jelenik meg. “Jó-jó de ezt senki nem látja amikor egy weboldalra érkezik, kit érdekel?” Látni nem látják a látogatók csak érezni fogják, elsődlegesen a weboldal sebességet. “Jó-jó de a WP-t is meg lehet csinálni gyorsra". Ez igaz, de az már nem olcsó, úgyhogy ezt meg a weboldal tulajdonos fogja érezni a pénztárcáján rendszeres költségként.

Más. Amikor egy WP-t használunk, akkor egy előre elkészített programot telepítünk ami egy általános megoldás ad, plusz valamennyire egyedivé tehetjük bővítményekkel. A WP-t is és a bővítményeket is egy másik idegen programozó készíti, akik időnként változtatnak a programkódjaikon. Ilyenkor kiadnak egy frissítést, amit el kell végezni a WP alatt is. Ez egy külső kötöttség, folytatom hogy ez miért lehet gond. A WP oldalak esetén egy idő után kötelező lesz frissítenünk, ha használni szeretnénk az oldalunk. Ha mi magunk végezzük, akkor meg van az a veszélye, hogy egy nem kompatibilis frissítés miatt összeomlik az egész oldalunk és tudnunk kell javítani azonnal. Ha egy weboldal készítőt kérünk meg, hogy frissítsen, esetleg havi rendszerességgel szerződést is kötünk a frissítésekre, akkor pedig pénzbe fog kerülni. Ilyenkor érdemes kiszámolni éves szinten mennyibe kerül az olcsónak induló WP weboldal.    
A saját egyedi fejlesztéseimnél nagyon drasztikusan lecsökkentem az összes ilyen külső kötöttséget. Nullát elérni sosem lehet, de el lehet érni azt a szintet, hogy ha a weboldal tulajdonos nem kér változtatást, akkor évekig működhet a weboldala anélkül hogy bárki hozzányúlna.

Ugyanez a problémám a bővítményekkel is. Olcsóbb beleugrani sokszor egy WP oldalba, de mivel a legtöbb bővítménynek ott van a fizetős változata (és persze a leghasznosabb funkció ami nekünk kéne a PRO változatban lesz elérhető). Ez egy újabb havi/éves ismétlődő költséget generál. És egy weboldalt legtöbbször nem 1 és nem 2 évre hozunk létre.

Biztonsági rések és hibák.    
Aki idáig lejutott az olvasásban, azoknak mutatok egy oldalt ami minden héten kigyűjti az ismert WP sérülékenységeket. Aki nem akarja megnézni, azoknak: hetente 250-350 biztonsági rést fedeznek fel a WP-ben vagy a leggyakoribb bővítményeiben. Vannak kiugró hetek is, amikor ez a szám eléri az 500-at is. https://solidwp.com/blog/category/wordpress-vulnerability-report/    
 

Egyedi problémák és igények.    
Na itt szokott elszabadulni a pokol! Amikor a WP vagy valamelyik bővítménye nem tudja megoldani a problémánk, akkor találni kell egy megoldást. Tavalyi évben találkoztam szállás foglaló bővítményre rádrótozott étel kiszállítással (bocs Gábor hogy titeket hoztalak rossz példának). Találkoztam olyan weboldallal, amit csak 20%-ban működtett a wp és 80%-ban kézzel beleírt kódok tömkelege működtette, (emiatt nem lehetett többé frissíteni). Illetve olyan nehezítésekkel amikor többféle termékopció különböző opció felárakkal és pénznemekkel. De van az az eset is amikor már 40 bővítménynél tart a WP oldal és iszonyat lassú az egész.

Egyedi fejlesztés hátrányok.   
Ahogy fentebb írtam a generált programkódok mindig bonyolultabbak lesznek mint egy igényesen megírt egyedi kód. Itt a hangsúly az igényesen van, mert sajnos vannak “spagetti” kódok is az egyedi fejlesztések között. Még nagyobb “sajnos”, hogy az ilyen spagetti kódokat író fejlesztők szoktak utána sok kárt és problémát okozni a weboldal tulajdonosok vállalkozásában, akik csalódottan hallani sem akarnak többet az egyedi fejlesztésről. Ebben meg is értem őket. Az előző fejlesztő is azt mondta neki hogy ért hozzá és megtudja csinálni, most vakon választani egy újabb fejlesztőt aki szintén azt mondja magáról hogy ért hozzá és meg tudja csinálni nem könnyű eset.    
Másik hátrány, hogy a weboldal tulajdonosként változtatást csak azon tudunk elvégezni, amihez kaptunk admin felületet. Drasztikus változáshoz pedig fejlesztő kell. Ez mondjuk nem hátrány, ha WP oldalnál is a webes embert keresnénk, mert a weboldal tulajdonos nem akar foglalkozni vele. Annak viszont hátrány, aki saját maga szeretné a teljes weboldalát szerkeszteni.

Konklúzió.   
Ebben a blogban csak a saját véleményem és eseteim szerettem volna feltüntetni. Én az egyszerűnek induló weboldalnál is egyedi fejlesztést választanék, mert olcsóbb lesz ez a kategória is. Ettől függetlenül elfogadom, hogy a WP-t sokan használják ma is és a jövőben is. Eddig is segítettem a WP oldalaknál és ezek után is fogok, de ahol szükséges ott mindig el fogom mondani hogy egyedi fejlesztéssel “egyszerűbb” lenne. :)