Tag: php

Categorieën
Hosting Linux PHP WordPress

WordPress e-mails SPF `neutral`

Veel WordPress website beheerders zullen wel eens meegemaakt hebben dat ze geen e-mailnotificatie kregen nadat een bezoeker een formulier had ingestuurd. Dit komt vaak doordat WordPress en het versturen van e-mails foutgevoelig is. Er kan namelijk op allerlei plekken iets fout gaan waardoor je als beheerder geen e-mailnotificatie binnen krijgt. In dit bericht zal ik een aantal scenario’s benoemen.

Formulieren plugin

Veel WordPress websites maken gebruik van een formulieren plugin. WordPress is namelijk standaard niet uitgerust met een formulieren functionaliteit. We maken bij Pronamic voornamelijk gebruik van de formulieren plugin Gravity Forms (affiliate link). Binnen Gravity Forms kunnen beheerders per formulier e-mailnotificaties instellen. Als een e-mailnotificatie niet binnen komt dan kan het zijn dat de e-mailnotificatie niet goed is ingesteld. Er is bijvoorbeeld een onjuist e-mailadres ingesteld of de e-mailnotificatie wordt alleen verstuurd bij bepaalde condities. Bij problemen is het daarom goed om altijd te controleren of e-mailnotificatie instellingen juist zijn. En of er misschien nog plugin updates beschikbaar zijn.

Standaard WordPress e-mail functie

WordPress is standaard uitgerust met een e-mail functie genaamd wp_mail(). Ontwikkelaars kunnen deze functie gebruiken voor het versturen van e-mails. Formulieren plugins zoals Gravity Forms maken vaak gebruik van deze functie. De wp_mail() functie maakt standaard gebruik van de PHPMailer bibliotheek. De PHPMailer bibliotheek maakt vaak weer gebruik van de PHP mail() functie. De PHP mail() functie roept vervolgens vaak weer de e-mail functionaliteit van het besturingssysteem aan. Binnen deze verschillende functies/technieken kan ook het één en andere fout gaan.

Maatwerk WordPress e-mail functie

De standaard WordPress e-mail functie kan door ontwikkelaars ook aangepast worden. Als iemand bijvoorbeeld geen gebruik wil maken van PHPMailer en/of de PHP mail() functie dan kan dat aangepast worden. Beheerders kunnen er bijvoorbeeld voor kiezen om e-mails te laten versturen door een e-mailprovider. Mijn collega Leo schreef op 29 februari 2016 in het bericht “4 gratis providers voor betrouwbare transactionele e-mails vanuit jouw WordPress website” hierover. Het voordeel van zo’n e-mailprovider is dat ze gespecialiseerd zijn in het versturen van e-mails. Deze partijen helpen je vaak ook om alle instellingen goed in te stellen.

  • Mandrill
  • SendGrid
  • Mailjet
  • MailGun
  • SparkPost
  • Postmark
  • SendinBlue

Toch kan er bij het gebruik van een e-mailproviders nog steeds van alles misgaan. Zo komt het soms voor dat WordPress niet goed kan communiceren met de betreffende e-mailprovider. Bijvoorbeeld doordat de e-mailprovider API even niet goed bereikbaar is. Daarnaast werken deze e-mailproviders vaak met abonnementen en limieten. Indien een limiet wordt bereikt kan het versturen van e-mails geblokkeerd worden. Verder zijn deze e-mailproviders vaak erg populair en werken ze met gedeelde IP-adressen. Doordat de diensten zo populair zijn komt het ook vaker voor dat hun IP-adressen op een blacklist staan.

SPF neutral

Om te testen of je WordPress installatie e-mails goed verstuurd kun je gebruik maken van de Check Email plugin van Chris Taylor en de mail-tester.com tool van MailPoet & AcyMailing. Via deze tools kun je controleren of e-mailbeveiliging technieken zoals SPF en DKIM goed zijn ingesteld. Op een website gehost bij SiteGround viel mij daardoor recent de volgende SPF-melding op:

spf=neutral (google.com: 69.175.69.92 is neither permitted nor denied by best guess record for domain of ********@esm35.siteground.biz) smtp.mailfrom=********@esm35.siteground.biz
Return-Path: <********@esm35.siteground.biz>

Het liefst zie je de spf=pass melding om meer zekerheid te hebben dat e-mails niet als ongewenst (spam) worden gezien. Na een zoektocht blijkt dat SiteGround standaard een @esm35.siteground.biz e-mailadres instelt als Return-Path. Hierdoor controleren e-mailservers of de server achter het esm35.siteground.biz adres wel e-mails mogen versturen namens de betreffende domeinnaam. Dit is neither permitted nor denied, dus niet toegestaan of geweigerd en daardoor neutral. Gelukkig kunnen we de Return-Path die SiteGround standaard instelt wel overschrijven. Tot 20 augustus 2016 deed WordPress dit standaard. Dit werd echter verwijderd omdat dit niet op alle hosting omgevingen goed werkt. Meer informatie hierover is te vinden in WordPress core Trac ticket 37736 (Git commit). Binnen een SiteGround hosting omgeving is dit echter geen probleem. De Return-Path kan bij SiteGround ingesteld via het php.ini bestand:

sendmail_path = "/usr/sbin/sendmail -t -i -f [email protected]"

Eventueel kan ook de “wp_mail return-path” plugin van Barnaby Puttick gebruikt worden.

Categorieën
Mac PHP

Homebrew PHP memory limit verhogen voor Composer

Ik heb op mijn blog al regelmatig geschreven over Homebrew (brew), PHP en Composer. Soms komt het voor dat bij het uitvoeren van een Composer commando memory limit fouten optreden. Bijvoorbeeld:

$ composer update

Loading composer repositories with package information
Updating dependencies (including require-dev)

PHP Fatal error:  Allowed memory size of 1073741824 bytes exhausted at Zend/zend_vm_execute.h:551 (tried to allocate 32 bytes) in phar:///usr/local/Cellar/composer/1.0.0-alpha8/libexec/composer.phar/src/Composer/DependencyResolver/RuleWatchGraph.php on line 52

Dergelijke fouten zijn vrij eenvoudig op te lossen door de memory limit te verhogen. Dit kan eenvoudig door in het PHP configuratie bestand de memory limit te verhogen.

Hiervoor moet je echter wel weten wat de locatie is van PHP configuratie bestand. Met Homebrew is dit gelukkig eenvoudig te achterhalen. Hiervoor moeten we eerst weten van welke PHP versie we gebruik maken:

$ php -v

PHP 5.6.3 (cli) (built: Nov 16 2014 12:01:32) (DEBUG)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2014 Zend Technologies
    with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans

Vervolgens kunnen we met het Homebrew info commando aanvullende informatie opvragen:

$ brew info php56

Dit commando zal de nodige informatie geven over PHP en onder het kopje “Caveats” zal de locatie van het PHP configuratie bestand vermeld staan:

The php.ini file can be found in:
    /usr/local/etc/php/5.6/php.ini

Vervolgens kan dit bestand met behulp van nano eenvoudig aangepast worden.

nano /usr/local/etc/php/5.6/php.ini

De memory_limit kan vervolgens eenvoudig aangepast worden van bijvoorbeeld:

; Maximum amount of memory a script may consume (128MB)
; http://php.net/memory-limit
memory_limit = 1024M

naar:

; Maximum amount of memory a script may consume (128MB)
; http://php.net/memory-limit
memory_limit = 4096M

Met behulp van het volgende commando kan gecontroleerd worden of de wijziging goed is doorgevoerd:

$ php -i | grep memory_limit

memory_limit => 4096M => 4096M
Categorieën
WordPress

WordPress User Query filter op post type author

Het is standaard niet mogelijk om binnen een WordPress User Query te filteren op auteurs van een specifieke post type. Met behulp van een een filter is deze functionaliteit echter vrij eenvoudig toe te voegen.

Vervolgens kan eenvoudig via een_User_Query argument gefilterd worden op een specifieke post type.