Categorie archief: PHP

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 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.

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:

WooCommerce 2.1 ‘Toevoegen aan winkelwagen’ tekst wijzigen

In het bericht “WooCommerce ‘Toevoegen aan winkelwagen’ tekst wijzigen” beschrijf ik hoe binnen WooCommerce de ‘Toevoegen aan winkelwagen’ tekst gewijzigd kan worden. Helaas heeft WooThemes in versie 2.1 van de WooCommerce plugin wijzigingen doorgevoerd waardoor deze oplossing niet meer werkt.

Vanaf WooCommerce 2.1 is namelijk de ‘add_to_cart_text’ filter verwijderd:
https://github.com/woothemes/woocommerce/blob/v2.0.20/templates/loop/add-to-cart.php#L46

In plaats daarvan is er in WooCommerce 2.1 de ‘woocommerce_product_single_add_to_cart_text’ filter:
https://github.com/woothemes/woocommerce/blob/v2.1.0/includes/abstracts/abstract-wc-product.php#L449

function prefix_add_to_cart_text( $text ) {
	$text = __( 'Add', 'text_domain' );

	return $text;
}

add_filter( 'woocommerce_product_single_add_to_cart_text', 'prefix_add_to_cart_text' );

Bovenstaande code kan toegevoegd worden aan het WordPress functies thema bestand (functions.php). Vaak kan de code zonder problemen aan het eind van dit bestand toegevoegd worden. Als je niet werkt met een maatwerk thema dan kan het overigens handig zijn om deze toevoeging binnen een child thema of plugin te definiëren. Op die manier kun je zonder problemen je thema blijven bijwerken.

Tekst Filter GitHub
Add to cart woocommerce_product_single_add_to_cart_text GitHub
Read more woocommerce_product_add_to_cart_text GitHub

iDEAL Advanced probleem met OpenSSL 1.0.1e 11 Feb 2013

Vandaag liep ik tegen een configuratie probleem aan binnen de “Pronamic iDEAL” plugin in combinatie met de “ING – iDEAL Advanced” oplossing. Na het generen en uploaden van een privé sleutel en certificaat kon de Pronamic iDEAL configuratie niet meer getoond worden. De iDEAL pagina werd zonder foutmelding volledig afgebroken. Na debug werk kwamen we tot de ontdekking dat het vast liep binnen de volgende functie:

https://github.com/pronamic/wp-pronamic-ideal/blob/2.4.2/includes/xmlseclibs/xmlseclibs-ing.php#L484

of

https://github.com/pronamic/wp-pronamic-ideal/blob/2.4.2/includes/xmlseclibs/xmlseclibs.php#L479

Binnen deze functie worden de XML berichten die verstuurd worden naar de iDEAL Advanced provider gesigneerd. Op deze manier kan de bank verifiëren dat het verzoek van de juiste partij vandaan komt. Het signeren van XML berichten wordt gedaan met behulp van de OpenSSL bibliotheek. Deze bibliotheek is gericht op het versleutelen van te versturen gegevens.

Het is bekend dat voor de iDEAL Advanced oplossing minimaal OpenSSL versie “OpenSSL 0.9.7f” is in verband met SHA256 ondersteuning. Om die reden heb ik direct de OpenSSL versie gecontroleerd. Op de betreffende hosting omgeving van TransIP blijkt momenteel OpenSSL versie “1.0.1e 11 Feb 2013″ te draaien. Voor zover mij bekend draaien de meeste hosting omgevingen nog op OpenSSL versie “0.9.8y 5 Feb 2013″, maar blijkbaar is TransIP al een stapje verder.

Na het probleem verder onderzocht te hebben leek het probleem zich te beperken tot de specifieke OpenSSL versie:

  • OpenSSL 0.9.8y 5 Feb 2013 » werkt wel
  • OpenSSL 1.0.1e 11 Feb 2013 » werkt niet
  • OpenSSL 1.0.1f 6 Jan 2014 » werkt wel

Ik vermoed dan ook dat in de betreffende OpenSSL versie een fout is ontstaan. Hierdoor kunnen de iDEAL Advanced berichten niet gesingeerd worden en zal iDEAL Advanced oplossing niet functioneren in combinatie met deze OpenSSL versie. Ik heb hierover telefonisch contact gehad met de ING Bank, maar helaas hebben ze mijn bevindingen nog niet kunnen verifiëren.

Hopelijk kan TransIP het probleem oplossen door de OpenSSL bibliotheek te up- en/of downgraden. Het zou immers jammer zijn als je bij TransIP niet de populaire iDEAL-betaalmethode kunt aanbieden. Mocht iemand overigens succesvol iDEAL Advanced gebruiken in combinatie met OpenSSL 1.0.1e 11 Feb 2013 dan hoor ik het graag.

WooCommerce ‘Sale!’ tekst wijzigen

In het bericht “WooCommerce ‘Toevoegen aan winkelwagen’ tekst wijzigen” beschreef ik al hoe de “Toevoegen aan winkelwagen” tekst gewijzigd kan worden. In dit bericht is te lezen hoe de “Sale!” tekst gewijzigd kan worden.

WooCommerce "Sale!" tekst wijzigen

De WooCommerce ontwikkelaars passen de filter ‘woocommerce_sale_flash’ toe op de “Sale!” tekst waardoor deze eenvoudig is aan te passen. In onderstaande code fragment is te zien hoe dit gerealiseerd kan worden:

Bovenstaande code kan toegevoegd worden aan het WordPress functies thema bestand (functions.php). Vaak kan de code zonder problemen aan het eind van dit bestand toegevoegd worden. Als je niet werkt met een maatwerk thema dan kan het overigens handig zijn om deze toevoeging binnen een child thema of plugin te definiëren. Op die manier kun je zonder problemen je thema blijven updaten.

PHP private/protected eigenschappen aanpassen

Binnnen de Pronamic iDEAL plugin breiden we verschillende WordPress plugins uit met de iDEAL gateway. Zo voorzien we ook de Shopp webwinkel plugin voor WordPress van een iDEAL gateway module.

De Shopp ontwikkelaars hebben het echter niet eenvoudig gemaakt om vanuit een andere WordPress plugin betalingsgateways toe te voegen. In de Pronamic iDEAL plugin moeten we daarom op een omslachtige manier te werken gaan om dit toch te realiseren.

Hoe we dit gerealiseerd hebben voor Shopp versie 1.0 tot 1.2.9 is te zien in het volgende Pronamic iDEAL bestand:

https://github.com/pronamic/wp-pronamic-ideal/blob/2.3.1/classes/Pronamic/Shopp/IDeal/AddOn.php#L51

In de recente gelanceerde Shopp versie 1.3 functioneerde deze code echter niet meer correct. De Shopp ontwikkelaars hebben in het inladen van modules namelijk flink over de kop gegooid. Na de Shopp code van versie 1.3 helemaal doorgelopen hadden kwamen we al snel tot de conclusie dat de Shopp ontwikkelaars het ons vrij lastig hebben gemaakt.

De Shopp ontwikkelaars hebben vrijwel geen WordPress filters of acties beschikbaar gesteld om betalingsgateways vanaf andere locaties in te laden.  Wel worden binnen Shopp betalingsgateways nu vanaf 2 loacties ingeladen, namelijk:

  • /wp-content/plugins/shopp/gateways
  • /wp-content/shopp-addons

https://github.com/ingenesis/shopp/blob/1.3/core/model/Gateway.php#L453

Nu zou je denken dat daar dan eenvoudig een 3e locatie aan toegevoegd kan worden, maar dat was helaas niet het geval. De paden waren de betalingsgateways vanuit worden geladen stonden namelijk vast in de code en kunnen niet aangepast worden.

Uiteindelijk kwamen op het idee om de paden uit te breiden met behulp van de PHP Refelection bibliotheek. Met behulp van deze bibliotheek is het mogelijk om niet toegankelijke eigenschappen van classes/objecten wel toegankelijk te maken.

Via de volgende code konden we zo een nieuwe gateway moduels locatie toevoegen aan de Shopp plugin:

global $Shopp;

$class = new ReflectionClass( 'GatewayModules' );

$property = $class->getProperty( 'paths' );
$property->setAccessible( true );

$paths = $property->getValue( $Shopp->Gateways );
// @see https://github.com/ingenesis/shopp/blob/1.3/Shopp.php#L193
$paths[] = Pronamic_WordPress_IDeal_Plugin::$dirname . '/classes/Pronamic/Shopp/Gateways';

$property->setValue( $Shopp->Gateways, $paths );

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]