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

PHP_CodeSniffer 2.0.0 gebruiken op Mac

Op 5 december kondigde Squiz Labs de release van PHP_CodeSniffer 2.0.0 aan. Met deze nieuwe versie van PHP_CodeSniffer is het mogelijk om fouten automatisch te corrigeren. Met behulp van Brew kan eenvoudig PHP_CodeSniffer 2.0.0 geïnstalleerd worden. Hiervoor dient het volgende commando uitgevoerd te worden in de terminal.

brew install php-code-sniffer --devel

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.