Share
Gjennom hele denne serien har vi tatt en titt på hvordan WordPress kan fungere som grunnlag for utvikling av webapplikasjoner.
Saken er, frem til dette punktet, har vi egentlig ikke tatt en titt på funksjonene i WordPress som virkelig bidrar til bygge webapplikasjoner. I stedet har vi brukt tid på å se på hvordan WordPress fungerer som grunnlag i stedet for et rammeverk, og vi har sett på hvordan WordPress er organisert i forhold til mange av de moderne rammene som er tilgjengelige.
Spesielt har vi tatt en titt på det hendelsesdrevne designmønsteret i motsetning til det populære mønster-kontroll-designmønsteret (og varianter av det), og hvordan dette ser ut i sammenheng med WordPress.
Dermed har vi jobbet for å revurdere programarkitektur og hvordan strukturen i WordPress-sammenheng hjelper oss med å få en bedre konseptuell modell for hvordan ting passer sammen i WordPress, og hvordan du kan dra nytte av kroksystemet - det vil si handlinger og filtre - og hvordan de påvirker ulike punkter under WordPress-sidens livssyklus.
Selv om dette fortjener litt mer diskusjon, må vi se på fasilitetene som WordPress tilbyr utenom-boksen for å kunne forstå de funksjoner og APIer som vi må jobbe for, før vi tar en titt på hvordan å jobbe med dem.
I løpet av de neste par artiklene skal vi bare gjøre det.
Når du tenker på komponentene i et webapplikasjon, kommer det en rekke ting som kommer til å tenke på. Det vil si at bortsett fra den vanlige arkitekturen til databasen, mellomvare og presentasjonslag, er det også følgende funksjoner:
Selv om denne listen på ingen måte er omfattende, treffer den høye notatene av hva som går ut på å bygge en standard webapplikasjon (selvfølgelig, hvis det er poeng som er savnet, ikke nøl med å nevne dem i kommentarene).
Og nei - dette er ikke reseptivt. Noen ganger vil webapplikasjoner ikke ha brukeradministrasjon, noen ganger vil brukerne ikke ha roller, kanskje du ikke trenger et caching, og så videre.
Men poenget er ikke å gjøre en sak for alle de tingene du trenger. I stedet handler det om å gjøre en sak for de tingene som er tilgjengelige bør du trenger dem.
Så med det sagt, la oss ta en titt på hva WordPress tilbyr i veien for brukeradministrasjon, tillatelser, e-postfunksjonalitet og øktstyring.
Alle som har brukt WordPress - selv om det bare er for blogging eller grunnleggende innholdshåndtering - er kjent med det grunnleggende brukersystemet. Det vil si at du oppretter et brukernavn, et passord, og fyll deretter ut profilen din så mye du vil.
Videre er mer erfarne utviklere kjent med ideene om roller og evner. Jeg vil selv venture å si at de som bruker WordPress, er kjent med systemet, selv om de aldri har tatt en titt på Codex eller ødelagt med å skrive noen brukerbasert kode.
Men den generelle ideen er veldig enkel: Brukere representerer en individuell profil for en konto i WordPress. Deres rolle er indikert av hva de har blitt tildelt under opprettelsen av kontoen.
Disse roller inkluderer:
Igjen, de fleste av oss som har jobbet med WordPress, er kjent med disse rollene, ikke sant? Men hvordan passer evner inn i bildet?
Enkelt sagt, evner er det som gir brukere visse tillatelser gjennom hele WordPress-applikasjonen, så vel som det som begrenser dem fra bestemte områder av applikasjonen. Dette er relativt godt dokumentert i Codex.
Men her er saken: Hvis du bygger et program på WordPress, gjør de tilgjengelige APIene det mulig å låse brukere ut av egendefinerte områder du har opprettet, basert på deres roller og evner.
Først, la oss si at når du jobber med webapplikasjonen din, vil du være i stand til å gi brukeren muligheten til å registrere eller registrere seg fra et egendefinert påmeldingsskjema (i motsetning til standardmetoden for å opprette brukerkontoen i baksiden som vist ovenfor).
Dette kan gjøres ved å lage en mal med et skjema og deretter lese postdata.
Faktisk kan det virkelig være så enkelt som å fange brukerens e-postadresse. Jeg nevner dette fordi, selv om brukernavnene er hyggelige og morsomme, har e-postene en tendens til å være unik for en person, slik at det blir enklere å gjøre feilkontroll.
Så trinnene for å gjøre det ville være:
Relativt rett fram, ikke sant? Selvfølgelig betyr dette at du kan generere et passord for brukeren ved opprettelsen av sin konto. Heldigvis er det en API for det.
Så her er et eksempel på hvordan du programmatisk lager en bruker basert på en spesifisert e-postadresse (mens du automatisk genererer et passord).
Accentsconagua
hvis (null == brukernavn eksisterer ($ email_address)) $ password = wp_generate_password (12, false); $ user_id = wp_create_user ($ email_address, $ passord, $ email_address); wp_update_user (array ('ID' => $ user_id, 'kallenavn' => $ email_address);); ellers // Brukernavnet eksisterer allerede, så håndter dette i henhold til dette ... Etter det må du faktisk lage en ny forekomst av WP_User.
$ user = ny WP_User ($ user_id);
Dette er hva som tillater oss å sette roller for den oppgitte brukeren.
Endelig er det på tide å bestemme hvilken rolle og sett av evner du vil tildele brukeren.
På den ene siden kan du hardt kode disse verdiene basert på alternativene som WordPress tilbyr. Sannheten er, du kan til og med skape tilpassede roller og evner. For nå er det utenfor artikkelen; Vi kan imidlertid besøke den i en fremtidig serie.
Så la oss si at vi vil at alle brukere som er registrert for øyeblikket, skal bli gitt abonnenten rolle. Du kan se hvilket sett av muligheter de vil bli gitt i denne Codex-artikkelen.
Å sette en rolle er trivielt:
$ user-> set_role ('bidragsyter'); På dette tidspunktet har du opprettet en ny bruker i WordPress-programmet programmatisk uten å måtte bruke noen av standard administrativ funksjonalitet.
Bare rør dette opp til din egen mal, valider, sanitiser og kontroller innkommende $ _POST data, og du vil være klar til å gå.
Den fulle koden ser slik ut:
hvis (null == brukernavn eksisterer ($ email_address)) // Generer passordet og opprett brukeren $ password = wp_generate_password (12, false); $ user_id = wp_create_user ($ email_address, $ passord, $ email_address); // Angi kallenavnet wp_update_user (array ('ID' => $ user_id, 'kallenavn' => $ email_address);); // Sett rollen $ user = ny WP_User ($ user_id); $ user-> set_role ('bidragsyter'); else // Brukeren eksisterer allerede // slutt hvis / annet Ikke dårlig, ikke sant?
Men å skape en bruker og da faktisk lagre informasjonen i databasen i bare halvparten av det, riktig?
Når brukeren logger på og er godkjent, vil du sannsynligvis ønske å begrense innholdet basert på deres rolle. Så dette reiser spørsmålet: Når en bruker er logget inn, hvordan henter vi brukerens rolle?
Heldigvis gjør WordPress 'API det relativt enkelt:
Vi kommer til å trenge å dra nytte av wp_get_current_user () funksjon, og da må vi få en forekomst av WP_User objekt ved hjelp av den nåværende brukerens ID, hvorefter vi kan se på brukerens evner.
Ta en titt på koden nedenfor:
// Få en forekomst av gjeldende bruker $ user_id = wp_get_current_user () -> ID; $ user = ny WP_User ($ user_id);
Ikke dårlig, ikke sant?
Dette gjør det veldig enkelt å skrive betinget kode som:
// Dette vil skrive ut brukerfunksjonene print_r ($ user-> wp_capabilities); // som igjen vil tillate deg å utføre en sjekk slik: hvis ('1' === $ bruker-> wp_capabilities ['abonnent']) // Vi har en abonnent Der er en alternativ måte å gjøre dette på, skjønt:
global $ current_user; get_currentuserinfo (); hvis (0 === $ current_user-> user_level) // Vi har en abonnent
Men dette reiser spørsmålet om hvor kom nullen fra? Sjekk ut akkurat det.
Forskjellene mellom de to tilnærmingene er avhengig av hvordan objektorienterte du vil at koden din skal være.
Jeg pleier å være mindre av en fan av å bruke global når det er en objektorientert tilnærming tilgjengelig (som i første eksempel); Det andre eksempelet gir imidlertid også en relativt enkel løsning. Ditt valg.
Uansett, når du er i stand til å betinget sjekke rollen til en brukers konto, kan du da begrense dem til bestemte områder av søknaden.
Du har rett: I det minste må brukerens behov for å motta e-postmeldinger for når kontoene er opprettet, og de må kunne motta e-post når noe om kontoen deres har endret seg.
Igjen gir WordPress en API som gjør dette veldig enkelt, men det kan utvides utover enkle handlinger, for eksempel når en brukeres profilinformasjon endres.
Faktisk, gitt at WordPress har et rikt hendelsessystem, kan du potensielt hekte inn i et hvilket som helst antall hendelser og sende e-post når hva som helst skjer. Det er åpenbart overkill, men det går for å vise hvor kraftig APIen egentlig er.
Så i neste avsnitt skal vi se på WordPress 'e-post-API og hvordan det kan brukes til å sende meldinger om bestemt aktivitet, samt hvordan det kan hekta på andre funksjoner i søknaden.
