Omdat we bij Pronamic betaaloplossingen ontwikkelen voor payment providers zoals Mollie, Buckaroo, Pay.nl, etc. zijn we vaak partner van deze organisaties. In sommige gevallen krijgen we commissie voor succesvolle betalingen die via de Pronamic Pay plugin zijn opgestart. De payment providers betalen ons maandelijks of per kwartaal de opgebouwde commissie uit. Voor de boekhouding ontvangen we dan vaak een zogenaamde self-billing factuur. Waar voorheen nog wel eens creditnota’s werden verstuurd lijken de payment providers nu over te stappen naar self-billing facturen. Ik was tot vandaag niet heel bewust van dit concept. In dit bericht wat meer informatie over het self-billing principe.
Tag: wordpress
Categorieën
Gitlabber
Als webontwikkelaar maak ik veel gebruik van Git en diensten zoals GitHub, GitLab en Bitbucket. Ook bij Pronamic maken we hier intensief gebruik van. Alle WordPress plugins en thema’s die we ontwikkelen staan keurig in een eigen Git repository. We hebben inmiddels dan ook een archief met duizenden repositories. Het komt soms voor dat we alle repositories moeten doorzoeken. Het kan dan een hele klus om alle repositories te clonen. Gelukkig zijn er tools zoals https://github.com/gabrie30/ghorg en https://github.com/ezbz/gitlabber die daarbij kunnen helpen (via https://stackoverflow.com/questions/29099456/how-to-clone-all-projects-of-a-group-at-once-in-gitlab). Ik ben vandaag eens aan de slag gegaan met gitlabber.
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.
Voor debug en ontwikkel doeleinden kan het soms handig zijn om alle WordPress queries op te slaan. Dit kan gerealiseerd worden door in je code de SAVEQUERIES constante op true te zetten. Vaak wordt dit toegevoegd aan het WordPress configuratie bestand wp-config.php. Er zijn echter ook plugins die deze constante op true zetten, bijvoorbeeld: Query Monitor. Het wil dan ook wel eens voorkomen dat maatwerk code de define( 'SAVEQUERIES', true ); definitie bevat. Voor productie omgevingen is dit echter vaak niet gewenst om dit impact kan hebben op de performance van een website. Het kan soms echter lastig zijn om te achterhalen waar de SAVEQUERIES constante op true is gezet. Gelukkig kan met grep eenvoudig gezocht worden naar alle bestanden met daarin SAVEQUERIES:
grep -r -H "SAVEQUERIES" *
Gebruikers van een Savvii VPS hebben de mogelijkheid om SSH toegang te krijgen. Dit kan erg handig zijn om bijvoorbeeld snel een backup te maken of een kopie te maken van een website. Voor het opzetten van een nieuwe actuele staging omgeving kun je als volgt te werken gaan:
Productie | staging
Allereerst is het handig dat productie en staging omgevingen met elkaar kunnen communiceren via SSH. Hiervoor is het handig om een nieuwe SSH key aan te maken op de productie omgeving en deze toe te voegen aan de staging omgeving.
Productie
ssh [email protected] ssh-keygen -t rsa -b 4096 -C "[email protected]" -f ~/.ssh/pronamic_rsa eval "$(ssh-agent -s)" ssh-add ~/.ssh/pronamic_rsa
Localhost
scp [email protected]:~/.ssh/pronamic_rsa.pub ~/Downloads/pronamic_rsa.pub scp ~/Downloads/pronamic_rsa.pub [email protected]:~/tmp/pronamic_rsa.pub
Staging
ssh [email protected] cat ~/tmp/pronamic_rsa.pub >> ~/.ssh/authorized_keys rm ~/tmp/pronamic_rsa.pub
Productie » staging
ssh [email protected] cd ~/wordpress/current echo "wp-config.php" > staging-exclude.txt echo "wp-content/infinitewp/backups" >> staging-exclude.txt echo "wp-content/mu-plugins" >> staging-exclude.txt echo "wp-content/mysql" >> staging-exclude.txt echo "wp-content/uploads/2002" >> staging-exclude.txt echo "wp-content/uploads/2003" >> staging-exclude.txt echo "wp-content/uploads/2004" >> staging-exclude.txt echo "wp-content/uploads/2005" >> staging-exclude.txt echo "wp-content/uploads/2006" >> staging-exclude.txt echo "wp-content/uploads/2007" >> staging-exclude.txt echo "wp-content/uploads/2008" >> staging-exclude.txt echo "wp-content/uploads/2009" >> staging-exclude.txt echo "wp-content/uploads/2010" >> staging-exclude.txt echo "wp-content/uploads/2011" >> staging-exclude.txt echo "wp-content/uploads/2012" >> staging-exclude.txt echo "wp-content/uploads/2013" >> staging-exclude.txt echo "wp-content/uploads/2014" >> staging-exclude.txt echo "wp-content/uploads/2015" >> staging-exclude.txt echo "wp-content/uploads/backwpup*" >> staging-exclude.txt echo "wp-content/uploads/gravity_forms" >> staging-exclude.txt echo "wp-content/uploads/sites" >> staging-exclude.txt # wp db export current.sql mysqldump --user=user1 --password=******** --add-drop-table user1 > current.sql rsync -avuz --exclude-from=staging-exclude.txt . [email protected]:~/wordpress/current
Het staging-exclude.txt bestand kun je in principe eenmalig aanmaken en in bijhouden welke mappen niet mee hoeven naar de staging omgeving. In bovenstaand voorbeeld heb ik veel uploads mappen uitgesloten.
Staging omgeving
ssh [email protected] cd ~/wordpress/current # wp db reset # wp db import current.sql # wp search-replace 'http://user1.savviihq.com' 'http://user2.savviihq.com' mysql --user=user2 --password=******** user2 < current.sql
WP-CLI
Helaas werkt WP-CLI momenteel niet op onze Savvii VPS’en. Hierdoor is het exporteren en importeren van de database nog wat omslachtig. Met WP-CLI zou dit vereenvoudig kunnen worden wp db export, wp db reset, wp db import en wp search-replace.
Resources
- http://www.linuxquestions.org/questions/linux-server-73/tar-using-include-file-and-exclude-file-one-liner-908800/
- http://stackoverflow.com/questions/9427553/how-to-download-a-file-from-server-using-ssh
- http://askubuntu.com/questions/4830/easiest-way-to-copy-ssh-keys-to-another-machine
- http://askubuntu.com/questions/46424/adding-ssh-keys-to-authorized-keys
Als je een WordPress site binnen een WordPress multisite/network wilt omzetten naar een individuele WordPress installatie zul je na een zoektocht op internet al snel het advies krijgen om de content te exporteren en te importeren. Dit heeft echter als nadeel dat gebruikers, instellingen, plugins, thema’s, etc. niet meegenomen worden. In de blog “The Return from Multiste” is te lezen hoe dit ook via enkele database queries gerealiseerd kan worden.
Aangezien ik veel gebruik maak van Gravity Forms, Pronamic iDEAL en Redirection moest ik nog de volgende extra queries uitvoeren:
RENAME TABLE OLDPRE_OLDNUM_rg_form TO NEWPRE_rg_form, OLDPRE_OLDNUM_rg_form_meta TO NEWPRE_rg_form_meta, OLDPRE_OLDNUM_rg_form_view TO NEWPRE_rg_form_view, OLDPRE_OLDNUM_rg_lead TO NEWPRE_rg_lead, OLDPRE_OLDNUM_rg_lead_detail TO NEWPRE_lead_detail, OLDPRE_OLDNUM_rg_lead_detail_long TO NEWPRE_lead_detail_long, OLDPRE_OLDNUM_rg_lead_meta TO NEWPRE_rg_lead_meta, OLDPRE_OLDNUM_rg_lead_notes TO NEWPRE_rg_lead_notes;
RENAME TABLE OLDPRE_OLDNUM_rg_ideal_feeds TO NEWPRE_rg_ideal_feeds, OLDPRE_OLDNUM_pronamic_ideal_configurations TO NEWPRE_pronamic_ideal_configurations, OLDPRE_OLDNUM_pronamic_ideal_payments TO NEWPRE_pronamic_ideal_payments;
RENAME TABLE OLDPRE_OLDNUM_redirection_404 TO NEWPRE_redirection_404, OLDPRE_OLDNUM_redirection_groups TO NEWPRE_redirection_groups, OLDPRE_OLDNUM_redirection_items TO NEWPRE_redirection_items, OLDPRE_OLDNUM_redirection_logs TO NEWPRE_redirection_logs, OLDPRE_OLDNUM_redirection_modules TO NEWPRE_redirection_modules;
Daarnaast heb ik via de active_sitewide_plugins meta key in de OLDPRE_sitemeta tabel en http://www.unserialize.com/ nog even gecontroleerd welke plugins sitewide geactiveerd waren.
Categorieën
WordPress in readonly (alleen lezen) modus
Bij het verhuizen van een WordPress website naar een nieuwe hosting omgeving kan het handig zijn om de WordPress website tijdelijk in readonly (alleen lezen) modus te zetten. Op die manier kun je voorkomen dat er nieuwe berichten, reacties, formulierinzendingen, etc. geplaatst worden na je database dump/export. Met behulp van de volgende .htaccess regels kun je een website vaak in readonly (alleen lezen) modus zetten:
<LimitExcept GET HEAD> Order Allow,Deny Deny from all </LimitExcept>
Bron: http://serverfault.com/a/270971
Update 22 juli 2014
Mocht bovenstaande code niet functioneren dan hetzelfde ook gerealiseerd worden met behulp van de volgende code:
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|OPTIONS|POST|PUT)
RewriteRule .* - [F]
Bron: http://www.xpertdeveloper.com/2012/02/limit-request-methods-using-htaccess/
wp-config.php
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.