Opprette egendefinerte WordPress-administrasjonssider, del 1

I en tidligere serie ga jeg en grundig veiledning for å jobbe med WordPress Settings API. For de som er nye til WordPress eller som har brukt andre verktøy som Customizer til å håndtere ulike alternativer, kan det være noe du ikke har hatt å bruke i temaet eller plugin-utviklingen.

Som angitt i Codex:

Innstillings-API, lagt til i WordPress 2.7, tillater administratorsider som inneholder innstillingsskjemaer som skal administreres semi-automatisk. Den lar deg definere innstillingssider, seksjoner i de sidene og feltene i seksjonene.

Jeg tror ikke det er noe som er nødvendig å lære, men det er noe du burde vite eksisterer og vet hvordan du skal jobbe med det hvis du finner deg selv nødt til å introdusere opsjons sider i WordPress administrasjonsområdet.

Det er en kraftig, men litt kompleks, API som gir oss mye funksjonalitet. I siste instans tillater det oss å gjøre mye arbeid på serversiden og minimal arbeid på klientsiden.

Men hva med tider når vi jobber med en tilpasset løsning for kunder, og vi trenger litt mer fleksibilitet enn Innstillinger API gir? For eksempel, si at vi må bygge et plugin som vil ha en innstillingsside, men trenger et mer fleksibelt sett med alternativer og skreddersydd valideringsfunksjonalitet?

I disse tilfellene er det mulig å skrive våre egne tilpassede WordPress-administrasjons sider. I denne serien skal vi se på hvordan du gjør akkurat det.

Før vi begynner

Som med de fleste opplæringsprogrammer som dette, er det viktig å sørge for at du har alt på plass for å følge sammen slik at du kan jobbe med kildekoden som vi dekker gjennom serien.

For denne opplæringen antar jeg:

• Du har et lokalt utviklingsmiljøoppsett i forhold til operativsystemet ditt.
• Du har en kopi av WordPress installert og klar til å bli brukt til å installere et plugin.
• Du er kjent med WordPress plugin-utviklingspraksis.
• Du er komfortabel med å arbeide med PHP og HTML.

Hvis du ikke er kjent med hvordan du konfigurerer et lokalt utviklingsmiljø som inkluderer WordPress, kan du se denne serien for hvordan du gjør det. 

Og hvis du er relativt komfortabel med PHP, selv om det bare leser språket, så vil jeg gjøre det beste jeg kan for å gi klare instruksjoner og kommentarer for hver bit kode som vi deler.

Når alt dette er på plass, er vi klare til å begynne å jobbe med pluginet vårt.

Tilpassede innstillinger for WordPress Administrasjon

Ved slutten av denne serien skal vi ha et plugin som oppfyller følgende krav:

• Legger til et nytt undermenyelement til det eksisterende WordPress menysystemet.
• Legger til en ny innstillingsside som tilsvarer det nye undermenyelementet.
• Sanitiserer og serialiserer alternativer på siden.
• Validerer og returnerer verdiene som ble lagret og gjør dem tilsvarende.

Videre sikrer vi at vi nærmer oss dette på den mest modulære måten ved hjelp av WordPress-kodingsstandarder og lignende fremgangsmåter for å gjøre lesing, skriving og vedlikehold av plugin så enkelt som mulig.

1. Plugin Bootstrap

Det første vi må gjøre er å lage plugin bootstrap. Dette vil inkludere å lage en katalog for å huse pluginens filer, en grunnleggende README, en kopi av lisensen, en bootstrap-fil som til slutt vil bli brukt til å starte pluginet, og en katalog som vil bli brukt til å holde klassene relatert til administrativ funksjonalitet.

Filene er tilgjengelige for nedlasting som et vedlegg til dette innlegget, men i mellomtiden kan du se hvordan katalogen min ser ut nedenfor:

Videre er innholdet i plugin bootstrap enkelt. Gå gjennom følgende kode for den enkle PHP-filen custom-admin-settings.php, og så skal jeg diskutere det nærmere under blokken.

Legg merke til at i koden ovenfor er det faktisk veldig lite kode. I stedet er det mange kommentarer. Hovedblokken med kommentarer øverst i filen forklarer hva filen gjør.
Området under @ Wordpress-plugin tag er hva WordPress vil lese for å generere pluginens tittel, beskrivelse og relative lenker i pluginpanelet i WordPress.
Deretter hindrer vi at noen får tilgang til filen direkte. Og til slutt lager vi en tilpasset funksjon som skal avfyres med plugins_loaded kroken. Denne funksjonen er det som skal brukes til å starte plugin.
På dette tidspunktet bør du være i stand til å logge på WordPress, navigere til Plugin's Dashboard, og så se plugin tilgjengelig for å aktivere. Gå videre og klikk Aktiver.
Ingenting vil skje ennå, men vi begynner å legge til funksjonalitet som vi jobber gjennom denne opplæringen.
2. Opprette undermenyelementet
For å begynne å jobbe med pluginet, la oss først introdusere en undermenyelement. For å gjøre dette, må vi dra nytte av WordPress API-funksjonen add_options_page. Denne funksjonen krever fem parametere:
 
teksten som skal vises som tittel på den tilsvarende alternativsiden
 
teksten som skal vises som undermeny tekst for menyelementet
 
evnene som trengs for å få tilgang til dette menyelementet
 
menypunktet som brukes til å identifisere denne undermenyelementet
 
en tilbakeringing til en funksjon som er ansvarlig for å gjengi administrasjonssiden
 
Vær oppmerksom på at vi skal bruke klasser for å organisere funksjonaliteten, så mye av det vi gjør kommer til å være objektorientert.
La oss først lage en klasse i administrasjonskatalogen som heter klasse submenu.php. Siden denne klassen er ansvarlig for å introdusere en ny undermeny, får vi navnet det som beskrivende.
Innholdet i klassen skal se slik ut:
submenu_page = $ undermeny_page;  / ** * Legger til en undermeny for dette pluginet til 'Verktøy' -menyen. * / offentlig funksjon init () add_action ('admin_menu', array ($ dette, 'add_options_page'));  / ** * Oppretter undermenyelementet og ringer på undermenyen Sidobjekt for å gjengi * det faktiske innholdet på siden. * / offentlig funksjon add_options_page () add_options_page ('Tuts + Tilpasset administrasjonsside', 'Tilpasset administrasjonsside', 'manage_options', 'custom-admin-side', array ($ this-> submenu_page, 'render'));  
På dette tidspunktet vil pluggen fortsatt ikke gjøre noe. Vi må fortsatt lage den faktiske Submenu_Page klassen, og da må vi føre klassene opp til oppstartsfilen.
3. Opprette undermenyen
La oss begynne med Submenu_Page klasse først. Opprett en annen fil i admin katalog og ring det klasse-undermeny-page.php. Deretter legger du til følgende kode i filen.
Når denne siden gjøres, vil den bare vise teksten: "Dette er den grunnleggende undermeny siden." Vi kommer til slutt inn i å legge til nye alternativer. Men først, la oss få denne pluginen til liv ved å instantiere den i vår bootstrap-fil.
4. Gjenopprette menyen og siden
Deretter åpner du egendefinert admin-settings.php-filen som vi opprettet tidligere i denne opplæringen. La oss gå videre og skriv koden som er nødvendig for å introdusere det nye undermenyelementet og tilhørende side.
Husk at undermeny-klassen krever at en forekomst av Submenu_Page klassen sendes inn i sin konstruktør, og da må vi ringe init-metoden i undermeny-klassen for å sette hele greia inn i bevegelse.
I kode ser dette ut som følgende:
i det(); 
På dette tidspunktet bør du kunne oppdatere installasjonen av WordPress, aktivere pluginet (hvis det ikke allerede er aktivert), og så se den nye siden gjengitt i administrasjonsområdet.
I neste artikkel ser vi på hvordan vi kan begynne å introdusere de faktiske innstillingene i skjermen. I tillegg vil vi se på noen gode fremgangsmåter når det gjelder å arbeide med vår mal og våre delpartier, og så ser vi hvordan de skal kobles til APIene som er ansvarlige for ikke bare å lagre dem, men hvordan vi vil sanere og validere dem.
Men før vi går så langt, vil jeg snakke litt om klassedesignet som vi har sett i denne opplæringen. Vanligvis vil jeg snakke om hvorfor vi har en klasse for undermeny og Submenu_Page og hvordan det handler om bootstrap-filen.
Et ord på klassenes ansvar
For de av dere som er kjent med prinsippet om enkelt ansvar, kan dette avsnittet ikke være av interesse for deg. Men hvis hvem trenger en oppdatering eller vil høre mer, så les videre.
Samle sammen de tingene som endres av samme grunner. Separat de tingene som endres av forskjellige grunner.
Det er mye mer til dette, men hvis du skulle se på hver av våre klasser (minst de to vi har så langt), så er det klart at årsakene våre klasser kan endres er som følger:
 
Innholdet i undermenyen kan endres. Alt fra siden tittelen til menyen slug og alt i mellom.
 
 Måten siden gjør innholdet kan (og vil endre seg). Spesielt, akkurat nå gjør det ingenting annet enn ekko en streng. Snart vil det inneholde en bestemt fil. Etter det kan det være nødvendig å inkludere flere filer.
 
Ovennevnte to grunner er to svært forskjellige grunner til at klassene kan endres, så det vil være i strid med ovenstående prinsipp at de holder sammen i samme klasse.
Til slutt bringer jeg opp dette ikke bare for å hjelpe til med å kaste lys på større programvare engineering prinsipper som kan brukes i WordPress, men også for å forberede deg på noen av grunnene til at vi skal bryte fra enkelte ting som vanligvis er store filer innenfor rammen av plugins.
Det fine med å lære prinsipper er at de kan brukes i flere prosjekter og ikke bare i enkeltprosjekter. Du lærer dem, du trener med å bruke dem, og du blir bedre på arkitekturløsninger for andre mennesker. 
Læringskurven kan være bratt, men når du begynner oppoverbakken, blir det enklere og enklere å innlemme prinsippene i det daglige arbeidet. Deretter blir arbeidet du gir for andre, mye lettere å opprettholde over tid.
Konklusjon
Ikke glem at du kan laste ned pluginet i sin nåværende tilstand fra dette innlegget. Når vi går gjennom serien, vil jeg gjøre den nyeste versjonen tilgjengelig på hvert innlegg slik at du vil kunne følge med koden som er dekket i hver veiledning, tinker med den og forberede spørsmål som du kanskje vil spørre i kommentarene.
Som en side notat, hvis du leter etter andre verktøy for å hjelpe deg med å bygge ut ditt voksende sett med verktøy for WordPress eller for å kodes for å studere og bli mer kjent med WordPress, ikke glem å se hva vi har tilgjengelig i Envato Market.
Husk at du kan fange alle mine kurs og opplæringsprogrammer på min profilside, og du kan følge meg på bloggen min og / eller Twitter på @tommcfarlin hvor jeg snakker om ulike programvareutviklingspraksis og hvordan vi kan bruke dem i WordPress.
Til slutt, ikke nøl med å legge igjen noen spørsmål eller kommentarer i feedet under. Jeg gjør mitt beste for å delta og svare på alle spørsmål eller kritikk du tilbyr som det gjelder dette prosjektet.
ressurser
 
Den komplette guiden til WordPress Settings API
 
Innstillings-API
 
plugins_loaded
 
add_options_page
 
Enkelt ansvar prinsipp
 



		
			
	   
	




Kode