Når det gjelder å jobbe med e-postmeldinger i WordPress, er de fleste brukere kjent med de grunnleggende funksjonene og / eller varslene.
Spesielt er vi vant til å se e-postmeldinger for:
Når det gjelder å bygge mer avanserte temaer - eller til og med applikasjoner - er det ikke uvanlig å outsource e-postfunksjonalitet for å gi brukerne en bedre opplevelse..
Det vil si at hvis vi er går for å sende e-post til dem, vil vi gjerne gjøre e-posten så fin som mulig. Dette krever vanligvis at vi inkluderer konsekvent merkevarebygging, en mer fleksibel layout og et større antall stilelementer.
For visse e-postmeldinger er dette helt fornuftig, spesielt når det gjelder velkommen meldinger, nyhetsbrev og lignende.
Men hvis du ønsker å gi en konsistent opplevelse på tvers av nettstedet ditt, fra hvordan det ser ut til å si, hvordan e-postmeldinger om kommentarvarsler vises, kan du gjøre det med den innfødte WordPress API.
Så i denne todelte serien skal vi se på API-en for å tilpasse våre kommentarer moderering og kommentar varsel e-post.
I den første delen av serien skal vi se gjennom funksjonen som er ansvarlig for å sende e-posten og krokene den gir. Vi skal vurdere kapasiteten til kroken, og så skal vi undersøke hvordan hele prosessen fungerer.
Etter det vil vi avslutte serien ved å se på et praktisk eksempel på hvordan vi kan tilpasse kommentarvarslingsmailen til våre behov.
Funksjonen som er ansvarlig for å sende kommentarvarsel e-post er funksjonen wp_notify_postauthor.
Når du skriver denne artikkelen, er dokumentasjonen for denne funksjonen litt svak. Selv om det riktig beskriver hva funksjonen aksepterer og hva den returnerer, er beskrivelsen litt uklar.
Det lyder:
Denne funksjonen kan erstattes via plugins. Hvis plugins ikke omdefinerer disse funksjonene, vil dette bli brukt i stedet.
Sanitiserer en nettadresse for bruk i omdirigering.
Nå er de to viktigste takeaways fra denne delen av dokumentasjonen som følger:
Kanskje den mest kryptiske delen av dokumentasjonen er at funksjonen kan erstattes engros via plugins; Funksjonen tilbyr imidlertid også flere filtre som vi kan hekte inn for å manipulere dataene.
Faktisk gir dette en viktig strategi når det gjelder å utvikle åpen kildekodeprosjekter.
En av de mest kraftfulle aspektene av åpen kildekodeutvikling er dens natur: at den er åpen kildekode.
Tilfelle i punkt: Når dokumentasjonen gir deg noe å være ønsket, er det neste beste å åpne kildekoden og se nøyaktig hva som skjer.
For å gjøre dette er det enkelt å finne funksjonen i kjerneprogrammet. Du kan gjøre dette ved din IDE eller ved å bla gjennom WordPress Trac.
Uansett, for dette innleggets formål er funksjonen i spørsmålet lokalisert i wp-includes / pluggable.php
.
Når vi har funnet den, kan vi begynne å finne hvilke aspekter av plugin som kan overstyres av plugins.
Legg merke til at en del av det som gjør WordPress så kraftig, er dens krok. Husk fra et tidligere innlegg at det er to typer kroker: Handlinger og Filtre.
Fordi vi ønsker å endre innhold og / eller styling av en e-post, søker vi etter funksjonalitet spesielt for gjengivelse av innhold i en e-post. Derfor må vi være på utkikk etter et filter.
Og siden vi leter etter funksjonalitet spesielt for gjengivelse av innhold for en e-post, må vi lete etter et filter.
Så med alt det sagt, vi leter etter en samtale (eller samtaler) til apply_filters
og denne funksjonen gir tre:
$ notify_message = apply_filters ('comment_notification_text', $ notify_message, $ comment_id);
$ subject = apply_filters ('comment_notification_subject', $ subject, $ comment_id);
$ message_headers = apply_filters ('comment_notification_headers', $ message_headers, $ comment_id);
Men hvor bra er filtre hvis vi ikke vet hvordan de skal brukes?
Når du vurderer koden ovenfor, ser du at WordPress filtrerer dataene gjennom tre spesifikke funksjoner som hver virker relativt klare, høyre?
comment_notification_text
er ansvarlig for å administrere det faktiske innholdet i e-postencomment_notification_subject
mangler emnelinjen til e-postencomment_notification_headers
håndtere hvordan e-posten blir gjengitt (vanligvis er det her vi angir ren tekst versus, si HTML).Enkelt nok, ikke sant? Selvfølgelig er dette egentlig bare halvparten av det.
I tillegg til å forstå hva hver funksjon gjør, er det ikke verdt mye før vi vet hvordan du faktisk bruker filtre.
I den neste artikkelen skal vi bygge vårt eget plugin som gir egendefinerte kommentarer til varslingsmeldinger.
Spesielt vil vi sikte på å gi en mer konsistent opplevelse med resten av nettstedet, vi tilpasser innholdet til e-posten, og vi vurderer hvordan og hvorfor vi skal administrere overskriftene som sendes med hver e-post.
Vi bruker også det siste temaet - Twentytwelve - som leveres med WordPress 3.5. Så, i mellomtiden, gå videre og få ditt utviklingsmiljøoppsett, så du vil være klar til å gå med neste artikkel.
En av de fineste tingene om åpen kildekodeutvikling er evnen til noen å bidra til prosjektet. Når vi, som utviklere, tenker på å bidra til et prosjekt, tenker vi ofte på å bidra til kodebase.
Men et open source-prosjekt er så mye mer: det inkluderer dokumentasjon, bildeverdier, ulike avhengigheter og så videre.
På tidspunktet for opprinnelig å skrive dette innlegget, trengte dokumentasjonen for wp_notify_postauthor litt forbedring. Som sådan har jeg bidratt med en oppdatering til Codex mens du skriver dette innlegget.
Hvis du er involvert i WordPress-fellesskapet i noen kapasitet og er i stand til å bidra i noe - selv om det oppdaterer dokumentasjonen - så oppfordrer jeg deg til å gjøre det slik det hjelper de tusenvis av mennesker over hele verden som bruker WordPress.