Share
Med WordPress blir mer og mer populært, er det en enorm mengde kode som blir generert av brukere, byråer og markedsplasser. Jeg har jobbet med WordPress i lang tid, og det amazes meg hvor mange utviklere der ute gjør de samme feilene igjen og igjen.
Jeg skal gå gjennom noen av de vanligste utviklingsfeilene og hvordan du enkelt kan fikse dem, og fremover gjør koden din bedre!
Hvis du gjør et Google-søk etter "WordPress", returnerer det 1,9 milliarder resultater. Det er millioner av nettsteder med kodeeksempler, opplæringsprogrammer og utdrag som kommer i svært nyttig som en WordPress-utvikler. Problemet er 2 ganger:
Så som en ny WordPress-utvikler gjør du et Google-søk, finn en artikkel, kopier og lim inn koden, og den fungerer! Strålende du sier til deg selv, og du husker eller bokmerker koden. Det store problemet her er at koden kanskje ikke er perfekt, men du er ny, så du vil ikke legge merke til det. Som det fungerer kan du bare fortsette å bruke det for alltid.
La oss begynne på hvordan du kan unngå noen vanlige feil!
WordPress selv innrømmer at enkelte deler av WordPress-kode strukturen for PHP-oppslag er inkonsekvent i deres stil (deres eksakte ord). De jobber gjennom for å rydde opp koden og gjøre den konsistent og har satt ut en standard for ALL WordPress-koden. Det spiller ingen rolle om det er et plugin eller et tema de alle bør følge de samme standardene.
WordPress-kodingsstandarder
Hvis du aldri har lest denne siden før lese det! Dette bør være en av de første stedene som en utvikler jobber med WordPress-besøk. Jeg kommer ikke til å gå gjennom punktene her, men du bør ta deg tid til å gå gjennom og lese den.
Jeg er selv skyldig i å bryte et par av disse reglene, men den virkelige nøkkelen er konsistens. Den ene regelen jeg bryter, jeg bryter hele tiden. Personlig når du arbeider med hvis uttalelser Jeg foretrekker å bruke alternativ syntaks for kontrollstrukturer. For meg er de lettere å lese. Ved å være konsekvent gjennom hele koden min, kan folk se umiddelbart, jeg gjør noe annerledes og følger meg gjennom koden min.
Huske: Konsistens- og kodingsstandarder virkelig gjør en lang vei for å få koden din til å se og lese bedre!
I den forrige delen vi så på WordPress Coding Standards, er dette dokumentet funnet i den mest nyttige utviklingsressursen for WordPress-utviklere. The WordPress Codex. Tilgjengelig på nesten 50 språk er Codex utviklerens bibel. Den inneholder dokumentasjon på nesten hver eneste funksjon, klasse og variabel innen WordPress, hvordan du bruker dem og kodeeksempler. Jeg har vanligvis 3 eller 4 faner åpne på kodeksen til enhver tid, faktisk i øyeblikket har jeg 4 åpne! Det spiller ingen rolle om du er ny til WordPress eller har jobbet med det i mange år, dokumentasjonen her er uvurderlig.
The beauty of Codex er at det er et levende, pustende samfunn for dokumentasjon. Du kan bidra med din egen kunnskap for å gjøre det bedre, eller legge til en side hvis den mangler, husk bare om du legger til noen kode for å følge WordPress Coding Standards!
Mitt største råd til Codex er å søke! Som med et Wiki-basert nettsted, er navigasjonen litt vanskelig og har ikke nødvendigvis noen mening først. Det innebygde søket skal hjelpe deg med å finne det du leter etter. Hvis du sliter med å finne det du leter etter, hopper du inn i #WordPress IRC-kanalen, det er vanligvis noen få folk der inne som vil peke deg til den riktige Codex-siden.
Så nå vet vi om kodingsstandarder og hvor du får den riktige dokumentasjonen, og hjelper oss med å se på noen av kodene dine.
Hallo
Ovennevnte kutt er de typiske første linjene i de fleste WordPress-temaer, men det bør ikke være. Skript og stiler kan håndteres så mye bedre med WordPress, og de gir oss noen flotte funksjoner for å jobbe med dem. Nå snakker jeg her om temaer, men noen plugin som trenger skript eller stiler, skal gjøre ting akkurat på samme måte. Vi presenterer wp_enqueue_style () og wp_enqueue_script ()! Hvis du ikke vet hva disse funksjonene gjør så må vi fikse det! La oss gå gjennom det du trenger å gjøre.
Uansett om det er et skript eller en stil, er det best å la WordPress vite om det. Vi gjør dette ved å bruke wp_register_script () eller wp_register_style (). Disse er begge de sikre måtene å registrere et skript eller en stil med WordPress, slik at du kan bruke dem senere. Nå gir denne funksjonen ikke noe til ditt tema eller nettsted, det forbereder bare WordPress for å bruke dem.
$ håndtak (Påkrevd) Dette er din navnet på stilarket eller skriptet. Dette kan være alt du liker så lenge det er unikt. Du kan alltid prefikse navnet for å unngå konflikter.
$ src (Påkrevd) Dette er nettadressen til stilarket eller skriptet. Det kan enten være eksternt eller internt på nettstedet ditt, avhengig av hva du gjør. Eksternt er nyttig hvis du bruker en tredje partitype-tjeneste som Type Kit eller Google Fonts eller for Social Media Javascript. Du burde aldri hardkod nettadressen for lokale stilark eller skript, det finnes riktige funksjoner du kan bruke til dette som vi vil diskutere senere.
$ deps (Valgfri) Dette er en veldig nyttig en, selv om den er valgfri. Dette lar deg angi en rekke avhengigheter for skriptet eller stilarket. Det vil også da sikre at de avhengige er lastet før skriptet eller stilen er.
$ ver (Valgfri) Her får du angi skriptet eller stilversjonsnummeret, hvis det har en. Dette er nyttig for å sikre at den riktige versjonen sendes til brukerens nettleser, uavhengig av caching. Selvfølgelig kan du sette dine egne versjonsnumre for dine egne skript og stilarter, eller du kan bruke et fint lite triks for å få dynamiske versjonsnumre.
$ in_footer (Valgfritt, kun skript) Normalt er skript plassert i men hvis du setter denne parameteren til sann, vil skriptet plasseres nederst på . Hvis du vil sende ut i footeren, må du sørge for at temaet ditt har wp_footer () hek på riktig sted.
$ media (Valgfritt, bare stil) Dette kan være en streng for å angi media som stilarket er definert for. (F.eks. 'alle', 'skjerm', 'Håndholdt', 'skrive ut').
La oss sette det sammen i et godt eksempel:
Veldig kort, vi har et JavaScript vi ringer fra vår temamappe, det er avhengig av jQuery, satt til versjon 1 og vi vil sende ut på slutten av siden vår. Også har vi vår style.css som vi ringer fra vår temamappe, den har ingen avhengighet, er versjon 1.0 og er for skjerm. Det er også viktig å huske at vi faktisk må gjennomføre disse skriptene ved å bruke en handlingskrog. I dette tilfellet bruker vi wp_enqueue_scripts som vår handling krog som anbefalt av Codex.
Det er veldig enkelt når du får tak i det og blir vant til å gjøre det!
Nå har vi registrert våre skript og stiler WordPress vet alt om dem og nå kan vi begynne å bruke dem. Kommer tilbake til vår wp_enqueue_script () og wp_enqueue_style () Vi kan nå kalkulere stiler og skript som vi registrerte i forrige trinn. Enqueue-skript og stilfunksjoner fungerer på samme måte som registerfunksjonene. Den store forskjellen er at WordPress vil nå utføre JavaScript eller stilen til siden den genererer.
Fordi vi allerede har registrert våre skript og stiler, er de enkle å gjøre. Skjønnheten i dette er at vi kan betinget enqueue våre skript og stiler, slik at vi bare laster dem på sidene de trengs på. Også som de blir kalt i samme handlingskrok, kan du gjøre alt i en funksjon. Ta en titt på eksemplet nedenfor:
Så vi har registrert våre stiler og skript på riktig måte og har krevd dem. Vi har også bare et skript og en stil som er enqueued på vår hjemmeside ved hjelp av en betinget uttalelse.
Dette er et perfekt eksempel på en av de største feilene jeg ser når man ser på temaer eller plugins skrevet av andre. Ved å lære et par enkle WordPress-funksjoner kan du laste inn stiler og skript på en sikker måte og sørge for at alle avhengighetene er på plass. Også hvis noen bruker et plugin du har skrevet, er det enkelt for dem å gjøre endringer uten at de slettes ut av oppdateringer. Alt de trenger å gjøre er å kopiere CSS til temaet deres, og de kan registrere seg og registrere seg selv!
Du kan se en full opplæring om hvordan du bruker disse funksjonene i bunnen av denne opplæringen.
Hvis du noen gang har satt dette i temaet ditt, plugin eller noe å gjøre med WordPress, drepte du bare en kattunge. Vi har allerede diskutert betydningen av å registrere og enqueueing dine skript og stiler, så hvorfor angre alt ditt harde arbeid. WordPress kommer med mange skript for deg å bruke bare ved å enqueuing dem. Selvfølgelig kan du, selv når du gjør ting riktig, avregistrere den bundlede versjonen av et skript og registrere din egen versjon. Som ovenfor kan vi kanskje bruke Google CDN-versjonen. Dette er greit hvis du jobber på ditt eget nettsted, ditt eget private tema eller plugin, og du kommer ikke til å slippe ut det. Men hvis du offentliggjør koden din offentlig hold deg til de medfølgende bibliotekene. Andre plugins kan bryte, temaer kan slutte å fungere alt fordi ingen følger reglene. Jeg finner ofte nettsteder med 3 eller 4 forskjellige versjoner av jQuery lastet opp rett og slett fordi folk ikke registrerer og enqueuing riktig eller noen plugin forfatter vil bruke en annen versjon av noe.
La oss gjøre hverandre en tjeneste og følge noen standarder!
Advarsel: Plugins eller temaer som bruker et bibliotek som ikke er bundet, vil bli avvist hvis de sendes til både ThemeForest og WordPress.org-depotet!
Nå er det også viktig å snakke om jQuery. Det er massivt, alle bruker det, temaer elsker det og plugins elsker det. Det kan imidlertid føre til problemer dersom det ikke brukes riktig. JQuery-biblioteket buntet med WordPress laster i "no conflict" -modus. Dette gjør det mulig å jobbe langs siden av de andre bibliotekene som WordPress kan bruke. Men i ingen konfliktmodus $ snarvei virker ikke og har blitt erstattet med litt lenger jQuery.
$ (dokument) .ready (funksjon () $ (# myfuntion) ...);
Ovennevnte må skrives om på nytt, den enkleste måten er å bruke følgende omslag:
jQuery (dokument) .ready (funksjon ($) $ (# myfunction) // Nå $ () fungerer som et alias for jQuery () i denne funksjonen!);
Problemet med å laste inn en ekstern versjon av jQuery er at den ikke kan lastes i ikke-konfliktmodus, den kan bryte andre skript og forfatteren kan ha skrevet JavaScript uten å følge reglene ovenfor. Dette betyr at alle bryter når du prøver å bruke den medfølgende jQuery-versjonen! Prøv alltid å bruke de samlede bibliotekene og skriv alltid JavaScript / jQuery i no-conflict modus!
Du kan få mer informasjon om WordPress og jQuery på Codex-siden.
Hvordan får du temakatalogbanen din? Hvordan leder du folk til hjemmesiden til nettstedet? Mange utviklere vet fortsatt ikke hvordan å gjøre noen grunnleggende ting med WordPress. Jeg kommer til å trekke ut noen av de vanligste.
Accentsconagua
TEMPLATEPATH eller bloginfo ('template_directory'). Stoppe! Du bør bruke det veldig nyttige get_template_directory () som vist i eksemplene ovenfor. Det er faktisk 4 variasjoner av denne funksjonen:
get_template_directory () returnerer PATH til temamappen din. Nyttig for bruk inne i PHP-funksjoner eller inkluderer.get_template_directory_uri () returnerer nettadressen til temamappen din. Nyttig for enqueueing og registrering av skript og stiler, og hvis du vil inkludere og bilde.get_stylesheet_directory () returnerer PATH til stilarkmappen. Dette vil alltid peke på Barnemnet hvis man er i bruk mens get_template_directory () vil alltid peke på foreldetemaet.get_stylesheet_directory_uri () returnerer nettadressen til stilarkmappen. Som med ovennevnte vil dette alltid peke på Barnemnet hvis man er i bruk.Pass på at du bruker riktig funksjon. Hvis du forventer at brukere overstyrer temaet ditt i et barntema, er det best å bruke den riktige funksjonen.
plugin_dir_url () returnerer nettadressen til pluginfilen som er sendt inn.plugin_dir_path () returnerer katalogbanen til pluginfilen som er sendt inn.Med plugins finner jeg alltid det enklere å definere en konstant rett ved starten og bruke det gjennom hele pluginet mitt.
bloginfo (). Eksempelet nedenfor gir et veldig grunnleggende eksempel på hvordan du gjør det riktig. "> Dette er en lenke til vår hjemmeside
Hvis du er i tvil om noe så les Codex det hjelper virkelig! Ved å bruke de riktige funksjonene for å få deg rundt WordPress, gjør du det mye mer sannsynlig at plugin eller tema ikke vil kollidere eller forstyrre andres kode. Det er ikke noe mer frustrerende enn å forsøke å feilsøke en feil i din egen kode bare for å finne at det er et annet plugin som ødelegger alt annet!
Dette har vært et snakkepunkt blant samfunnet i mange aldre. Skal jeg sette funksjonaliteten mitt i temaet eller i et plugin? Jeg finner alltid at det enkle svaret er dette: Fungerer funksjonaliteten din hvis du bruker et annet tema? Hva jeg mener her er om du legger til ekstra funksjonalitet, kanskje en egendefinert innleggstype eller en tilpasset lysboksseffekt for bilder, vil den fungere med noe tema eller kan det fungere med noe tema? Det er ingenting verre enn å bruke aldre å sette opp et nettsted med masse nydelige egendefinerte innleggstyper, og legger masse innhold bare for å finne at du endrer tema og alt forsvinner bare.
Jeg følger vanligvis denne enkle regelen, hvis det kan være en plugin, gjør den til en. Temaer er ment å spesifikt håndtere den visuelle stilen til et nettsted, ikke funksjonaliteten. Plugins er for funksjonalitet. Nå hvis pluginet ditt skriver ut noe, som de fleste av dem er, kan du enkelt sjekke ditt aktive tema for de nødvendige malfilene og komme tilbake til pluginens malfiler hvis det er nødvendig. Faktisk kommer mine plugins i de fleste tilfeller som dette. I det minste gir du brukeren muligheten til å endre måten den ser ut uten å miste endringene hvis du publiserer en oppdatering. Jeg vil prøve å dekke dette i en fremtidig opplæring, men leksjonen her er å holde det enkelt. Ved å bryte funksjonaliteten din opp i fine bite-størrelse biter gir brukeren valget, hvis de ikke liker dine sosiale deling knapper, la dem slå dem av eller erstatte dem med sine egne. Flere plugins, mindre altfor kompliserte temaalternativer sider!
Dette er et annet poeng som jeg ønsket å heve veldig kort som jeg vet det er noen gode opplæringsprogrammer der ute på Handlinger og Filtre (en er koblet nederst for deg). Uansett hvilken type WordPress-utvikling du gjør, lær om handlinger og filtre. Dette er en av de største feilene jeg ser folk gjør. WordPress har en flott API for tema og plugin utvikling, og du kan gjøre din utvikling mye bedre ved å bruke verktøyene som WordPress legger ut der for deg. De beste plugins der ute gjør omfattende bruk av handlinger og filtre, slik at hvis du vil tilpasse hvordan det fungerer for deg, er det enkelt.
Et eksempel på dette er WooCommerce fra WooThemes. Nå, mens jeg ikke er en fan av de massive temaalternativer panelene de legger inn i deres temaer, har WooCommerce blitt bygget med andre utviklere i tankene. Nesten alt kan tilpasses eller overstyres ved ganske enkelt å fjerne handlinger eller erstatte dem. Deres handling og filterreferanse er omfattende og lar deg jobbe langs siden det akkurat slik du vil. Nå forventer jeg ikke at du skal gå i den grad for dine egne prosjekter, men vi kan lære viktige leksjoner her. Hvis koden din er enkel å tilpasse uten å hacking den til biter, er det mer sannsynlig at folk bruker den, vurderer den og anbefaler den!
Handlinger og filtre er en av de viktigste tingene du bør lære om WordPress-utvikling, ta litt tid og du kommer dit!
Vi har dekket mye i denne artikkelen, og jeg håper det var i bruk. Jeg vil bare bryte den ned enda lenger for deg:
Når du kopierer og limer inn den koden du fant fra Google, tar du et minutt for å se på det, forstå det og prøv å bruke ovenstående til det. Følger det kodningsstandardene? Bruker den riktige funksjonene? Hva gjør jQuery? Du er bare 1 tema eller plugin unna alle disse punktene blir den andre naturen. Neste gang du ser en feil, prøv å fikse det!
Relaterte innlegg