Share
En av de fineste tingene med moderne webapplikasjonsutviklingsrammer er at de gir en måte å generere virkelig rene ruter eller URL-ordninger på - det kartet til den konseptuelle modellen for hvordan applikasjonen er strukturert.
For eksempel, gitt noen type data-si, en Individuell-du kan kanskje utføre følgende handlinger:
Og så videre.
Avhengig av arten av søknaden din, kan du kanskje gjøre mer (for eksempel si, legg til en ektefelle), men i dette innleggets grunnlag er de grunnleggende CRUD-operasjonene nok til å demonstrere poenget.
For de av dere som har fulgt med, har vi tatt en titt på en rekke funksjoner som WordPress tilbyr som grunnlag for applikasjonsutvikling. Når du fortsetter denne diskusjonen, er det viktig at vi tar en titt på APIene som er tilgjengelige for oss, for å tilpasse WordPress 'omskrivningsregler.
Den gjennomsnittlige brukeren er sannsynligvis kjent med hvordan du endrer nettadresseskjemaet i WordPress-dashbordet - som vi kort vil diskutere for å sikre at vi alle er på samme side. Det er imidlertid langt flere muligheter tilgjengelig for de som forstår URL-omskrivning i WordPress.
Faktisk har vi muligheten til å konstruere URL-omskrivningsregler for å matche og utføre akkurat som de av moderne MVC-baserte rammer.
For å være sikker på at vi alle er på samme side, kan omskrivningsregler betraktes som måten et bestemt mønster matches mot webserveren for å hente data fra databasen.
For eksempel, i standard WordPress-installasjonen, er standard permalink-strukturen som denne:
http://domain.com/?p=123
Denne nettadressen inneholder en forespørselsstrengparameter, nemlig nøkkelverdierparet av p = 123 som, i sammenheng med WordPress, sier "hente innlegget med ID på 123".
Hvis du tar en dypere titt på alternativene på Permalink Innstillinger skjermen, ser du også en rekke alternativer:
Et annet eksempel på omskrivningsreglene som du sannsynligvis vil se er det som kalles "ganske permalinks" eller, som nevnt i WordPress dashboard, "Postnavn".
I dette formatet ser nettadressen slik ut:
http://domain.com/post-title/
Herfra kommer den forespurte nettadressen inn i web-serveren, og deretter, basert på et sett med regler, bestemmer ID-en for posten som har den tittelen og returnerer den til den forespørgende klienten (som ville være nettleseren).
Mellom disse to eksemplene er det et grunnleggende prinsipp i spill som viser nøyaktig hva omskrivningsregler er.
Kort sagt, omskrivningsregler definerer et sett med regler der i den innkommende nettadressen oversettes til et format som henter informasjon fra databasen til klienten.
Selvfølgelig reiser dette to spørsmål:
Årsaken til at omskrivningsregler kan tjene som en utfordring for utviklere, er fordi de er basert på regulære uttrykk. Og det er et gammelt sitat om regulære uttrykk av Jamie Zawinski:
Noen mennesker, når de konfronteres med et problem, tenk "Jeg vet, jeg skal bruke vanlige uttrykk." Nå har de to problemer.
Morsomt, men sant. Og det er hvorfor å håndtere tilpassede omskrivningsregler i WordPress kan være en utfordring for mange utviklere.
Dessverre kan vi ikke demonstrere alle variasjoner eller typer nettadresseskjemaer som kan opprettes eller støttes av omskrivningsregler, men vi kan se på noen få praktiske eksempler som viser hvordan du kommer i gang og gir et grunnlag eller en veiledning for hva vi trenger å gjøre i fremtidig arbeid med våre applikasjoner.
En ting som er viktig å merke seg er at når du definerer dine omskrivningsregler, vil de ikke umiddelbart få virkning - de har blitt spylt. Dette betyr at du må slette det gamle settet med regler, for å erstatte dem med det nye settet med regler.
Det er to måter du kan gå på å gjøre dette:
Accentsconagua
functions.php filen vil bli brukt.$ Wp_rewrite-> flush_rules (); og programmatisk ta vare på problemet.Uansett hvilken rute du velger, er det viktig å huske dette trinnet, fordi hver gang du definerer en ny omskrivningsregel, må du skylle de gamle reglene.
Når det gjelder å skrive våre egne omskrivningsregler, er det viktig å forstå hvordan Rewrite API fungerer.
Det kan destilleres i en fire-trinns prosess:
index.php som vil matche mønsteret til nettadressen.Hvis du er interessert i å se definisjonen av omskrivningsregler basert på konfigurasjonen du har i permalink dashbord, sjekk ut Plugin Registry Inspector plugin.
Dette pluginet vil gjøre en liste over alle reglene som er på plass for å matche angitte nettadresseskjemaer, komplett med de vanlige uttrykkene og de matchede variablene mot index.php.
Gir mening? Hvis ikke, la oss ta en titt på noen enkle, praktiske eksempler.
Gitt at vi vet at mønstre vil bli matchet og sendt videre til index.php, Vi kan dra nytte av add_rewrite_rule Funksjon for å definere hvordan våre egendefinerte nettadresser vil fungere.
La oss si at vi ser på det første innlegget i systemet, det vil si, vi ser på innlegget med ID på 1.
I de fleste vanilla WordPress installasjoner er dette Hei Verden og nettadressen er vanligvis http://domain.com/hello-world eller http://domain.com/?p=1 avhengig av dine permalink-innstillinger (det vil si ditt nåværende sett med omskrivningsregler).
Men la oss definere en regel slik som http://domain.com/first vil også laste det første innlegget i databasen:
funksjon example_add_rewrite_rules () add_rewrite_rule ('first', 'index.php? p = 1', 'top'); flush_rewrite_rules (); add_action ('init', 'example_add_rewrite_rules'); La oss legge til en ny regel som vil følge etter og la oss laste inn det andre innlegget i databasen. nemlig, http://domain.com/?p=2.
funksjon example_add_rewrite_rules () add_rewrite_rule ('first', 'index.php? p = 1', 'top'); add_rewrite_rule ('second', 'index.php? p = 2', 'top'); flush_rewrite_rules (); add_action ('init', 'example_add_rewrite_rules'); Forutsatt at du har lest dokumentasjonen for add_rewrite regel, Dette er lett nok til å forstå, riktig?
Kort sagt tar det tre argumenter:
Nå er disse eksemplene grunnleggende. Dette er ikke nok til å virkelig vise oss hvordan du konfigurerer egendefinerte ruter som de som vi skisserte tidligere i denne artikkelen. For å gjøre det må vi ta en titt på noen mer komplekse uttrykk.
Men før vi går om å gjøre det, er det viktig å merke det kallet flush_rewrite_rules () som vi gjør over er faktisk a dårlig praksis. Det fungerer i eksemplet ovenfor, men det kan faktisk senke nedlastningstiden for et nettsted.
Faktisk trenger det bare å bli kalt når omskrivningsreglene endrer seg. Dette kan oppstå når et plugin er aktivert, eller det kan endres når et tema er aktivert.
Uansett hva som er tilfelle, må du sørge for at du hekker dine funksjoner riktig, slik at omskrivningsregler ikke skylles på hver enkelt sidebelastning - bare når omskrivningsreglene selv har endret seg.
For å introdusere et mer komplisert sett med omskrivningsregler som de som vi tidligere har beskrevet i dette innlegget fra CRUD-operasjoner, er det viktig å forstå følgende to funksjoner:
add_rewrite_tag vil la WordPress vite om egendefinerte spørringsstrengvariabler. Dette brukes også i forbindelse med neste funksjon.add_rewrite_rule, som nevnt, vil tillate oss å legge til flere omskrivningsregler til WordPress (samt sette prioritet).La oss si at vi har en egendefinert posttype som heter Individuell som representerer en person i søknaden. La oss da si at Individuell har også følgende metoder og tilhørende nettadresser tilgjengelige:
alle: http://domain.com/individuals/ Oppdater: http://domain.com/individual/update/1 som brukes til å oppdatere den første personenslette: http://domain.com/individual/delete/1 som brukes til å slette den første personenSå skjemaet er enkelt nok, men hvordan går vi med å implementere det?
Først må vi definere omskrivningsregler:
funksjon example_add_rewrite_rules () // Definer taggen for den enkelte ID add_rewrite_tag ('% individual_id%', '([0-9] *)'); // Definer reglene for hver enkelt person add_rewrite_rule ('^ individual / update / ([0-9] *)', 'index.php? Individual = update & individual_id = $ matches [1]', 'top'); add_rewrite_rule ('^ enkelt / slett / ([0-9] *)', 'index.php? individual = delete & individual_id = $ matches [1]', 'top'); add_action ('init', 'example_add_rewrite_rules'); Deretter må vi definere disse tilpassede funksjonene for hver enkelt person, slik at de oppdaterer riktig post i databasen når de kalles.
I dette tilfellet vil vi definere to funksjoner, en for å oppdatere Individuell og en for å slette Individuell. Følgende kode forutsetter også at litt informasjon kommer til å være inneholdt i skjemaet som sendes inn fra nettleseren.
Nærmere bestemt antas det at den individuelle ID, fornavn, etternavn og annen informasjon vil bli sendt for å oppdatere den enkelte.
funksjon example_process_individual ($ input) hvis (example_updating_user ()) example_update_individual ($ input); annet hvis ('true' == $ input ['delete_individual']) example_delete_individual ($ input ['individual_id']); hvis (! is_admin ()) add_action ('init', 'example_process_individual'); funksjon example_update_individual ($ input) / * Den innkommende $ inngangssamlingen fra en antatt form * som vil bli brukt til å oppdatere brukeren. * * Det kan inneholde informasjon som ID, fornavn, etternavn og så videre. * * Etter suksess, bruk wp_redirect å gå tilbake til hjemmesiden, eller last * på siden for å vise en feil. * / funksjon example_delete_individual ($ individual_id) / * Bruk innkommende ID for å finne den enkelte posten og fjern den * fra databasen. * * Etter suksess, bruk wp_redirect å gå tilbake til hjemmesiden, eller last * på siden for å vise en feil. * / funksjon example_updating_user () return 0 == strpos ($ _SERVER ['REQUEST_URI'], '/ individuell / oppdatering'); funksjon example_deleting_user () return 0 == strpos ($ _SERVER ['REQUEST_URI'], '/ individual / delete'); Legg merke til at den første funksjonen er koblet til i det handling og er bare sparket hvis brukeren ikke er logget inn som administrator. Dette kan forbedres videre ved å betinget at det bare skal lastes hvis det kommer fra en bestemt side; Men for dette eksempelet tjener det sitt formål.
Deretter les koden kommentarer for Oppdater og Slett Fungerer for å se hvordan de skal fungere.
Til slutt merk at de to siste funksjonene er enkle hjelpere som er ment å tillate oss å skrive renere kode i den opprinnelige tilkoblede funksjonen.
Jeg vet at dette er litt av et ufullstendig eksempel, men for en lengre artikkel og et komplekst emne har jeg sikret meg å gjøre det beste jeg kan for å presentere WordPress Rewrite API, diskutere fordelene ved å bruke det og snakke om hvordan det kan brukes til å skape renere URL-ruter.
Sannheten er, det er fortsatt noe av et utfordrende tema og er en som er best forstått gjennom implementering. Ikke desto mindre er dette enda en komponent i WordPress-programmet som gjør det mulig å tjene som grunnlag for utvikling av webapplikasjoner.
Med alt det sagt, er det på tide å gå videre til konseptet med caching.
Visst, det er mange caching plugins som er tilgjengelige for WordPress, men hvis du er en utvikler, vil du bygge på et nivå av innfødt caching, og du ønsker å utnytte WordPress APIer for å gjøre det. Hvis det er tilfelle, er det viktig å gjøre deg kjent med hva som er tilgjengelig og hvordan du gjør det.
Så med det sagt vil vi neste gang gjøre oppmerksomheten vår til Transienter API slik at vi kan håndtere litt innfødt caching på egen hånd, og se hvordan dette kan hjelpe tredjeparts caching-mekanismer, gjør våre applikasjoner enda raskere.
