Azokhoz wordpress és egyéb CMS keretrendszerekhez, melyek PHP-ban készültek, csatlakoztatható hozzájuk plugin. Ezek viszont nem minden esetben kompatibilisek egymással, de az is gyakran előfordul, hogy egy új kiegészítő funkciót szeretne a felhasználó. Ekkor jön képbe a programozó.

Mi a plugin javítás menete?

Az első teendő, hogy át kell nézni, a pluginok leírásaiban milyen követelmények szerepelnek. Ugyanis, egy egyszerű hiba azzal is összefüggésben lehet, hogy a PHP melyik verziója van a szerveren. Ha nem kompatibilis a szerver PHP verziójával, akkor vagy a PHP verzióját kell módosítani, vagy a plugint kell frissíteni. Ha elvileg minden plugin kompatibilis egymással, és ennek ellenére sem működik az oldal, akkor a debug bekapcsolásával, elemezni kell a rendszert, s javítani kell a hibákat.

Sajnos, ez nem egy egyszerű feladat. A hiba okának megtalálása sokszor nehezebb, mint magát a hibát kijavítani. Nem egyszer fordult elő velem is, hogy más hibáját keresve napokat vett igénybe, de a javítás egy delete gomb, és egy karakter megnyomása volt.

Általában az elágazásoknál és ciklusoknál szokott lenni a probléma, a logikai kifejezéssekkel. De ez sem egyszerűsíti a feladatot, hiszen a programok pontosan ezek sorrendjéből, és értékadásokból áll össze. Ilyenkor, plusz üzeneteket szoktam beletenni a kódba, hogy merre is fut a program. Ez segít abban, hogy amikor fut a program, akkor nyomon tudjam követni az egy-egy eseményre történő válaszát, választását.

Azt szeretem, s ezzel szerintem nem vagyok egyedül, amikor a beillesztett kódom egyből látható, mert ez azt jelenti, hogy az eredeti kódot jól értelmeztem, olvastam.

De van, hogy annyira mély a hiba, hogy egy nagyobb átírás szükséges hozzá. Ezért, jól ki kell választani a plugin-t, természetesen ár-érték arányban, s konzultálni kell egy fejlesztővel (aki lehetek én is), hogy amit nem tud a plugin, azt bele lehet-e szerinte fejleszteni, és ha igen, akkor vállalja-e.

Sokszor hallom azt, s megértem a kollégáimat, hogy nem szeretnek más kódjában turkálni. Ez érthető, hiszen más ember gondolatmenetét kell megérteni. De egy jó fejlesztő, ezt is be meri vállalni, hiszen a rendszereket nem egy fejlesztő állítja össze, hanem sok-sok esetleg egymást sem ismerő emberek.

A probléma akkor van, amikor a rendszer, vagy a plugin úgynevezett spagetti kódos. Ez tényleg okoz problémát, mert ha egy helyen van változtatva, akkor benne van a pakliban, hogy másutt is kell változtatni. Ekkor a kód teljes átírása szükséges. Ami azt jelenti, hogy a programozást a nulláról kell kezdeni. Felteheti a kérdést a kedves felhasználó, hogy mi értelme van annak, hogy a plugin kódját átnézze egy fejlesztő, s a hibát javítsa, vagy ha nincs is hiba, de az igényeknek megfelelően alakítsa.

A legtöbben a Clean Code módszert alkalmazzák, vagy legalábbis igyekeznek azt alkalmazni, s így könnyebben átlátható a kód. Ma már nem tetszik senkinek sem az a fejlesztésvezetők között, ha a kód kifürkészhetetlen, mert a hibák könnyebben megbújnak benne, s a következő fejlesztő elölről kezdhet mindent.

Viszont, ez nem azt jelenti, hogy nem érdemes a licenceket meghosszabbítani. Azért, mert egy fejlesztő nem biztos, hogy minden hibát megtalál, s mivel neki a nem általa készített plugin-t nézi, ezért nem hozzá jönnek be arról a plugin-ról a hibajelentések. Így, a frissítéseket is érdemes letölteni, s összevetni a fejlesztőnek az általa készített módosításokkal. Ez úgy történik, hogy egy biztonsági mentést csinál a fejlesztő a régi plugin-ról, adatbázis és kód mentéssel együtt, s az új plugin-t telepíti a teszt rendszerre. Ekkor már könnyedén összetudja hasonlítani mind az adatbázis, mind a kódbeli változtatásokat. Ha a hiba javítva lett a frissítéssel, akkor a kódját, ami a hibára vonatkozik nem vezeti át, de azon módosításokat melyek kiegészítik a plugin-t, átvezeti a frissített plugin-ba.

És utána jöhet a tesztelés, a tesztelés, s a tesztelés, amíg hibára fut a felhasználó… Aztán persze az átadás.