Opprett Vedlikeholdbare WordPress Meta Bokser

Akkurat nå, et av de vanligste designmønstrene - hvis ikke de mest vanlige designmønster - ansatt i webutvikling, er MVC (eller modell / visning / kontrollør), men så populært som det er det ikke den eneste måten rammeverk, stiftelser og andre biblioteker er bygget på.

Case in point: WordPress bruker det hendelse-drevne designmønsteret for å koble kroksystemet. Og selv om designmønstre ikke er gjensidig, er du mer sannsynlig å gjenkjenne at spesielt mønster fordi det er det som gjør WordPress så fleksibelt som det er.

For å være tydelig betyr dette ikke at andre mønstre ikke er i bruk gjennom sin kodebase (eller et annet programs kodebase), de kan bare ikke være like lett gjenkjennelige.

Utover det er en av de tingene som profesjonelle utviklere strever etter, å skrive vedlikeholdsbar kode. Men som en kodebase aldre og flere og flere mennesker får sitt arbeid i kodebase blir det stadig vanskeligere å holde samme nivå av organisasjon, klarhet og vedlikehold som konsistent som et prosjekt aldre.

Alle de ovennevnte ideene gjelder for WordPress om du jobber med temaer, plugins, utvidelser eller en annen type prosjekt. Saken er, det er viktig å sørge for at du følger kodningsstandarder og konvensjoner som er angitt for å skape disse prosjektene.

La oss si at du jobber med et plugin som introduserer en tilpasset meta-boks; Det er imidlertid ikke nok å introdusere en meta-boks. I stedet skal det opprettes grupper av relaterte alternativer.

Dette er hvor det begynner å bli litt mer utfordrende. Gjennom hele denne serien skal vi ta på en måte at vi kan skrive vedlikeholdsbar kode i WordPress gjennom et eksempel-plugin som introduserer meta-bokser, forskjellige alternativer og tabbed navigering i WordPress dashboard.

Organisering av Meta Bokser

Når du er i ferd med å planlegge hvordan du planlegger alternativene for meta-boksene dine, har du et par alternativer som er tilgjengelige:

1. Innfør en enkelt meta-boks per opsjon
2. Innfør en enkelt meta-boks med faner som logisk grupperer hver enkelt opsjon

For de som har brukt WordPress for en lang tid, så er du sannsynligvis kjent med å se flippert navigasjon i dashbordet i det minste i noen kapasitet. For de som er nysgjerrige som hvordan å implementere dette ikke bare programmatisk, men i en vedlikeholds måte, vi skal se på hvordan du gjør dette gjennom denne serien.

Spesielt skal vi skrive et lite WordPress-plugin som introduserer noen få felt, relaterte alternativer som er gruppert av faner, og så skal vi introdusere noen flere elementer for å vise hvordan det skal være riktig og sikkert, lagre, sanitere, og hent dataene.

Hvor vi er på vei

Som med flertallet av innleggene i serie som jeg skriver, liker jeg å prøve å skissere hva vi skal gjøre på et høyt nivå før vi faktisk hopper inn i kode. Dette bidrar til å gi et konseptbasert grunnlag av hvor vi er på vei og bidrar til å skissere den kommende serien av artikler så vel som hva vi skal gjøre på kodenivå.

Hvis ikke noe annet, gir det et sted å referere til som vi fortsetter å utvikle seg gjennom serien.

Før jeg ser på omrisset, er det jeg vil nevne at den viktigste uttaket av denne spesifikke artikkelen kommer til å merke seg at det er separasjon av bekymringer så vel som Hvorfor Vi har valgt å gjøre ting som vi har gjort, slik at vi forstår hvordan det hjelper med vedlikehold.

For det formål, her er det vi ser på over de neste artiklene:

1. Legger grunnlaget for plugin
2. Definerer alle alternativene og organiserer dem i faner
3. Ren implementering av hver av alternativene og fanene sammen med sikkerhetstiltak
4. Ser alt i aksjon

Som med alt i utvikling, er det helt nøkkelt å bryte ting ned i flere mindre komponenter, så resten av dette innlegget skal vi se på trinnene som trengs for at vi skal begynne å jobbe med et plugin som introduserer en meta-boks inn i standard 'Post' posttype.

Plugins skjelett

Før du går videre, la oss sette opp vår plugin-katalog. Dette bør inneholde følgende:

• En fil for å bootstrap plugin
  
• Den viktigste plugin-klassen
• Forståelse av hvordan de opprinnelige filene er organisert
• Et tomt README

Og selvfølgelig bør vi sørge for at katalogene er godt organisert og at koden er tydelig.

For å gjøre dette i det minste noe praktisk, skal vi kalle dette pluginet "Forfatterens kommentar", som gir oss mulighet til å dele noen få ærlige notater om hva vi trodde, brukt og kuttet ned mens du skrev innlegget. 

Vi kan velge å gjøre det offentlig i et fremtidig innlegg basert på tilbakemelding, men for nå planlegger vi bare å la det stå i backend.

Med det sagt, la oss komme i gang.

Komme i gang med Forfatterens kommentar

Klargjør Katalog

Det som vi trenger å gjøre er å stubbe ut katalogen struktur som vi skal bruke for prosjektet. Du får se et skjermbilde for dette under, og deretter beskriver jeg formålet med hver katalog.

Roten til katalogen inneholder to filer:

1. README.md som er standarden README som følger med et WordPress-plugin.
2. Forfatterne-commentary.php som er ansvarlig for faktisk å starte plugin. Dette er bootstrap-filen.

Deretter har vi admin-katalogen. Denne katalogen inneholder:

1. eiendeler som inkluderer underkataloger for både våre JavaScript- og CSS-filer (vi bruker vanilje CSS i hele denne serien.
2. klasse-forfattere-commentary.php som kommer til å være den primære klassen enn encapsulates mye av vår funksjonalitet.
3. visninger som inkluderer en underkatalog som heter partials. De visninger katalogen vil være ansvarlig for å gjengi fanene og inkludere alt innholdet for hver kategori basert på den delvise. Det er det partials katalog inneholder innholdet for hver kategori.

Vær oppmerksom på at vi kan legge til flere kataloger for plugin-modulen når serien fortsetter. Det vil si at denne strukturen kan endres ved at vi sannsynligvis vil legge til eller til og med flytte litt innhold basert på hvordan pluginprosessen går, men dette er grunnstrukturen som vi trenger for å komme i gang. 

Lag filene

Siden vi har den grunnleggende katalogstrukturen lagt ut og de nødvendige filene på plass, er vi klare til å begynne å stikke ut noe av koden. Vær oppmerksom på at selv om pluginet vil fungere fra et aktiveringsperspektiv, vil det egentlig ikke gjøre noe før vi begynner å legge til kode i neste sett med artikler.

Med det sagt, vil vi fortsette og fylle ut filene som er nødvendige for å få plugin-programmet i WordPress dashboard.

Det første vi må gjøre er å fylle toppteksten til pluginet slik at den inneholder den nødvendige dokumentasjonsblokken for WordPress for å vise pluginet i dashbordet:

Den endelige betingelsen sørger for at hvis noen prøver å få tilgang til filen direkte, vil skriptet avbryte kjøringen.
Deretter må vi sørge for at kjernepluginfilen som vi startet ovenfor, er klar over den primære klassen vi opprettet i forrige trinn. For å gjøre dette trenger vi bare en enkel require_once uttalelse.
Men før vi ringer require_once, Vi trenger en fil som skal inkluderes, ikke sant? Til slutt, la oss hoppe inn i admin underkatalog og i klasse-forfatter-commentary.php klasse, legger vi til følgende kode.
Kommentarene er selvforklarende, men jeg vil sørge for å skissere alt som skjer etter at koden er fullført:
 * / klasse Author_Commentary_Admin / ** * IDen til denne plugin. * * @since 0.1.0 * @access private * @var streng $ navn IDen til denne plugin. * / privat $ navn; / ** * Versjonen av denne plugin. * * @since 0.1.0 * @access private * @var string $ versjon Den nåværende versjonen av denne plugin. * / privat $ versjon; / ** * Initialiser klassen og sett dens egenskaper. * * @since 0.1.0 * @var string $ name Navnet på denne plugin. * @var string $ version Versjonen av dette plugin. * / offentlig funksjon __construct ($ navn, $ versjon) $ this-> name = $ name; $ this-> version = $ version; 
Legg merke til at i koden ovenfor har alt vi egentlig har gjort - bortsett fra å gi dokumentasjon for vår klasse, egenskaper og konstruktør - er oppsett en konstruktør som aksepterer en $ name og a $ versjon parameter.
Disse vil være nyttige senere når vi importerer JavaScript-avhengigheter og stilark. For nå er dette alt vi trenger for å komme i gang.
Med det gjort, kan vi gå tilbake til Forfatterne-commentary.php og skriv koden for å starte pluginet.
Først skal vi bruke require_once å importere klassen som vi nettopp har opprettet:
Da skal vi sette opp en enkel funksjon og et funksjonsanrop for å avslutte prosessen:
Legg merke til at vi ikke definerer noen kroker i denne filen. Alt skal til slutt ligge i underpakken - dette hjelper oss å skille våre bekymringer mer effektivt og dermed gjøre koden mer vedlikeholdbar, og det gjør det mulig for oss å holde koden en objektorientert som mulig.
Legg merke til at dette definerer en enkel funksjon som, når den blir ringt så snart plugin er aktivert, oppretter en forekomst av Author_Commentary_Admin klasse etter å ha passert i det nødvendige $ name og $ versjon parametere.
Legg grunnlaget
På dette punktet har alt grunnlaget blitt lagt som vil hjelpe oss å gå videre med å jobbe med pluginet vårt. Du bør kunne laste ned filen fra GitHub, installere den i WordPress, og aktivere den.
Igjen, dette vil egentlig ikke vise noe, men det forbereder koden for arbeidet som vi skal begynne i neste artikkel.
Hvis du har spørsmål ovenfor koden ovenfor eller hvor serien er ledet, ikke nøl med å legge igjen en kommentar; ellers ser jeg frem til å se deg i neste avdrag.



		
			
	   
	




Kode