PHPUnit en WordPress plugins

In het bericht “Unit tests voor WordPress plugins” uit juni 2013 schreef ik al eerder over unit testing voor WordPress plugins. In dit bericht een korte update over hoe je PHPUnit in 2014 voor WordPress plugins kunt inrichten.

In het WordPress.org core handboek staat in het artikel “Automated Testing” meer informatie over unit testing en WordPress. In dit artikel staat onder andere beschreven hoe je WordPress test suite kunt uitvoeren.

cd ~/Projects
svn co https://develop.svn.wordpress.org/trunk/ wordpress-develop

Zodra je het ‘wordpress-develop’ project op je lokale computer hebt staan dien je nog een database aan te maken en het ‘wp-tests-config.php’ te voorzien van de juiste gegevens.

Vervolgens kun je .bash_profile bestand bewerken met behulp van het volgende commando:

nano ~/.bash_profile

En het volgende toevoegen:

# WordPress tests
export WP_TESTS_DIR=~/Projects/wordpress-develop/tests/phpunit

Op deze manier weet Bash ook waar je WordPress tests map staat. Vervolgens kun je in je WordPress plugin een PHPUnit XML-bestand aanmaken.

<?xml version="1.0" encoding="UTF-8"?>

<phpunit
 bootstrap="tests/bootstrap.php"
 colors="true"
>
 <testsuites>
 <testsuite name="WordPress Plugins Test Suite">
 <directory>./tests/</directory>
 </testsuite>
 </testsuites>

 <filter>
 <whitelist>
 <directory>./src</directory>
 </whitelist>
 </filter>

 <logging>
 <log type="coverage-clover" target="build/logs/clover.xml"/>
 </logging>
</phpunit>

In de ‘tests’ map binnen je WordPress plugin kan vervolgens een ‘bootstrap.php’ bestand neergezet worden met de volgende inhoud:

<?php

$_tests_dir = getenv( 'WP_TESTS_DIR' );
if ( ! $_tests_dir ) {
 $_tests_dir = '/tmp/wordpress-tests-lib';
}

require_once $_tests_dir . '/includes/functions.php';

require_once __DIR__ . '/../vendor/autoload.php';

require $_tests_dir . '/includes/bootstrap.php';

Een voorbeeld van deze test setup is terug te vinden in een aantal van de WordPress Pay gateways bibliotheken.

https://github.com/wp-pay-gateways

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

Mijn MacBook Pro installatie

In dit bericht zal ik kort samenvatten hoe mijn MacBook Pro installatie er uit ziet qua programma’s, tools, addons, etc..

Webbrowsers

  • Google Chrome [standaard]
    • LastPass
    • AdBlock Plus
  • Firefox
    • LastPass
    • AdBlock Plus
    • Firebug
  • Opera
    • LastPass
  • Safari
    • LastPass

Productiviteit

  • Evernote
  • Dropbox
  • Alfred 2

Entertainment

  • Spotify
  • VLC

Ontwikkeling

  • iTerm2
  • Sublime Text 3
  • Java SE Development Kit
  • Eclipse
    • PHP Development Tools (PDT)
    • Preferences
      • PHP » Editor » Save Actions » ✓ Remove trailing whitespace » All lines
  •  SourceTree
    • Project folder: /Users/remco/Projects
    • Terminal App: iTerm2
    • Taal: English
  • FileZilla
    • Thema: Classic
  • Poedit
  • Homebrew
  • Node.js
    • brew install node
  • Git
    • brew install git
  • PHP
    • brew tap homebrew/dupes
    • brew tap homebrew/versions
    • brew tap homebrew/homebrew-php
    • brew install php56
  • PHP CodeSniffer
    • brew install php-code-sniffer
  • WordPress Coding Standards
    • https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards
  •  Grunt
    • npm install -g grunt-cli
    • npm install -g npm-check-updates
  • Xcode
  • VirtualBox
    • https://github.com/xdissent/ievms

Communicatie

  • Adium
  • Skype
  • Twitter

Overige

  • ScanSnap
    • ABBYY FineReader for ScanSnap
  • uTorrent
  • The Unarchiver
  • QFinder
  • Kitabu
  • Aegisub

Bronnen

WordPress menu custom current URL class

Veel WordPress ontwikkelaars zullen wel eens tegen beperkingen van de standaard WordPress menu classes aangelopen zijn. Zo is het soms lastig om actieve menu items te benaderen bij diepere menu’s met verschillende type menu items. Zo ook bij een menu met als hoofditem een pagina en daaronder een custom post type archief link:

  • Pagina
    • Custom post type ‘Project’ archief
      • Single ‘Project’

Om er voor te zorgen dat op een single ‘Project’ de pagina ook een class krijgt gebruiken we de volgende WordPress filter functie:

Brew link autoconf » undefined method `cleanpath’

Voor het installeren van PHP Xdebug via Homebrew moest ik Autoconf linken via Homebrew. Helaas resulteerde dit in de volgende foutmelding:

$ brew link autoconf
Linking /usr/local/Cellar/autoconf/2.69... 
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/pathname.rb:486:in `relative_path_from': undefined method `cleanpath' for #<Keg:/usr/local/Cellar/autoconf/2.69> (NoMethodError)
    from /usr/local/Library/Homebrew/keg.rb:40:in `to_s'
    from /usr/local/Library/brew.rb:161:in `message'
    from /usr/local/Library/brew.rb:161:in `rescue in <main>'
    from /usr/local/Library/brew.rb:66:in `<main>'

Meestal zijn Homebrew problemen vrij eenvoudig op te lossen door de ‘brew doctor’ output tips te volgen. In dit geval kon ik via ‘brew doctor’ het probleem helaas niet oplossen.

Uiteindelijk heeft de Homebrew troubleshooting pagina me iets verder geholpen. Via het volgende commando kreeg ik een lijst van bestanden te zien die mogelijk voor problemen zorgde:

$ HOMEBREW_MAKE_JOBS=1 brew install -v autoconf 2>&1

In eerste instantie heb ik geprobeerd de rechten van deze bestanden te herstellen via de volgende commando:

$ sudo chown -R $(whoami) /usr/local

Dit loste het probleem helaas ook niet op, daarom heb ik uiteindelijk de betreffende bestanden maar compleet verwijderd. Vervolgens heb ik de Autoconf bibliotheek verwijderd en opnieuw geïnstalleerd via Homebrew.

$ brew uninstall autoconf
$ brew install autoconf

En dit keer ging de installatie van Autoconf goed zodat ik ook PHP Xdebug kon gaan installeren.

Waarschijnlijk ging er eerder toch wat verkeerd door onjuiste rechten waardoor het relatieve link pad o.i.d. niet bepaald kon worden door Homebrew.

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 “project.ruleset.xml” bestand om een aantal mappen/bestanden en sniffs uit te schakelen.

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/

Bug Yoast – Google Analytics for WordPress – the_content leeg

In de “Google Analytics for WordPress” plugin van Yoast schijnt een bug te zitten in de ‘trackoutbound’ en ‘trackcrossdomain’ functionaliteit. Yoast zorgt er binnen deze functionaliteit voor dat links worden aangepast:

Zodra we in een Gravity Forms formulier een link in een ‘Sectie-einde’ plaatsen is plotseling de output van de inhoud van de WordPress pagina/bericht leeg.

Gravity Forms - Sectie-einde met link

Na wat debug werk met een ‘the_content’ filter en de prioriteit van 0 te verhogen naar 100 kwamen we er al snel achter dat het mis ging bij de ‘the_content’ filter van Yoast zijn Google Analytics plugin.

Binnen de filter van Yoast worden links met behulp van een reguliere epxressie aangepast. Ik ben zelf  geen fan van reguliere expressies. Er zijn naar mijn idee namelijk erg weinig ontwikkelaars die goed weten hoe reguliere expressies werken. Daardoor zijn ze lastig in beheer en is een fout snel gemaakt. Ik probeer ze daarom zelf altijd te vermijden.

In dit geval zal er waarschijnlijk ook een fout in de plugin van Yoast zitten, waardoor de complete content van een bericht/pagina leeg wordt gemaakt. Hopelijk kan dit probleem opgelost worden in een toekomstige release. Een controle op de lengte van de content na het wijzigen van de links zou misschien ook slim kunnen zijn. De content zou immers niet korter moet worden, als dat wel het geval is is er waarschijnlijk wat fout gegaan.

WordPress plugins en Grunt

Met behulp van Grunt is het mogelijk om bepaalde taken bij het ontwikkelen van bijvoorbeeld software te automatiseren. Ook bij het ontwikkelen van WordPress plugins kan Grunt handig zijn, zo heb ik vandaag de WordPress plugin “Pronamic iDEAL” uitgebreid met een Gruntfile. Momenteel zorgt Grunt er voor dat de JavaScript bestanden automatisch gecontroleerd worden op kwaliteit met JSLint. Ook worden alle PHP bestanden automatisch gecontroleerd met PHPLint. Aanvullend wordt ook automatisch de PHPUnit tests uitgevoerd.

De Gruntfile voor de “Pronamic iDEAL” plugin is te vinden op de GitHib repository:
https://github.com/pronamic/wp-pronamic-ideal/blob/develop/Gruntfile.js

Handige resources hierbij waren: