Aangepaste e-mailadressen voor reacties maken de API begrijpen

Als het gaat om het werken met e-mails in WordPress, zijn de meeste gebruikers bekend met de basisfuncties en / of meldingen.

In het bijzonder zijn we gewend om e-mails te zien voor:

  • Gebruikersregistraties
  • Wachtwoordherinneringen
  • Meldingen van reacties
  • … enzovoorts.

Als het gaat om het bouwen van meer geavanceerde thema's - of zelfs applicaties - is het niet ongebruikelijk om e-mailfunctionaliteit uit te besteden om onze gebruikers een betere ervaring te bieden.

Dat wil zeggen als dat zo is gaand om ze te e-mailen, willen we de e-mail er zo goed mogelijk laten uitzien. Dit vereist meestal dat we consistente branding, een flexibelere lay-out en een groter aantal gestileerde elementen opnemen.

Voor bepaalde e-mails is dit totaal zinvol, vooral als het gaat om welkomstberichten, nieuwsbrieven en dergelijke.

Maar als u een consistente ervaring op uw site wilt bieden op de manier waarop het eruitziet, bijvoorbeeld hoe e-mails met opmerkingen over reacties eruit zien, dan kunt u dat doen met de native WordPress API.

Dus in deze tweedelige serie gaan we de API bekijken voor het aanpassen van onze moderatie van opmerkingen en e-mails voor reacties.

In het eerste deel van de serie gaan we de functie bekijken die verantwoordelijk is voor het verzenden van de e-mail en de hooks die deze biedt. We gaan de mogelijkheden van de haak bekijken, en dan gaan we onderzoeken hoe het hele proces werkt.

Hierna beëindigen we de serie door een praktisch voorbeeld te bekijken van hoe we de e-mail met opmerkingen voor opmerkingen volledig kunnen aanpassen aan onze behoeften.


De functie en de haken

De functie die verantwoordelijk is voor het verzenden van e-mailberichten met opmerkingen, is de functie wp_notify_postauthor.

Op het moment van schrijven van dit artikel is de documentatie voor deze functie een beetje zwak. Hoewel het goed beschrijft wat de functie accepteert en wat het teruggeeft, is de beschrijving ervan een beetje onduidelijk.

Er staat:

Deze functie kan worden vervangen via plug-ins. Als plug-ins deze functies niet opnieuw definiëren, wordt deze in plaats daarvan gebruikt.

Zuivert een URL voor gebruik in een omleiding.

De twee belangrijkste afhaalmomenten uit dit deel van de documentatie zijn de volgende:

  • "De functie kan worden vervangen via plug-ins."
  • "Sanitizes een URL voor gebruik in een omleiding."

Misschien wel het meest cryptische deel van de documentatie is dat de functie groothandel kan worden vervangen via plug-ins; De functie biedt echter ook verschillende filters die we kunnen inhaken om de gegevens te manipuleren.

In feite brengt dit een belangrijke strategie met zich mee als het gaat om het ontwikkelen van open source-projecten.

Een strategie voor open source-ontwikkeling

Een van de krachtigste aspecten van open source-ontwikkeling is de aard zelf: dat het open source is.

Voorbeeld: wanneer documentatie u iets te wensen overlaat, is het het beste om de broncode te openen en te bekijken wat er precies gebeurt.

Om dit te doen, is het eenvoudig om de functie in de kernapplicatie te lokaliseren. U kunt dit doen met uw IDE of door de WordPress Trac te bekijken.

Hoe dan ook, voor de doeleinden van deze functie bevindt de functie zich in wp-includes / pluggable.php.

Zodra we het hebben gevonden, kunnen we beginnen met het lokaliseren welke aspecten van de plug-in te overschrijven zijn door plug-ins.


De mogelijkheden

Merk op dat een deel van wat WordPress zo krachtig maakt, het haaksysteem is. Bedenk uit een eerder bericht dat er twee soorten haken zijn: acties en filters.

  • Acties zijn gebeurtenissen die vuren in de levenscyclus van de WordPress-pagina wanneer bepaalde dingen zijn gebeurd.
  • Filters zijn functies die primair verantwoordelijk zijn voor het onderscheppen, beheren en retourneren van gegevens voordat deze worden doorgegeven aan de browser.

Omdat we de inhoud en / of vormgeving van een e-mail willen wijzigen, zoeken we naar functionaliteit die specifiek is bedoeld voor het weergeven van inhoud van een e-mail. Daarom moeten we op zoek naar een filter.

En omdat we specifiek op zoek zijn naar functionaliteit voor het weergeven van inhoud voor een e-mail, moeten we op zoek naar een filter.

Dus, met dat alles gezegd, we zijn op zoek naar een oproep (of oproepen) naar apply_filters en deze functie biedt drie:

  • $ 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);

Maar wat goed is het vinden van de filters als we niet echt weten hoe ze te gebruiken?


Hoe het werkt

Bij het bekijken van de bovenstaande code, ziet u dat WordPress de gegevens filtert via drie specifieke functies die elk relatief schoner lijken, toch?

  • comment_notification_text is verantwoordelijk voor het beheren van de daadwerkelijke inhoud van de e-mail
  • comment_notification_subject manges de onderwerpregel van de e-mail
  • comment_notification_headers omgaan met hoe de e-mail wordt weergegeven (meestal is dit de plek waar we platte tekst plaatsen versus, laten we zeggen, HTML).

Makkelijk genoeg, toch? Natuurlijk is dit eigenlijk maar de helft.

Naast het begrijpen van wat elke functie doet, is het niet veel waard totdat we weten hoe we de filters daadwerkelijk kunnen gebruiken.


Conclusie

In het volgende artikel gaan we onze eigen plug-in bouwen die aangepaste e-mailberichten voor reacties biedt.

We streven er in het bijzonder naar om een ​​consistentere ervaring te bieden met de rest van de site, we zullen de inhoud van de e-mail aanpassen en we zullen bekijken hoe en waarom we de headers moeten beheren die bij elke e-mail worden verzonden.

We gebruiken ook het nieuwste thema - Twentytwelve - dat wordt geleverd met WordPress 3.5. Dus, in de tussentijd, ga je gang en haal je ontwikkelingsomgeving op, zodat je klaar bent om te gaan met het volgende artikel.


Een opmerking over documentatie

Een van de leukste dingen over open source-ontwikkeling is de mogelijkheid voor iedereen om aan het project bij te dragen. Wanneer we als ontwikkelaars denken aan bijdragen aan een project, denken we vaak aan het bijdragen aan de codebase.

Maar een open source-project is zoveel meer: ​​het omvat documentatie, beeldmateriaal, verschillende afhankelijkheden, enzovoort.

Op het moment dat dit bericht oorspronkelijk werd geschreven, had de documentatie voor wp_notify_postauthor enige verbetering nodig. Als zodanig heb ik een update van de Codex bijgedragen tijdens het schrijven van dit bericht.

Een oproep tot actie

Als je in welke hoedanigheid ook betrokken bent bij de WordPress-community en op een of andere manier iets kunt bijdragen - zelfs als het de documentatie bijwerkt - dan verzoek ik je dat dringend, want het helpt de vele duizenden mensen over de hele wereld die WordPress gebruiken.


Middelen

  • wp_notify_postauthor
  • WordPress Trac
  • Acties en filters begrijpen
  • WordPress 3.5 RC3
  • Twintig twaalf