A legtöbb WordPress bővítményfejlesztés ugyanazt az ívet járja be. Valakinek kell egy foglalási űrlap, egy hírfolyam-importáló vagy egy plusz mező a pénztárnál, egy fejlesztő megírja, működik, mindenki továbblép. Két évvel később a webhely egy régi WordPress-verzión ragadt, mert senki sem bízik abban, hogy az a bővítmény túlél egy frissítést, aki pedig megírta, régen elment.

Az ok ritkán az, hogy a mag túl gyorsan mozogna. A WordPress óvatosan bánik azzal, hogy elrontson dolgokat, és rengeteg öt éve jól megírt bővítmény változatlanul fut a WordPress 7.1 alatt. A bővítmények az első héten hozott döntések miatt romlanak el: a funkciók a sablonba kerülnek, a mag fájljait szerkesztik ahelyett, hogy horgokra kötnék, az adatok abba a szerkezetbe kerülnek, amelyik éppen kéznél volt, és soha senki nem teszteli a kiadásra jelölt verzión.

Mitől él túl egy egyedi WordPress bővítmény egy magfrissítést? Négy dologtól. A kód bővítményben lakik, nem a sablonban. Akciókon és szűrőkön keresztül bővíti a WordPresst, ahelyett hogy a mag fájljait szerkesztené. Minden adatot abban a szerkezetben tárol, amelyik az adott adat alakjához illik. És valaki minden kiadásra jelölt verzión leteszteli, mielőtt az a verzió megjelenne.

Miért bővítménybe való a WordPress bővítményfejlesztés, és miért nem a sablonba

Az egyedi kód alapértelmezett otthona a sablon functions.php fájlja, mert az már ott van, és már fut is. Ez egyben az a fájl is, amelyik a következő arculatváltásnál eltűnik.

A sablon megjelenés. Cseréljük le a sablont, és minden megáll, amit a régi végzett. Az egyedi tartalomtípusok regisztrálása elmarad, így a tartalom ott ül az adatbázisban admin képernyő és állandó hivatkozás nélkül. A rövid kódok nyers szövegként jelennek meg az oldal közepén. Az analitikai kódrészlet, a schema jelölés és az éjszakai CRM-hívás mind eltűnik, és semmi sem jelez hibát.

A szabály elég egyszerű ahhoz, hogy bekerüljön egy feladatkiírásba. Minden, aminek egy arculatváltás után is igaznak kell maradnia, bővítménybe való: egyedi tartalomtípusok és taxonómiák, bármilyen külső rendszerrel való integráció, rövid kódok és blokkok, üzleti szabályok, ütemezett feladatok, és minden, ami az adatbázisba ír. A sablonnál maradnak a sablonfájlok, a stílusok és a sablonrészletek.

A számla későn érkezik. A következő arculatváltásnál vagy újra fizet azért, hogy felépüljön, ami már megvolt, vagy átemeli a régi functions.php fájlt. Egy több éve gyűlő kódrészletekkel teli webhelyen ez több ezer font elkerülhető munka, és emiatt jön vissza egy arculatváltás ajánlata az ügyfél várakozásainak kétszeresén. A gyermeksablon is sablon.

A bővítési modell és az egyetlen szabály, ami számít

A WordPresst arra tervezték, hogy kívülről lehessen megváltoztatni. Ennek eszközei a horgok, és a horgok dokumentációja azokat az előre meghatározott pontokként írja le, ahol az egyik kódrészlet kapcsolatba léphet a másikkal vagy módosíthatja azt. Egy akció egy meghatározott pillanatban sül el, és hagyja, hogy csináljunk valamit: értesítést küldjünk egy bejegyzés közzététele után, vagy regisztráljunk egy tartalomtípust. Egy szűrő átad egy értéket, elvárja, hogy megváltoztassuk vagy békén hagyjuk, és elvárja, hogy visszaadjuk.

Az ebből következő szabály feltétlen. Ha a wp-admin, a wp-includes vagy egy másik bővítmény könyvtárában szerkeszt egy fájlt, már veszített. Ezeket a módosításokat a következő frissítés törli, figyelmeztetés nélkül, hibaüzenet nélkül, és rendszerint anélkül, hogy bárki észrevenné, amíg egy ügyfél nem jelzi, hogy valami leállt. Kérdezze meg erről egyenesen a fejlesztőt, mielőtt megbízza.

Ha a szükséges horog nem létezik, burkolja be a viselkedést ahelyett, hogy lecserélné, lépjen feljebb egy tágabb horogra, forkolja a külső bővítményt verziókövetés alatt, dokumentálva az eltérést, vagy kérje a horgot a felsőbb forrástól, hiszen a legtöbb így született meg.

Elnevezések, előtagok és egy nagyon zsúfolt névtér

A WordPressben a PHP egyetlen globális névtérben fut, amelyen a mag, az aktív sablon és minden más aktív bővítmény osztozik. Az a két bővítmény, amely egyaránt deklarál egy get_settings() nevű függvényt, nem udvariasan verseng egymással: a második végzetes hiba, a webhely pedig fehér.

Az előtagok hosszabbak, mint gondolná

A kézikönyv bővítmény-alapelveket tartalmazó oldala egyedi előtagot kér mindenre, ami globálisan elérhető, legalább négy karaktert, de inkább ötöt, kerülve a gyakori angol szavakat, és soha nem használva a wp_, _ vagy magát a WordPress szót. Több tízezer forgalomban lévő bővítmény mellett három betű az ügyfél kezdőbetűiből tiszta pénzfeldobás.

Névterek és automatikus betöltés

A modern gyakorlat a probléma felét megoldja. Deklaráljon PHP névteret, tegyen egy osztályt egy fájlba, és hagyja, hogy egy PSR-4 automatikus betöltő megtalálja őket, így nincsenek kézzel írt require utasítások, és nincs esély arra, hogy egy osztálynév ütközzön egy másik bővítményével. Ettől a kód tesztelhetővé is válik, mert a konstruktorfüggőségekkel rendelkező osztályok példányosíthatók anélkül, hogy a WordPress betöltődne.

Az automatikus betöltés nem oldja meg azt, ha két bővítmény ugyanannak a könyvtárnak más-más verzióját szállítja. Az nyer, amelyik előbb töltődik be. Terjesztésre szánt kódnál lássa el előtaggal a szállítói névtereket fordítási időben.

A szöveges kulcsok, amelyeken a névtér nem segít

A névtér a PHP szimbólumokra vonatkozik. Amit egy bővítmény regisztrál, annak nagy része viszont nem PHP szimbólum, hanem egy szöveg egy közös nyilvántartásban, és azoknál továbbra is a régi előtagszabály érvényes: horognevek, beállítás- és átmeneti kulcsok, bejegyzés-metakulcsok, tartalomtípus- és taxonómianevek, rövidkód-címkék, cron-eseménynevek, REST névterek és egyedi táblanevek. Ezek lapos térben élnek, ahol az utolsó regisztráció nyer, vagy ahol két bővítmény némán ugyanazon az állapoton osztozik.

Két korlátot érdemes ismerni, mielőtt bárminek nevet adna. Egy tartalomtípus kulcsa nem lehet hosszabb 20 karakternél, egy taxonómia kulcsa pedig 32-nél, mindkettő kisbetűs alfanumerikus, kötőjellel és aláhúzással. Egy ötkarakteres előtag 15 karaktert hagy a tartalomtípus nevének, ami kevesebb hely, mint amennyinek hangzik.

Annak eldöntése, hol lakjanak az adatok

Ez a döntés vonja maga után a leghosszabb következményláncot. Ha elhibázza, a bővítmény induláskor rendben működik, az adatok növekedésével hónapról hónapra lassul, és mire bárkinek feltűnik, a javítás már migráció, nem pedig módosítás.

Beállítások és átmeneti tárolók

A beállítások a webhelyszintű értékekre valók: néhány kulcs, kis értékek, a legtöbb kérésnél kiolvasva. A csapda az automatikus betöltés, mert minden automatikusan betöltött beállítás minden egyes kérésnél lekérdeződik, beleértve az admin-ajax és a REST hívásokat is, akár használja valami, akár nem.

A WordPress 6.6 megváltoztatta a mechanikát, ahogyan azt a Make WordPress Core blog nagy beállítások automatikus betöltésének kikapcsolásáról szóló bejegyzése leírja. A tárolt érték immár on, off vagy auto, és a 150 000 bájtnál nagyobb beállítás alapértelmezés szerint nem töltődik be automatikusan, a küszöb pedig a wp_max_autoloaded_option_size szűrővel állítható. Kezelje ezt felső határként, ne célértékként. Az átmeneti tárolók lejárattal ellátott beállítások, és ezek a helyes otthona mindennek, ami máshonnan érkezik.

A bejegyzés-metaadat nem kulcs-érték tároló

A bejegyzés-metaadat egyetlen bejegyzés jellemzőire való: egy alcím, egy ár, egy beszállítói hivatkozás. Nem általános célú kulcs-érték tároló, és az ok látszik a tábla definíciójában. A wp_postmeta táblának négy oszlopa és három kulcsa van. Csak a post_id és a meta_key első 191 karaktere indexelt. A meta_value oszlop egy longtext, egyetlen index nélkül.

Egy metaértékre szűrő lekérdezés ezért nem tud indexet használni. Egy metalekérdezés minden feltétele újabb összekapcsolást ad hozzá, és egy 50 000 bejegyzést tartalmazó webhelyen, ahol mindegyikhez 20 metasor tartozik, a tábla egymillió sort tárol. Három feltétel három összekapcsolást jelent egymillió soron, minden oldalbetöltésnél. Ez az egyik leggyakoribb oka annak, hogy egy első évében gyors webhely a harmadikban használhatatlan, és folyamatosan felbukkan a WooCommerce teljesítményével kapcsolatos munkában.

Egyedi tartalomtípusok és taxonómiák

Az egyedi tartalomtípus akkor helyes, ha a dolog tartalom. Kell neki saját listaképernyő, állandó hivatkozás, verziók és szerkesztőségi folyamat, és van értelme oldalként, amelyet valaki felkereshet. Az egyedi taxonómia akkor helyes, ha közös szókincsre van szüksége, amely ezeket a dolgokat csoportosítja, és saját archívumoldalakat érdemel.

Mindkettő ingyen hozza a gépezetet: admin képernyőket, jogosultságokat, keresést, a blokkszerkesztőt és a REST API-t. Állítsa a show_in_rest értékét true-ra, különben a blokkszerkesztő nem kezeli a típust, és mindkettőt az init horgon regisztrálja, soha nem korábban.

Mikor van tényleg szüksége saját táblára

A saját tábla akkor helyes, ha az adat nem tartalom: nagy mennyiségű, csak hozzáfűzött rekordok, például eseménynaplók, importsorok, ártörténet vagy auditnyomok, illetve bármi, amit olyan mező szerint fog szűrni és rendezni, amely nem bejegyzésoszlop. Néhány százezer sor fölött, amelyeket a saját mezőik szerint kérdez le, a megfelelő indexekkel ellátott tábla nagyságrendekkel veri a bejegyzés-metaadatot, és növekedés közben is kiszámítható marad.

Az ára az, hogy minden a magáé lesz: a tábla létrehozása és a verziózott migrációk, a takarítás az uninstall.php fájlban, a saját admin képernyők, a REST végpontok és a gyorsítótárazás. Ezért a legtöbb bővítménynél az őszinte válasz továbbra is az egyedi tartalomtípus.

A biztonság négy szokás, és hármat kihagynak belőlük

A WordPress biztonsági kézikönyve kertelés nélkül mondja ki az elvet: ne bízzon a felhasználói bemenetben, a külső API-kban, sem az adatbázisában már ott ülő adatokban. Négy szokás viszi a kockázat majdnem egészét, és az általunk auditált bővítményekben állandó sorrendben hagyják ki őket. Először a jogosultság-ellenőrzések, másodszor a nonce-ok, harmadszor a kimenet escapelése. Az előkészített utasítások jönnek utoljára, mert egy hiányzót elkap a kódellenőrzés.

Jogosultság-ellenőrzések

Minden kezelőnek, amely megváltoztat valamit, meg kell kérdeznie, hogy ez a felhasználó jogosult-e rá, ami azt jelenti, hogy current_user_can() a konkrét jogosultsággal, magában a kezelőben ellenőrizve, nem csupán a hívó gomb körül.

Az is_admin() nem jogosultság-ellenőrzés. Azt jelenti vissza, a webhely melyik oldalán jár a kérés, és true értéket ad minden bejelentkezett feliratkozóra, aki admin-ajax végpontot szólít meg. Egy jogosultság-ellenőrzés nélküli admin_post_ vagy wp_ajax_ akció minden regisztrált felhasználó számára elérhető, ami egy webáruházban minden valaha rendelt vásárlót jelent. A WordPress biztonsági megerősítési listánk az ezt körülvevő webhelyszintű védelmeket tárgyalja.

A nonce-ok

A nonce egy űrlapot vagy egy URL-t véd olyan kéréstől, amelyet a felhasználó nem szándékozott elküldeni. Használja a wp_nonce_field() függvényt az űrlapon és a check_admin_referer() függvényt a kezelőben, AJAX esetén pedig a check_ajax_referer() függvényt. A nevük ellenére nem egyszer használatosak: egy időablakra érvényes kivonatok, alapértelmezés szerint egy napra, olyan kétütemű séma szerint, amely a valós élettartamot tizenkét és huszonnégy óra közé teszi.

A nonce-ok dokumentációja egyértelműen kimondja, hogy soha nem szabad rájuk hagyatkozni hitelesítéshez, engedélyezéshez vagy hozzáférés-szabályozáshoz. A nonce azt igazolja, hogy a kérés az ön űrlapjáról érkezett. Semmit nem mond arról, hogy az adott személynek szabad-e megtennie azt a dolgot.

Bemenetnél tisztítás, kimenetnél escapelés

Ellenőrizze, ahol tudja, mert az ellenőrzés konkrét: egy irányítószám vagy illeszkedik a mintára, vagy nem. Tisztítson ott, ahol nem tud ellenőrizni, a mezőtől függően a sanitize_text_field(), sanitize_email(), sanitize_key(), absint() vagy wp_kses_post() függvénnyel.

Azután escapeljen a kiírás pontján, minden alkalommal, az esc_html(), esc_attr(), esc_url() vagy wp_kses_post() függvénnyel. Az escapelés dokumentációja ezt a lehető legkésőbb kéri, hogy az ellenőrző az escapelést és a kiírást ugyanabban a sorban lássa. Az escapelést hagyják ki a leggyakrabban, mert semmi nem néz ki rosszul, ha kihagyják. Az oldal tökéletesen megjelenik egészen addig, amíg valaki be nem ír egy script címkét egy mezőbe.

Előkészített utasítások

Minden saját kezűleg írt lekérdezés a $wpdb->prepare() függvényen megy át, amely %d jelet fogad egészekhez, %f jelet lebegőpontos számokhoz, %s jelet szövegekhez és %i jelet azonosítókhoz, például tábla- és oszlopnevekhez. A helyőrzők idézőjel nélkül maradnak, a szó szerinti százalékjelet kétszer kell kiírni, a LIKE helyettesítő karakterét pedig a behelyettesítendő argumentumban kell átadni, nem a lekérdezésbe gépelve. Egy változó SQL-be fűzése nem stílusbeli nézeteltérés, hanem maga a sebezhetőség.

A REST API és a blokkszerkesztő

Egy idén írt bővítménynek a REST API-n keresztül kellene közzétennie az adatait, a beállításait pedig a szerkesztőn keresztül, nem egy kézzel összerakott beállításoldalon.

Az útvonalakat a register_rest_route() függvénnyel regisztráljuk a rest_api_init horgon. A WordPress 5.5 óta a permission_callback argumentum kötelező, elhagyása pedig _doing_it_wrong() figyelmeztetést vált ki, amely megnevezi az útvonalat. A ténylegesen nyilvános végpont a __return_true értéket használja, és éppen ez a tervezés lényege: egy útvonal nyilvánossá tétele szándékos kódsorrá válik mulasztás helyett. Az egyedi végpontok dokumentációja az argumentumsémát is tárgyalja, ahová a tisztító és ellenőrző visszahívások tartoznak, hogy rossz bemenet soha ne érje el a kezelőjét.

A beállításokat a register_setting() függvénnyel és a show_in_rest true értékével regisztráljuk. Ez a mag beállítási végpontjára teszi őket, így a blokkszerkesztő vagy egy külső szkript olyan felületen keresztül olvashatja és írhatja őket, amely a hitelesítést, a jogosultságokat és az ellenőrzést már elintézi. Ezzel megszűnik egy beállításoldal, annak nonce-a, űrlapkezelője és a bennük lakó hibák.

A blokkokat egy block.json fájlból regisztráljuk, ami a WordPress 5.8 óta az ajánlott kanonikus módszer. A blokk-metaadatok dokumentációja megfogalmazza az előnyt: az ott deklarált erőforrások csak azokon az oldalakon töltődnek be, ahol a blokk megjelenik, nem pedig az egész webhelyen, csak mert egy bővítmény aktív.

Teljesítménybeli fegyelem a bővítményen belül

Négy dolog adja a bővítmények okozta lassulás legnagyobb részét, amit auditokon találunk, és mind a négy olcsón elkerülhető és drágán javítható utólag. Az első az automatikusan betöltött beállítás, mert minden kérésnél kerül valamibe, örökre.

A második a gyorsítótárazatlan távoli kérés az oldal betöltése közben. Egy wp_remote_get() hívás egy beszállító API-jára gyorsítótárazás nélkül azt jelenti, hogy minden látogató arra a beszállítóra vár. Ha a beszállító lassú, az ön webhelye lassú, ha pedig leáll, a webhely az időtúllépésig áll. Tárolja a választ átmeneti tárolóban, állítson be kifejezett időkorlátot, és döntse el előre, mit jelenít meg az oldal, ha a hívás elbukik.

A harmadik a cikluson belüli lekérdezés. A get_post_meta() hívása 200 sor mindegyikére 200 oda-vissza utat jelent, hacsak a metaadatok gyorsítótára nincs előre feltöltve, és a WP_Query ezt megteszi ön helyett, ha hagyja. A javítás rendszerint az, hogy hagyjuk abba valaminek a kikapcsolását, ami egy Core Web Vitals audit legtöbb megállapítására is igaz.

A negyedik az a munka, amely valakinek az oldalkérésén belül zajlik. A WP-Cron nem rendszerszintű cron: oldalbetöltéskor indul, tehát az ütemezett feladat egy látogató kérésén belül fut, egy csendes webhelyen pedig a hajnali kettes feladat addig nem indul el, amíg öt órakor valaki be nem néz. Definiálja a DISABLE_WP_CRON konstanst, hajtsa a wp-cron.php fájlt valódi rendszerütemezőből, és tartsa a feladatokat rövidnek és idempotensnek.

A magfrissítések túlélése: a rész, amelyre senki sem tervez keretet

A mag ritkán töröl bármit egy csapásra. A függvények elavulttá válnak, tovább működnek és figyelmeztetést adnak, és éppen ezért a WP_DEBUG bekapcsolásával futó tesztkörnyezet a létező legolcsóbb korai riasztórendszer. Az elavulási figyelmeztetés dátumozott meghívó arra, hogy javítson meg valamit, amíg még olcsó.

A meglepetéseket megelőző folyamat körülbelül negyedévente egy órába kerül. Kövesse a mag fejlesztői blogját, hogy tudja, mikor van béta, majd kiadásra jelölt verzió. Olvassa el a Field Guide-ot, amely a kiadásra jelölt szakaszban jelenik meg, és amely felsorolja az adott kiadás fejlesztőknek szóló újdonságait és a törő változtatásokat. Ezután tegye fel a kiadásra jelölt verziót egy tesztmásolatra, és futtasson le egy leírt füstpróbát a bővítmény valódi funkcióira.

A verziótámogatás annyit számít, mint a kód. A WordPress a PHP 7.4 verzióját kéri abszolút alsó határként, és a 8.3 vagy újabb verziót ajánlja, mellette MariaDB 10.11 vagy MySQL 8.0 verziót. Adja meg őszintén a Requires PHP és a Requires at least értékét a bővítmény fejlécében, majd a legalacsonyabb megadott verzión teszteljen, ne azon, ami a fejlesztő laptopján fut.

Verziózza a saját bővítményét szemantikusan, és gondolja komolyan. A javítóverzió megjavít valamit, a kisebb verzió úgy ad hozzá viselkedést, hogy semmit nem tör el, a nagyobb verzió pedig törhet, feltéve hogy megmondja, mit tört el. Az automatikus frissítést használó ügyfelek erre az ígéretre támaszkodnak.

Terjesztés, licencelés és hogyan jutnak el a frissítések a webhelyre

A WordPress a GPL 2-es vagy későbbi verziója alatt jelenik meg, és a wordpress.org licencoldala fejti ki a projekt álláspontját, amely szerint a bővítmények és a sablonok származékos művek, amelyek öröklik a licencet, miközben elismeri, hogy jogi szürke zóna, mi számít származékosnak.

A forráskódot mindig megkapja, és bárki mást megbízhat a módosításával. Amit a GPL nem tesz meg, az az, hogy közzétételre kötelezze, így egy cégnek épített bővítmény maradhat zárt. Azt sem akadályozza meg, hogy a fejlesztő ugyanazt a munkát eladja valaki másnak. Ha a kizárólagosság számít, az szerződéses kikötés, nem licenckérdés.

Ha a bővítmény bekerül a nyilvános tárba, meg kell felelnie a bővítménytár irányelveinek, amelyekből tizennyolc van. Az első GPL-lel összeegyeztethető licencet kér a csomagban lévő mindenre, a képeket is beleértve. Mások kizárják a trialware-t, vagyis a fizetés vagy bővítés mögé zárt funkciókat, tiltják az obfuszkált kódot, tiltják a felhasználók hozzájárulás nélküli követését, és tiltják a nyilvános webhelyre engedély nélkül felkerülő hivatkozásokat és feltüntetéseket.

Ha zárt marad, a frissítés az ön dolga lesz. Állítsa be az Update URI fejlécet, amely azért létezik, hogy egy zárt bővítményt ne írjon felül egy hasonló nevű a tárból, és szolgálja ki a frissítéseket a saját végpontjáról. Ha ezt hagyja a végére, így jut oda az ügyfél, hogy FTP-n frissít.

Mennyibe kerül egy egyedi WordPress bővítmény

Az alábbi sávok brit ügynökségi árak fontban, az itt leírt színvonalon leszállított munkára: tesztekkel, dokumentációval és egy megnevezett felelős személlyel az indulás után. Egy hozzáértő WordPress- és PHP-fejlesztő nagyjából napi 400 és 600 font között számláz, tehát ezek a terjedelemről szólnak, nem a díjszabásról.

Egy kis segédbővítmény 1500 és 3000 font között van. Egyetlen feladat, néhány horog, esetleg egy beállítási kapcsoló: átirányítások kezelése, egy plusz mező a megrendelésen, egy éjszakai export a beszállítónak.

Egy közepes méretű integráció 3000 és 15 000 font között van. Egy külső API hitelesítéssel, újrapróbálkozásokkal és hibakezeléssel, egy egyedi tartalomtípus, admin képernyők és háttérfeldolgozás. Ezt a méretet rendelik meg a leggyakrabban, és ezt becsülik alá a leggyakrabban, mert az integráció egy hét, a hibakezelés pedig két hét.

Egy komoly termékbővítmény 20 000 és 75 000 font között van, és fölötte. Saját táblák, blokkszerkesztős felületek, licencelési és frissítési infrastruktúra, többwebhelyes támogatás, és egy támogatási teher, amely az indulás napján kezdődik.

A sáv alján fizetni nem eleve rossz döntés. Akkor rossz, ha az ár olyan terjedelemből jött, amely csendben kihagyta az alábbi szállítandókat. A WordPress-fejlesztői díjakról és a feltehető kérdésekről szóló útmutatónk elmondja, hogyan kell egy ajánlatot olvasni, WordPress-fejlesztés oldalunk pedig azt, hogyan határozzuk meg ennek a munkának a terjedelmét.

Mi legyen benne a szállítmányban

Kérje mindezt írásban, mielőtt a munka elkezdődik, mert mindegyik olcsón belefér és drágán pótolható. A forráskódot, az ön tulajdonában lévő tárolóban, sértetlen előzményekkel, nem pedig egy utolsó napon elküldött tömörített fájlként. Egységteszteket az üzleti szabályokra és egy integrációs tesztet mindenre, ami az adatbázisba ír vagy külső szolgáltatást hív, mert ettől lesz két év múlva biztonságosan módosítható olyasvalaki számára, aki nem volt ott.

Egy readme fájlt, amely megmondja, mit csinál a bővítmény, mire köt rá, mit tárol és hol, milyen külső szolgáltatásokat hív, és mi történik, ha ezek bármelyike kiesik. Két oldal bőven elég, és a hiánya az oka annak, hogy a bővítményeket inkább lecserélik, mint karbantartják. Egy uninstall.php fájlt, amely eltávolítja a beállításokat, a táblákat, a cron-eseményeket és a metaadatokat. És egy megnevezett támogatási megállapodást, amely fedezi a tesztelést minden magkiadáson és a talált hibák javítását.

Hogyan épül meg

A Mecanik mindhárom fenti méretben épít bővítményeket, és átvesz olyanokat is, amelyeket más írt, ami gyakran a hasznosabb megbízás. WordPress-fejlesztő és szoftverfejlesztés oldalunk elmagyarázza, hogyan határozzuk meg a terjedelmet és hogyan szállítunk. Ha már van egy bővítménye, amelyhez senki nem akar hozzányúlni, a fenti gyakorlatok szerinti audit körülbelül egy napot vesz igénybe, és megmondja, javítható-e vagy inkább cserélendő.

Gyakran ismételt kérdések

Az egyedi funkciók bővítménybe vagy a sablonba valók? Bővítménybe, hacsak nem tisztán megjelenésbeliek. A sablont a következő arculatváltásnál lecserélik, és minden megáll, amit végzett: az egyedi tartalomtípusok elvesztik az admin képernyőiket, a rövid kódok nyers szövegként jelennek meg, az integrációk pedig némán leállnak. Minden, aminek egy arculatváltás után is igaznak kell maradnia, bővítménybe való.

Mennyibe kerül egy egyedi WordPress bővítmény az Egyesült Királyságban? Egy kis segédbővítmény jellemzően 1500 és 3000 font között van, egy közepes méretű integráció külső API-val és admin képernyőkkel 3000 és 15 000 font között, egy komoly termékbővítmény pedig saját táblákkal és frissítési infrastruktúrával 20 000 és 75 000 font között vagy afölött. Az erre a munkára képes fejlesztők nagyjából napi 400 és 600 font között számláznak.

Elfogadható-e valaha a WordPress magját vagy egy másik bővítmény fájljait szerkeszteni? Nem. Ezeket a módosításokat a következő frissítés törli, hibaüzenet nélkül, és rendszerint anélkül, hogy bárki észrevenné, amíg valami le nem áll. Használjon helyettük akciókat és szűrőket. Ha a szükséges horog nem létezik, burkolja be a viselkedést, forkolja a bővítményt verziókövetés alatt, vagy kérje a horgot a felsőbb forrástól.

Az enyém-e az a bővítmény, amelynek megépítéséért fizettem? Az ön tulajdona a saját példánya és az, amit a szerződés kimond. A GPL megadja a forráskódot, a módosítás jogát és azt a jogot, hogy bárki mást megbízzon a karbantartással, közzétételre pedig nem kötelezi, így egy cégnek épített bővítmény maradhat zárt. Nem akadályozza meg, hogy a fejlesztő ugyanazt a munkát továbbadja, ezért írja bele a kizárólagosságot a szerződésbe, ha számít.

Hogyan előzhető meg, hogy egy bővítmény elromoljon egy WordPress-frissítéskor? Tesztelje minden kiadásra jelölt verzión egy tesztmásolaton, mielőtt az a verzió megjelenik, futtassa a tesztkörnyezetet bekapcsolt WP_DEBUG mellett, hogy az elavulási figyelmeztetések korán előjöjjenek, és adja meg a fejlécben a támogatott PHP- és WordPress-verziókat. A WordPress a PHP 7.4 verzióját kéri alsó határként, és a 8.3 vagy újabb verziót ajánlja.