A WordPress és a letöltött plugin esete

Egy tavalyi statisztika szerint az interneten fellelhető oldalak 19%-a WordPress motort használ. Több százan részt vesznek a fejlesztésében, és 2-3 havonta jönnek ki új verziókkal. Talán méltán nevezhető opensource megoldásnak, és sok esetben az ügyfél ragaszkodik is hozzá. A hivatalos oldalán több, mint 32 ezer plugin elérhető hozzá, s ez a szám sokakat arra ösztönöz, hogy könnyelműen elvállaljanak egy munkát minél kevesebb fejlesztést remélve a kész bővítmények használatától. Na, ezen a ponton hibáznak! :)

Természetesen ez a kijelentés így nem teljesen igaz, hiszen vannak olyan esetek, amikor igenis jobban jársz egy plugin alkalmazásával, mintha saját magadnak fejlesztenéd le a funkciót sok-sok munkaóra alatt. Arról nem is beszélve, hogy a kevésbé, vagy programozni egyáltalán nem tudó felhasználóknak ezek nagy segítséget jelentenek. Ők inkább kattintgatnak addig, míg olyan nem lesz a megjelenés és működés, amilyet szeretnének (vagy amilyenre sikerül).

A buktatók

A problémát az okozza az ilyen esetekben, hogy úgysem találsz olyan bővítményt, ami pontosan azt csinálja, amit te elképzeltél. Számos alkalommal rávágtuk projekt tervezésekor, ha kellett egy egyszerű dokumentumtár, hogy nem gond, letöltünk egy már elkészített bővítményt és csak kicsit testre kell szabni a megjelenését. A testreszabás mindig több időt vett igénybe, mint azt gondoltuk. Ha van rá lehetőség, hogy az adminisztrációs felületen beállítsd a megjelenést és a szükséges dolgokat, még nincs nagy gond. Viszont amikor már ahhoz kell folyamodnod, hogy beleírj a plugin kódjába, akkor számolnod kell az esetleges későbbi kellemetlenségekkel.

Az egyik legkomolyabb gond a plugin frissítésekor jelentkezhet, amennyiben belenyúltál a kódjába. A frissítés során ugyanis felülíródnak a fájlok és búcsút inthetsz az általad eszközölt módosításoknak. Persze ha csak a megjelenés a kérdéses, a sablonba írt css felülbírálásokkal kivitelezhető a dolog, de valljuk be, nem túl elegáns megoldás.

A nyilvánosan elérhető bővítményeknek van még egy hátrányuk, mégpedig, hogy növelik az oldalunk támadhatóságát. Rövid forrás-böngészéssel könnyen beazonosíthatóak az oldal által használt bővítmények és percek alatt elérhetjük a forráskódjukat. És egy rosszul megírt plugin bizony komoly kiskapukat adhat a rosszindulatú felhasználóknak. Elég csak a nemrég történt eseményekre gondolni, milyen károkat okozott egy bővítményben hagyott biztonsági rés. Ha nem vagy rest utánajárni, számos bővítmény a sablonba elhelyezett pár sornyi PHP kóddal kiváltható. Legegyszerűbb példa rá a WordPress admin bar problémája. Létezik hozzá egy letölthető plugin, ugyanakkor egy sorral elintézhető, amit a sablon functions.php fájlba kell beillesztened.

Azért ne írjuk le őket…

A fent leírtak természetesen nem azt akarják sugallni, hogy ne használj bővítményeket, és írj meg magadnak mindig mindent. Vannak robusztus pluginek (bbpress, woocommerce, stb.), amiket felesleges lenne újra megírni, vagy annyira kézenfekvő a működésük, hogy ha saját magadnak kódolnád le, ugyanaz jönne ki. Minek megírni a nyelvesítést megvalósító bővítményt, ha már megtették előttünk, és jól működik? Abban az esetben sincs sok értelme magadnak kódolni, ha csak például az adminisztrációs felületet akarod használhatóbbá tenni.

Konklúzió

A bővítmények jók, nem véletlenül vannak és érdemes őket használni. Viszont, ha fejlesztő vagy és WordPress-re épülő, egyedi és minőségi oldalakat akarsz kiadni a kezeid közül, akkor érdemes jó néhány esetben saját megoldások felé nyitni, és nem kell más kódját bogarásznod, módosítanod, felülírnod. Hiszen mennyivel szebben is néz ki egy admin felület, ahol nem csak a telepített bővítmények kevert nyelvű felületei láthatóak, hanem mindennek szépen meg van a helye.