Rabobank OmniKassa automaticResponseUrl betalingstatus updates

De Rabobank OmniKassa oplossing heeft ondersteuning voor een zogenaamde automaticResponseUrl parameter. Bij het starten van een transactie kan hier een URL in opgegeven worden. Vervolgens zal de OmniKassa betalingsstatus updates doorgeven aan deze URL.

Nu krijg ik als ontwikkelaar van de Pronamic iDEAL plugin regelmatig klachten over dat de betalingsstatus updates van de OmniKassa niet functioneren. Blijkbaar worden de betalingsstatus updates van de OmniKassa dan niet correct verwerkt. Het is echter lastig om te achterhalen wat wanneer mis gaat.

Het betalingsstatus request van de OmniKassa kan namelijk op verschillende locaties niet goed verwerkt worden. Allereerst moet de automatische response URL natuurlijk bereikbaar zijn voor de OmniKassa. Maar hoe controleer je of de OmniKassa je website goed kan bereiken?

De server logboeken zijn vaak een goed startpunt om dit te onderzoeken. De automatisch OmniKassa betalingsstatus updates requests zien er in een Apache logboek vaak zo uit:

160.92.133.135 - - [06/Feb/2015:12:12:45 +0100] "POST / HTTP/1.0" 302 283 "-" "Java/1.6.0_45"
160.92.133.135 - - [06/Feb/2015:12:12:46 +0100] "GET / HTTP/1.0" 200 58249 "-" "Java/1.6.0_45"

Belangrijke en opvallende punten hierin zijn het IP-adres 160.92.133.135 en de User-Agent Java/1.6.0_45. Na een zoektocht op internet kwam ik al snel de volgende Twitter conversatie tegen met een goede tip:

Mochten de automatisch OmniKassa betalingsstatus updates niet correct functioneren dan is het verstandig om te informeren of je hostingprovider de volgende IP-adress kan ‘whitelisten':

  • 160.92.133.135
  • 193.56.46.18

WordPress ontwikkelomgeving op Mac met Brew, Nginx, PHP 5.6, PHP-FPM, MariaDB, phpMyAdmin en meer

 In dit bericht beschrijf ik in een aantal stappen hoe je een WordPress ontwikkelomgeving omgeving kunt opzetten op een Mac.

Brew

Homebrew is een pakket manager voor je Mac en erg handig voor het installeren van allerlei handig tools.

http://brew.sh/

Met het volgende commando kun je Homebrew installeren, maar ik adviseer je om de instructies op de Homebrew website te volgen:

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Mocht je Brew al geïnstalleerd hebben dan kun je met het volgende commando Brew bijwerken.

brew update
brew upgrade

PHP

PHP kan eenvoudig via Homebrew geïnstalleerd worden, maar hiervoor moet je wel even de PHP repository intappen.

https://github.com/Homebrew/homebrew-php

Met de volgende commando’s kun je de PHP repository voor Homebrew tappen:

brew tap homebrew/dupes
brew tap homebrew/versions
brew tap homebrew/homebrew-php

Vervolgens kun je met het volgende commando bekijken wel opties er beschikbaar zijn voor het installeren van PHP 5.6:

brew options php56

Als het goed is geeft dit commando het volgende resultaat:

--disable-opcache
	Build without Opcache extension
--disable-zend-multibyte
	Disable auto-detection of Unicode encoded scripts (PHP 5.2 and 5.3 only)
--homebrew-apxs
	Build against apxs in Homebrew prefix
--with-apache
	Enable building of shared Apache 2.0 Handler module, overriding any options which disable apache
--with-cgi
	Enable building of the CGI executable (implies --without-apache)
--with-debug
	Compile with debugging symbols
--with-fpm
	Enable building of the fpm SAPI executable (implies --without-apache)
--with-gmp
	Build with gmp support
--with-homebrew-curl
	Include Curl support via Homebrew
--with-homebrew-libxslt
	Include LibXSLT support via Homebrew
--with-homebrew-openssl
	Include OpenSSL support via Homebrew
--with-imap
	Include IMAP extension
--with-libmysql
	Include (old-style) libmysql support instead of mysqlnd
--with-mssql
	Include MSSQL-DB support
--with-pdo-oci
	Include Oracle databases (requries ORACLE_HOME be set)
--with-pgsql
	Include PostgreSQL support
--with-phpdbg
	Enable building of the phpdbg SAPI executable (PHP 5.4 and above)
--with-thread-safety
	Build with thread safety
--with-tidy
	Include Tidy support
--without-bz2
	Build without bz2 support
--without-mysql
	Remove MySQL/MariaDB support
--without-pcntl
	Build without Process Control support
--without-pear
	Build without PEAR
--without-snmp
	Build without SNMP support
--HEAD
	install HEAD version

Ik heb vervolgens PHP 5.6 geïnstalleerd met de volgende opties:

brew install php56 --with-debug --with-fpm --with-homebrew-curl --with-homebrew-libxslt --with-homebrew-openssl

Zodra de installatie is voltooid kun je via het volgende commando controleren of de juiste PHP versie is geïnstalleerd;

php -v

Vervolgens kun je met het volgende commando controleren welke modules er actief zijn:

php -m

PHP-extensies

Er zijn binnen Brew flink wat PHP-extensies beschikbaar, deze kun je met het volgende commando weergeven:

brew search php56-

Hieronder vind je een aantal handige PHP-extensies ik geïnstalleerd heb.

Xdebug

Xdebug is een PHP-extensie die debugging functionaliteiten toevoegt, om dit te installeren kan het volgende commando uitgevoerd worden:

brew install php56-xdebug

Tidy

brew install php56-tidy

PHP-FPM

Om PHP-FPM op te starten dienen de volgende commando’s uitgevoerd te worden:

ln -sfv /usr/local/opt/php56/*.plist ~/Library/LaunchAgents
launchctl load ~/Library/LaunchAgents/homebrew.mxcl.php56.plist

Met behulp van het volgende commando kan vervolgens bekeken worden of PHP-FPM luistert naar poort 9000.

lsof -Pni4 | grep LISTEN | grep php

MariaDB

Ook MariaDB kan via Homebrew geïnstalleerd worden met behulp van het volgende commando:

brew install mariadb

Als het goed is gaat Homebrew vervolgens MariaDB installeren en vermeld het de volgende kanttekeningen:

To have launchd start mariadb at login:
    ln -sfv /usr/local/opt/mariadb/*.plist ~/Library/LaunchAgents
Then to load mariadb now:
    launchctl load ~/Library/LaunchAgents/homebrew.mxcl.mariadb.plist
Or, if you don't want/need launchctl, you can just run:
    mysql.server start

Aangezien MariaDB van mij opgestart mag worden bij het inloggen heb ik vervolgens het volgende commando uitgevoerd:

ln -sfv /usr/local/opt/mariadb/*.plist ~/Library/LaunchAgents

Om MariaDB na installatie op te starten heb ik het volgende commando uitgevoerd:

launchctl load ~/Library/LaunchAgents/homebrew.mxcl.mariadb.plist

Om de MySQL installatie te beveiligen kan het volgende commando uitgevoerd worden:

mysql_secure_installation

Mocht je je root wachtwoord vergeten zijn dan kun je de volgende pagina van MariaDB volgen: https://mariadb.com/blog/how-reset-root-password-mariadb-linux.

Mocht je eerder al MySQL geïnstalleerd hebben dan kun je via de volgende stappen MySQL verwijderen: http://stackoverflow.com/questions/1436425/how-do-you-uninstall-mysql-from-mac-os-x.

phpMyAdmin

Voor het installeren van phpMyAdmin kan het volgende commando uitgevoerd worden:

brew install phpmyadmin

Na de installatie zal Homebrew de volgende kanttekeningen melden:

Note that this formula will NOT install mysql. It is not
required since you might want to get connected to a remote
database server.

Webserver configuration example (add this at the end of
your /etc/apache2/httpd.conf for instance) :
  Alias /phpmyadmin /usr/local/share/phpmyadmin
  
    Options Indexes FollowSymLinks MultiViews
    AllowOverride All
    Order allow,deny
    Allow from all
  
Then, open http://localhost/phpmyadmin

More documentation : file:///usr/local/Cellar/phpmyadmin/4.2.8/share/phpmyadmin/doc/

Configuration has been copied to /usr/local/etc/phpmyadmin.config.inc.php
Don't forget to:
  - change your secret blowfish
  - uncomment the configuration lines (pma, pmapass ...)

Apache uitschakelen

Binnen een Mac wordt Apache vaak standaard opgestart, met het volgende commando kan Apache uitgeschakeld worden:

sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist

Bron: http://stackoverflow.com/a/20439859

Nginx

Nginx kan geïnstalleerd worden met het volgende commando:

brew install nginx

Na de installatie zal Homebrew de volgende kanttekeningen melden:

Docroot is: /usr/local/var/www

The default port has been set in /usr/local/etc/nginx/nginx.conf to 8080 so that
nginx can run without sudo.

To have launchd start nginx at login:
    ln -sfv /usr/local/opt/nginx/*.plist ~/Library/LaunchAgents
Then to load nginx now:
    launchctl load ~/Library/LaunchAgents/homebrew.mxcl.nginx.plist
Or, if you don't want/need launchctl, you can just run:
    nginx

Na installatie zal er een standaard Nginx configuratie bestand ingesteld zijn. Aangezien in dit bestand veel commentaar staat is het niet heel overzichtelijk. Daarom verwijderen we dit bestand volledig en voegen we een eigen configuratie bestand toe.

rm /usr/local/etc/nginx/nginx.conf
nano /usr/local/etc/nginx/nginx.conf

In het nieuwe configuratie bestand plaatsen we het volgende:

worker_processes  1;
 
error_log  /usr/local/etc/nginx/logs/error.log debug;
 
events {
    worker_connections  256;
}
 
http {
    include             mime.types;
    default_type        application/octet-stream;
 
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
 
    access_log  /usr/local/etc/nginx/logs/access.log  main;
 
    sendfile            on;
 
    keepalive_timeout   65;
 
    index index.html index.php;
 
    include /usr/local/etc/nginx/sites-enabled/*; 
}

Op de Nginx documentatie websites staat meer informatie over de verschillende directives:

Voor de logs en configuratie bestanden maken we een aantal maken aan:

mkdir -p /usr/local/etc/nginx/logs
mkdir -p /usr/local/etc/nginx/sites-available
mkdir -p /usr/local/etc/nginx/sites-enabled
mkdir -p /usr/local/etc/nginx/conf.d

Composer

brew install composer

WP-CLI

brew install wp-cli

 

Dnsmasq

Met behulp van Dnsmasq kunnen we er voor zorgen dat elk request naar bijvoorbeeld .dev domeinnamen doorverwezen worden naar je lokale IP-adres 127.0.0.1. Hiermee hoef je dus niet voor elke ontwikkelomgeving een extra regel toe te voegen aan je host bestand (/etc/hosts).

brew install dnsmasq

Na het installeren van Dnsmasq geeft Brew de volgende kanttekeningen:

To configure dnsmasq, copy the example configuration to /usr/local/etc/dnsmasq.conf
and edit to taste.

  cp /usr/local/opt/dnsmasq/dnsmasq.conf.example /usr/local/etc/dnsmasq.conf

To have launchd start dnsmasq at startup:
    sudo cp -fv /usr/local/opt/dnsmasq/*.plist /Library/LaunchDaemons
Then to load dnsmasq now:
    sudo launchctl load /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist

t

Bronnen

Website controleren op virus

Veel website ontwikkelaars zullen wel eens een website in beheer hebben gehad die geïnfecteerd is geraakt met een virus. Na het opschonen van een website kan met online tools gecontroleerd worden of de website nog gemarkeerd wordt als onveilig of geïnfecteerd. Een aantal populaire online tools zijn:

 

PHP CodeSniffer en WordPress Coding Standards

Als WordPress ontwikkelaar volg ik ook graag de WordPress Coding Standards in de WordPress plugins en thema’s die ik ontwikkel. Ook bij Pronamic, het bedrijf waar ik voor werk, volgen we strikt deze standaarden. Sinds kort gebruik ik PHP CodeSniffer en de WordPress Coding Standards sniffs om projecten te controleren op de WordPress Coding Standards.

Op een Mac kan met behulp van Brew eenvoudig de PHP CodeSniffer package geïnstalleerd worden. Hiervoor kan de volgende commando in de Terminal uitgevoerd worden:

$ brew install php-code-sniffer

Als de installatie is voltooid kan met de volgende commando gecontroleerd worden welke versie van PHP CodeSniffer is geïnstalleerd.

$ phpcs --version
PHP_CodeSniffer version 1.5.2 (stable) by Squiz (http://www.squiz.net)

Vervolgens kan met het volgende commando gecontroleerd worden welke PHP CodeSniffer standaarden zijn geïnstalleerd.

$ phpcs -i
The installed coding standards are MySource, PEAR, PHPCS, PSR1, PSR2, Squiz and Zend

Standaard worden de WordPress Coding Standards sniffs niet meegeleverd in de PHP CodeSniffer package. De WordPress Coding Standards zijn echter eenvoudig te installeren via de volgende commando:

$ git clone git://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards.git /usr/local/Cellar/php-code-sniffer/1.5.2/CodeSniffer/Standards/WordPress

Als goed is staat hierna “WordPress” tussen de lijst met de geïnstalleerde PHP CodeSniffer standaarden.

$ phpcs -i
The installed coding standards are MySource, PEAR, PHPCS, PSR1, PSR2, Squiz, WordPress and Zend

Standaard zal er gebruik gemaakt worden van de WordPress Coding Standards in de ‘master’ branche. De ‘develop’ branche is echter veel interessanter, daarom is het interessant om over te schakelen naar de de ‘develop’ branche. Hiervoor kunnen de volgende commando’s uitgevoerd worden:

$ cd /usr/local/Cellar/php-code-sniffer/1.5.2/CodeSniffer/Standards/WordPress
$ git checkout develop

Hierna kan een WordPress thema of plugin met de volgende commando gecontroleerd worden op de WordPress Coding Standards:

$ phpcs -p -s -v --standard=WordPress .

Zelf maak ik veel gebruik van Grunt om ontwikkel taken verder te automatiseren. Er is een Grunt PHP CodeSniffer taak beschikbaar die hierbij van pas komt. Deze taak kan met de volgende commando geïnstalleerd worden.

$ npm install grunt-phpcs --save-dev

Binnen de Pronamic iDEAL plugin is te zien hoe we ‘phpcs’ Grunt taak verder hebben geconfigureerd. We gebruiken daar ook een “phpcs.ruleset.xml” bestand om een aantal mappen/bestanden en sniffs uit te schakelen.

Pronamic iDEAL – OmniKassa conflict met Yoast SSL tip

Vandaag heb ik een probleem onderzocht waarbij de betalingsstatus updates van de OmniKassa niet binnen kwamen op de WordPress omgeving. Hierdoor werd de status van de betaling niet bijgewerkt en in het geval van WooCommerce de status van de bestelling ook niet. Al snel bleek dat dit probleem beperkt was tot de specifieke WordPress installatie van een Pronamic iDEAL gebruiker. Na wat debug werk bleek een SSL-forceer script van Yoast voor een conflict te zorgen.

Binnen de Pronamic iDEAL plugin wordt ingehaakt op de WordPress ‘template_redirect’ actie om te luisteren naar OmniKassa betalingsstatus requests:


https://github.com/pronamic/wp-pronamic-ideal/blob/2.4.3/classes/Pronamic/WordPress/IDeal/Plugin.php#L86

De luisterfunctie van de Pronamic iDEAL plugin haakt in op de ‘template_redirect’ actie met de standaard prioriteit van 10. Yoast zijn SSL-forceer functie wordt in zijn voorbeeld toegevoegd met prioriteit van 1. Hierdoor zal Yoast zijn functie altijd voor de Pronamic iDEAL plugin uitgevoerd worden. Doordat Yoast in zijn functie een HTTP-redirect header verstuurd en vervolgens het script stopt met een exit(); aanroep zal de Pronamic iDEAL luisterfunctie nooit uitgevoerd worden.

Door Yoast zijn doorverwijzing naar een https:// URL zal de OmniKassa POST-data niet meegestuurd worden. Hierdoor zal de betalingsstatus update van de OmniKassa dus nooit de Pronamic iDEAL plugin bereiken.

Om dit conflict op te lossen hebben we de Pronamic iDEAL pluign aangepast zodat deze niet langer de ‘template_redirect’ actie gebruikt om te luisteren naar betalingsstatus updates. In plaats daarvan gebruiken we nu de ‘wp_loaded’ actie.

De ‘wp_loaded’ actie wordt eerder uitgevoerd dan de ‘template_redirect’ actie, hierdoor krijgt de Pronamic iDEAL plugin voorrang op de SSL-forceer functie van Yoast. Ook is de ‘wp_loaded’ functie waarschijnlijk geschikter voor het luisteren naar betalingsstatus updates. De ‘template_redirect’ functie is waarschijnlijk ook meer bedoeld voor thema/templates gerelateerde doorverwijzingen. In de volgende commit is de aanpassing terug te zien:

https://github.com/pronamic/wp-pronamic-ideal/commit/0e6633bb1fe024e3566fcc91955f2dcc9fe17809

WordPress oEmbed en de Vimeo API (Froogaloop)

De videoplayer van Vimeo kan met behulp van JavaScript aangestuurd worden. Op de JavaScript API pagina van Vimeo is hier meer informatie over te vinden. Ook is de kleine JavaScript bibliotheek Froogaloop erg handig om hiervoor te gebruiken.

Om gebruik van te maken van de Vimeo JavaScript API moet echter de embed code aangepast worden. Ze moet de video van de URL in de iframe uitgebreid worden met een ‘api’ parameter.

http://player.vimeo.com/video/VIDEO_ID?api=1

Als je meerdere URL’s op 1 pagina hebt ingevoerd moet daar ook nog een ‘player_id’ parameter aan toegevoegd worden:

http://player.vimeo.com/video/VIDEO_ID?api=1&player_id=vimeoplayer

Helaas ondersteund WordPress en Vimeo oEmbed deze parameters nog niet. Dit is echter eenvoudig te corrigeren met behulp van de volgende fiter functies. Met behulp van de eerste filter voegen we de ‘api’ en ‘player_id’ parameter toe aan de video URL:

In de tweede filter functie zorgen we dat het ‘iframe’ element dezelfde ‘id’ attribuut krijgt als de ‘player_id':

Vervolgens kunnen we de volgende shortcode gebruiken om gebruik te maken van WordPress oEmbed en de Vimeo API en player ID:

[embed player_id="uniqid"]http://vimeo.com/31215588[/embed]

Van fouten kun je veel leren

Een paar weken geleden kwam ik het blog bericht “Mistakes I’ve Made (And Lessons Learned Along The Way)” van op Smashing Magazine tegen. In zijn blog schrijft hij over fouten die hij gemaakt heeft en wat hij daar van geleerd heeft. Ik denk dat veel van deze fouten worden gemaakt door bedrijven. Voor mij als ontwikkelaar bij Pronamic daarom ook zeker een leerzaam bericht.

Fout #1: Voortgang belangrijker vinden dan projecten (en personen)

Jeremy verteld in zijn blog over een project waarbij hij minder goed kon opschieten met de opdrachtgever. Om het project wel in goede banen te leiden hield hij zich vast aan een proces. Dit kwam de samenwerking met de opdrachtgever echter niet ten goede.

Fout #2: Vertellen in plaats van laten zien

Veel bedrijven vertellen hoe fantastisch hun product en/of dienst is. Dit terwijl iedereen het spreekwoord “Praatjes vullen geen gaatjes” kent. Door klanten niet te laten zien hoe het product kunnen er verkeerde verwachtingen ontstaan. Dit is eenvoudig te voorkomen door het product of dienst te laten zien.

Jermey behandeld in zijn blog bericht nog een 3-tal fouten waarvan hij geleerd heeft:http://www.smashingmagazine.com/2013/07/26/mistakes-made-lessons-learned/

Een succesvolle Git vertakking model

Op mijn werk bij Pronamic maken we al enige tijd gebruik van Git voor het bijhouden van ontwikkelingen in een versiebeheersysteem. We werkten hierbij voornamelijk met één tak, de ‘master’ branch. Sinds ons team echter is versterk met een extra ontwikkelaar bleek dit echter niet altijd meer even handig te werken. Collega Leon stelde daarom voor om te gaan werken volgens het branching model van Vincent Driessen.

Vicent heeft een eenvoudige en logische manier van vertakken binnen Git in kaart gebracht. Hieronder is een mooi overzicht te zien van hoe het vertakken in de praktijk gebruikt kan worden:

Git branche model