WordPress on väga populaarne viis saidi kiireks käivitamiseks. Kiirustades jõuavad paljud arendajad siiski kohutavate otsusteni. Mõned vead, näiteks lahkumine WP_DEBUG seatud väärtusele true võib olla lihtne teha. Teised, näiteks kogu teie JavaScripti ühte faili koondamine, on sama levinud kui laisad insenerid. Ükskõik mis vea teil õnnestub teha, lugege edasi, et teada saada 12 kõige levinumat WordPressi viga, mida uued ja kogenud arendajad teevad. Kui leiate, et teete ühte neist vigadest, ärge heitke meelt. Iga viga on võimalus õppida.

1. WordPressi teema JavaScripti koodi paigutamine ühte põhifaili

Kord kliendi veebisaitide lehekiiruse optimeerimise ajal märkasin, et nad kasutavad lisateemat, millel on kõik kasutatavad teegid, sealhulgas kohandatud kood, ühes failis nimega main.js, theme.js või custom.js. See tava on halb järgmistel põhjustel:

1. Aja jooksul võib fail tõeliselt suureks muutuda, kuna aktiivselt arendatava teema funktsioonid suurenevad ja mõnikord näete faile, mille suurus on 1 MB. Fail laaditakse kogu saidi ulatuses isegi siis, kui mõnel lehel on vaja ainult 10% faili koodist. See muudab lehtede allalaadimise kauem aega ja renderdamise aeglasemaks, eriti kui see on renderdamise blokeerimine kood lehe päisesektsioonis.
2. See muudab failis oleva koodi haldamise keerulisemaks, kuna te ei saa kasutada selliseid funktsioone nagu wp_dequeue_script() mõnel lehel osa koodist maha laadima, et parandada lehe kiirust või vältida konflikti mõne muu JavaScripti koodiga, mille üks aktiivsetest pistikprogrammidest võiks laadida. Muidugi saab faili jagada mitmeks ja lisada WordPressile, kuid kui mõni aeg hiljem värskendab veebisaidi administraator teemat main.js faili, siis peab kogu protsess otsast peale alustama.

2. Muutujate, funktsioonide, konstantide või klasside jaoks liiga tavaliste nimede kasutamine

Pistikprogrammi väljatöötamisel on parem kasutada nimetamiskorda, mis hoiab ära koodide konflikti juhul, kui sama nime kasutavad muud pistikprogrammid. Sellepärast lisavad paljud arendajad oma muutujate ja funktsiooninimede ette millegi ainulaadse ja pistikprogrammiga seotud. Lisaks koodikonfliktide kõrvaldamisele muudab see ka asjade leidmise lihtsamaks, kui teil on lubatud palju pistikprogramme.

Seevastu on arendajaid, kes eelistavad PHP-nimeruume kasutada üksuste kapseldamiseks ja kahe probleemi lahendamiseks, millega raamatukogude ja rakenduste autorid korduvkasutatavate koodielementide, näiteks klasside või funktsioonide loomisel kokku puutuvad:

1. Nimetage nende loodud koodi ja sisemise PHP või kolmanda osapoole klasside, funktsioonide või konstantide kokkupõrked
2. Võimalus varjunime (või lühendada) Extra_Long_Names mõeldud esimese probleemi lahendamiseks või lähtekoodi loetavuse parandamiseks. See on minu lemmik, kuna töötan sageli välja palju koodi sisaldavaid teemasid või pistikprogramme. Selle abil saan koodi hõlpsalt lugeda ja hallata, ilma et peaksin palju muretsema pikkade ainulaadsete nimede pärast.

Soovitan nimeruumidest enne nende kasutamist hästi aru saada, kuna neid saab sageli valesti kasutada.

Sõltuvalt projektist, mille te kaasate, peate tõenäoliselt kinni pidama olemasolevast kodeerimisstiilist, välja arvatud juhul, kui teie töö on enamasti olemasolevast eraldi. Juhul, kui peate laiendama olemasolevat pistikprogrammi või teemat, mis juba järgib PHP kodeerimisstandardid WordPressi jaoks on kõige parem neist püsida, et oleks ühtlane stiil, nii et kood muutub puhtaks ja hõlpsasti loetavaks. Pange tähele, et mõningaid reegleid rakendatakse jõudluse parandamiseks universaalselt, eirates kodeerimisstiili. Näiteks on alati kõige parem kasutada üksikuid jutumärke (topeltjoonte asemel), kui te ei hinda stringis midagi. Samuti tuleb kood lugemiseks taanduda, eriti kui sellel on pesastatud kood (nt IF s IF s sees, pesastatud FOREACH s ja FOR s).

3. Olemasoleva WordPressi põhifunktsioonide tõelise potentsiaali ärakasutamine

Kuna WordPressil on komplekt regulaarselt värskendatavaid teeke, mida saab lihtsalt meie pistikprogrammides ja teemadel kutsuda, on kõige parem kasutada võimalikult palju olemasolevat põhifunktsionaalsust. Olen näinud WordPressi teemasid ja pistikprogramme, mille varakataloogis olid failid, mis olid juba WordPressi põhifailides (nt jQuery või Color Picker). Lisaks asjaolule, et pakett suureneb ja võrgu kaudu laadimine võtab kauem aega, peate tagama ka kõigi kolmandate osapoolte teekide korrapärase värskendamise, mis on lihtsalt üks asi, mille eest hoolitseda.

Kasutage seda, mida WordPress juba pakub, kuna WordPressi arenduse põhimeeskond on raamatukogusid juba värskendanud ja teil võib olla kerge ja hõlpsasti hooldatav projekt. Korrapäraselt WordPressi värskendusi tehes saate juurdepääsu rohkematele funktsioonidele (olgu see siis pistikprogramm, teema või WordPressi tuum ise, kuna selle juhtpaneeli pidevalt täiustatakse) ja muudate veebisaidi turvalisemaks juhul, kui vanades koodiväljaannetes leitakse haavatavusi.

4. Pistikprogrammi või teema muutmine toimingute ja filtrite abil hõlpsasti muutmata

WordPressi pistikprogrammi või teema otse muutmine on halb mõte, välja arvatud juhul, kui olete muidugi otseselt seotud selle paketi arendamisega ja panustate selle koodi juurde. Kui pistikprogrammi või teemat värskendatakse automaatselt, lähevad paketi otsesed muudatused kaotsi ja peate faile uuesti redigeerima.

Seetõttu on nii toimingute ja filtrite kasutamine kui ka lapseteema loomine (mis laiendab vanemat teemat) teema muutmiseks kõige tõhusamad lähenemisviisid, kuna saate olemasolevat funktsionaalsust muuta ilma vanematemaatikat või pistikprogrammi ennast muutmata. Veelgi enam, kui pakute pistikprogrammi WordPress.org tasuta allalaadimiseks ja soovite hiljem luua lisalaiendi, mis sõltuks vanempluginist, peaksite tasuta pistikprogrammi välja töötama nii, et see olema hõlpsasti laiendatav ja lisatav lisatasu.

5. Arendamine WP_DEBUG abil Määra väärtuseks false

Vaikimisi on WP_DEBUG konstant on seatud väärtusele „väär”, et vältida PHP-vigade, hoiatuste ja teadete printimist. Reaalses keskkonnas on see soovitatav valik, kuna see hoiab avalike vaadete eest varjatud eraserveri teed ja skriptid, mis on turvalisuse huvides suurepärane. Arendamise etapis on siiski parem, kui see on seatud väärtusele „Tõene”, kuna see teavitab meid kõigist vigadest meie koodis. Isegi kui vead ei mõjuta otseselt funktsionaalsust, sunnib see teid sageli paremat koodi kirjutama ja paremaid kodeerimisharjumusi välja töötama. See juhtus minuga. See tagab ka selle, et teie välja töötatud pistikprogramm või teema ei tekita PHP-vigu üheski WordPressi installis.

Kuigi seda teevad kõige kogenumad arendajad, juhtub see eriti kiirustades. Ükskõik kui kiireloomuline see töö on, peaksid arendajad alati proovima säilitada WordPressi kodeerimisstandardeid, jälgides silmnähtavalt PHP parimaid tavasid.

6. PHP-koodi kirjutamine, arvestamata sellega, et lehe võiks ühel päeval vahemällu salvestada

See on tavaline PHP viga ja sarnaselt eelmisele on seda suhteliselt lihtne vältida, kui järgite PHP kodeerimisstandardeid.

Mõnel arendajal on kombeks rakendada PHP-i juppe teemadesse ja pistikprogrammidesse, mis kehtivad ainult siis, kui PHP-kood on kogu aeg käivitatud. Näiteks tuleks teha PHP-funktsioon, mis reageerib HTTP-kasutajaagendile teatud toimingutega või mitte (nt varjates ainult mobiilikasutajatele mõeldud skripte).

Kui teie klient installib pistikprogrammi, mis salvestab lehe vahemällu (nt W3 kogu vahemälu või WP Rocket), käivitamata teie teema või pistikprogrammides olevaid tingimusi, muudetakse teie PHP-kood kasutuks. Kui kavatsetakse muuta lehed reageerivaks, tuleks seda teha eesservas meediumipäringute ja JavaScripti kaudu. Viimast ainult siis, kui seda tõesti nõutakse. Ideaalis soovite vältida saidi tundlikuks muutmiseks JavaScripti kasutamist.

7. Professionaalsel viisil tehtud muudatuste mittejälgimine versioonihaldussüsteemi (nt Git) kaudu

Kohandatud kodeeringuga failid, näiteks alateema või kohandatud pistikprogramm, peaksid ideaalis olema versiooni kontrolli all. Git loob muudetust rekordi ja võimaldab arendajatel töötada koos sama WordPressi projektiga või naasta eelmisele versioonile lihtsalt siis, kui veebisaidil midagi valesti läheb. Veelgi enam, kliendid saavad Giti abil jälgida kogu tööajalugu, mille tegid kõik selle konkreetse projekti jaoks palgatud arendajad, eriti kui see oli suur pikaajaline WordPressi kohandatud veebisait.

Ehkki see võib alguses olla hirmutav, eriti nooremate arendajate jaoks, on Giti mõistmine seda aega väärt ja Git GUI tarkvara nagu SourceTree (üks minu lemmikutest) oleks lihtsalt see, kuidas te oma Giti hoidlatega suhtlete, muutes selle tervikuks. õppimiskõver nauditavam. Kui olete aru saanud, kuidas see töötab, kaaluge kontrollimist Kasutage ApeeScape'i arendajate parimaid tavasid ja näpunäiteid see selgitab põhjalikumalt Giti kasutamist.

8. CSS- ja JavaScripti failide kaasamine, kui neid pole vaja

Paljude HTTP-päringute olemasolu korral muutuks veebisaidi laadimine aeglasemaks, seega oleks Google PageSpeedis madalam tulemus, mis tõenäoliselt mõjutaks otsingu asetust. See võib pistikprogrammide vaheliste konfliktide tõttu põhjustada ka JavaScripti vigu. Näiteks võib olla kaks pistikprogrammi, mis kasutavad ühist jQuery teeki, mida võidakse laadida kaks korda ja see võib tekitada probleeme. Ja tõesti, see on parim näide, kuna jQuery laaditakse veebisaitidele väga sageli mitu korda. See juhtub tõenäoliselt halvasti kirjutatud pistikprogrammide või teemade tõttu.

9. Kasutades .php Staatilise .css asemel CSS-i või JavaScripti koodi väljastamise failid ja .js Toimikud

Olen näinud teemasid ja isegi WordPressi pistikprogramme, millel olid sellised failid nagu style.php mida kasutati lihtsalt kohandatud CSS-koodi loomiseks ja selle printimiseks. Sellised asjad nagu värvid, fondi suurus ja tühik elementide ümber määrati teema seadetes ja salvestati seejärel andmebaasi. Seejärel loetakse style.php (nt) ja genereeritakse armatuurlaual värskendatud kohandatud sätete põhjal CSS-kood.

See on WordPressi jõudluse osas tõesti halb tava. Siin on peamised puudused, mis sellega kaasnevad:

1. Kuna CSS-faili laaditakse head -s tag (mis on tavaline ja enamik neist laaditakse niimoodi), sellega kaasneb toimivusprobleem, kuna brauser peab faili enne lehe renderdamist täielikult alla laadima. Kui WordPressi keskkond on mõne pistikprogrammi tõttu aeglane, lükkab see laadimisaega märkimisväärselt edasi. Isegi kui kasutatakse vahemäluvõtteid või laaditakse väärtuste andmebaasist toomiseks vaid osa WordPressi keskkonnast. Parem on kasutada staatilist .css-faili.
2. PHP-failis on koodi (CSS-reeglid segatud PHP muutujate ja tingimuslausetega) arendajatel raskem lugeda, kui neil on vaja midagi üle vaadata. Muidugi saab faili brauseris käivitada (kuigi olen kindel, et see on prinditud, isegi ei taanitata ega kena välimusega), kuid kui teil on projekti kohalik koopia ja sirvite teema koodi ja vajate CSS-i või JavaScripti süntaksi leidmiseks (juhul kui kasutataks script.php-d), muudaks see loetavuse raskemaks.

Lahendus: salvestage kohandatud CSS väljaspool pistikprogrammi kataloogi. Näide: /wp-content/uploads/theme-name-custom-css/style-5.css. Sel juhul, kui teema või pistikprogramm värskendatakse, ei lähe kohandatud fail kaduma.

10. WordPressi pistikprogrammide ja teemade jaoks õige arhitektuuri (koodiorganisatsiooni) mitte kasutamine

Sõltuvalt pistikprogrammi suurusest ja olemusest (nt eraldiseisev pistikprogramm või pistikprogrammilaiend, mis töötab ainult siis, kui on aktiveeritud mõni põhiplugin, näiteks WooCommerce), tuleb seadistada õige arhitektuur ja koodikorraldus.

Kui peate kliendi jaoks ehitama üheotstarbelise WordPressi pistikprogrammi ja sellel on piiratud interaktsioon WordPressi tuuma, teemade ja muude pistikprogrammidega, ei ole keeruline keerukate klasside väljatöötamine, kui te pole kindel, et pistikprogramm laieneb hiljem märkimisväärselt peal.

Kui pistikprogrammi pakutakse rikkalikult ja palju koode, oleks otstarbeka programmeerimise (OOP) kodeerimismeetodi kasutamine (millel on palju klasse). Näiteks kui teil on palju otsekoode, võite need kõik hoida eraldi klassifailis, näiteks class.shortcodes.php või kui juhtpaneeli ja esiosa vaates on mõeldud CSS- ja JavaScripti faile, siis üks klass nagu class.scripts.php saab kasutada ja meelitada esiotsa faile sellise meetodi abil nagu enqueue_public_scripts() samal ajal enqueue_admin_scripts() -i administraatoripiirkonda laadimiseks mõeldud failid meetod.

Selle asemel, et HTML-i PHP-koodiga segada, on parem hoida see eraldatuna, lisades pistikprogrammidesse ja teemadesse MVC-mustri. Hea näide on WooCommercei pistikprogramm. Sellel on mitmesuguste paigutuste mallid, mida saab ka teema või mitmesuguste filtrite abil hõlpsasti üle kirjutada lihtsalt seetõttu, et loogika on kujundusest eraldatud. HTML-paigutust sisaldavat malli kasutatakse enamasti juba töödeldud teabe printimiseks. HTML-koodi olemasolu PHP-meetodites on tavaliselt halb tava (HTML-koodi väikeste bittide jaoks on muidugi ka erandeid), eriti pistikprogrammi puhul, mida suuruse kasvades hoiab rohkem kui üks arendaja.

WordPressi pistikprogrammi käsiraamatu kohaselt võib küll arvukalt võimalikke arhitektuurimustreid grupeerida laias laastus kolme variatsiooni:

• Üks pluginafail, mis sisaldab funktsioone
• Üks pistikprogrammi fail, mis sisaldab klassi, kohandatud objekti ja valikuliselt funktsioone
• Peamine pistikprogrammi fail, seejärel üks või mitu klassi faili

11. Ärge võtke WordPressi turvalisust koodi kirjutamisel tõsiselt

Turvalisust ei võeta WordPressi arendamisel sageli tõsiselt, kuna paljud algajad arendajad keskenduvad rohkem klientide soovitud tulemustele. Kõik on korras, kuni kliendi veebisait häkitakse või teie WordPress.org-is avaldatud pistikprogrammil on haavatavus, mis mõjutab tuhandeid veebisaite. Neid asju juhtub mõnikord ja isegi WordPressi tuumik on CMSi algusaegadest alates tegelenud üsna paljude turvaaukudega. Meie kohustus on muuta see võimalikult turvaliseks ja juhul, kui midagi juhtub, tegutsema kiiresti ja veenduma, et vabastame kindla, hästi testitud plaastri.

Mõned kõige olulisemad turvanõuanded on:

XSS-i haavatavused: Selle vältimiseks tuleb teha kaks asja: puhastada andmesisestus ja väljundandmed. Sõltuvalt andmetest ja kontekstist, milles seda kasutatakse, on WordPressis mitu meetodit koodi desinfitseerimiseks. Ei tohiks usaldada sisendandmeid ega trükitavaid andmeid. Üks levinud funktsioon andmete sisestamisel on sanitize_text_field() . See kontrollib sobimatuid UTF-8 märke, teisendab üksikudesc_url() funktsioon, mis lükkab tagasi valed URL-id, kõrvaldab valed märgid ja eemaldab ohtlikud märgid.

Välistage otsene juurdepääs teie failidele: failidele pääseb otse juurde, kuna enamik hosti lubab seda. Kui see juhtub aga ja kood pole selle käsitlemiseks õigesti kirjutatud, võidakse printida mõned vead (nt puuduvad funktsioonid või muutujad, mida pole deklareeritud), mis sisaldaksid potentsiaalsetele ründajatele väärtuslikku teavet. Üks levinud koodilõik, mida sageli pistikprogrammides ja teemadel näete, on:

// Exit if accessed directly if ( ! defined( 'ABSPATH' ) ) exit;

Kui konstant ABSPATH pole määratletud (mis peaks olema mis tahes WordPressi installi jaoks), siis skript väljub ja ei prindi midagi.

Kasuta Nonces: nagu on öeldud WordPressis dokumentatsioon , nonce on „üks kord kasutatud number”, mis aitab kaitsta URL-e ja vorme teatud tüüpi väärkasutuse, pahatahtliku või muul viisil.

Näiteks kasutatakse postituse prügikastis järgmist armatuurlaua URL-i: img/back-end/16/12-worst-mistakes-advanced-wordpress-developers-make.jpg - sellele URL-ile juurdepääsemisel kinnitab WordPress autentimisküpsise teavet ja kui teil on õige luba (nt olete administraator kõik privileegid), see postitus kustutatakse.

Ründaja saab teha, kui teha teie brauserile juurdepääs sellele URL-ile ilma teie teadmata, koostades kolmanda osapoole lehele lingi, nagu järgmises näites: Selle taotluse WordPressile esitamisel lisab brauser automaatselt teie autentimisküpsise ja WordPress peab seda taotlust kehtivaks.

Siis tuleb kasutusele nonce, kuna ründaja ei saa nonce väärtust (loodud administraatorile, kes on tegelikult sisse logitud WordPressi) nii lihtsalt. Uus päringu URL näeks välja selline: img/back-end/16/12-worst-mistakes-advanced-wordpress-developers-make.jpg&_wpnonce=b192fc4204

Ilma kehtiva vorminguta saadaks WordPress brauserisse 403 Keelatud vastuse koos teadaoleva veateatega: 'Kas olete kindel, et soovite seda teha?'

Kuigi enamik inimesi ei võta WordPressi turvalisust tõsiselt, mõeldes, et nende veebisaiti ei hakataks kunagi häkkima, usaldades hostimist (mis võib olla kasulik, kuid ainult teatud punktini) ja asjaolu, et nad ostsid kommertspluginaid / teemasid (mis viivad sageli eeldusel, et need on väga turvalised), peaksime alati tegema oma veebisaitidele läbitungimiskatseid, et tuvastada kasutatavad haavatavused enne, kui mõni häkker suudab neid tuvastada ja ära kasutada.

Pange tähele, et suurt hulka sealseid häkkimisi ei tee isegi üks inimene kavatsusega spetsiaalselt teie veebisaiti häkkida. Sageli leidub roboteid, mis skannivad WordPressi veebisaite järjepidevalt ja kui teadaolev haavatavus leitakse, kasutatakse seda ära ja serverit kasutatakse rämpspostitamiseks, andmebaasist privaatse teabe hankimiseks, peidetud linkide paigutamiseks veebisaidi teatud lehtedele. viiks igasuguste kohmakate veebisaitideni (nt pornograafia, keelatud uimastid). Mõnikord on häkid peidetud nii hästi, et peate häkkinud koodi tuvastamiseks oma veebisaidi korralikult skannima ja nägema kuupäeva, millal konkreetseid faile värskendati. Sellepärast on hea isegi WordPress uuesti installida (jah, sama versioon, kui teil on viimane), nii et kõik häkkitud failid kirjutaksid üle ehtsad WordPressi tuumfailid.

12. WordPressi funktsioonide ja koodijuppide kasutamine neid mõistmata

Sageli, kui arendajad takerduvad ja leiavad lahenduse nagu StackOverflow, on nad lihtsalt rahul sellega, et neil õnnestus midagi korda saata, ilma et vaevuksite aru saada selle koodi taga olevast loogikast või kui seda koodi saab muuta laadimiseks kiiremini või vähem koodiread.

Olen seda praktikat nii palju kordi näinud, kui koodijuppe kopeeritakse PHP-skriptidesse, kui tegelikult kasutatakse ainult kolmandikku sellest koodist.

Sellel võib olla mõni puudus, sealhulgas:

1. Kood ei kasuta sama stiili kui olemasolev projekti kood. Jah, mugav on lihtsalt karbist välja töötavaid juppe kopeerida ja kleepida ning ehkki need sobivad väikese isikliku projekti jaoks (see võib kunagi suureks projektiks muutuda, kes teab), pole see tava sageli hea, kui see tuleb kommertstööde juurde, kus tuleb hoida stiilis järjepidevust.
2. Ehkki kood teeb oma tööd, võib see sisaldada ebaefektiivseid funktsioone, mida ei soovitata täita vajava ülesande jaoks. Kui koodi pole optimeeritud, võib selline kopeerimise ja kleepimise praktika viia aeglase ja raskemini hooldatava veebisaidini, eriti kui projekti erinevates kohtades kasutatakse rohkem kui ühte juppi.
3. Koodil ei pruugi olla korduvkasutuseks litsentsi ja koodi lisamine kliendi projekti võib avada neile palju juriidilisi probleeme.

Pidev täiustamine

Kõik teevad vigu ja iga viga on võimalus ennast parandada. As WordPressi arendajad , meie tööstus liigub väga kiires tempos ja kunagi pole ühtegi õiget viisi, kuidas asju teha. Mida rohkem aga harjutate ja õpite, seda paremaks muutute.

Kas te ei nõustu mõne veaga, millele osutasin, või arvate, et jätsin ühe vahele? Andke mulle kommentaarides teada ja arutame.

Seotud: Minu viis halvimat WordPressi arendusviga