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>

http://serverfault.com/a/270971

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

WooCommerce bestellingen met iDEAL Basic automatisch geannuleerd

Een aantal WordPress gebruikers die met WooCommerce een webwinkel hebben opgezet en een iDEAL Basic aansluiting hebben zullen opgemerkt hebben dat betaalde bestellingen soms automatisch geannuleerd worden. Dit wordt veroorzaakt een automatisch systeem van WooCommerce die bestellingen met de status ‘in afwachting’ (pending) na een bepaalde tijd annuleert.

De WooCommerce ‘woocommerce_cancel_unpaid_orders()‘ functie regelt het annuleren van bestellingen met de status ‘in afwachting’. De werking van deze functie is te beïnvloeden met 2 instellingen, namelijk de ‘Voorraadbeheer’ (Manage Stock) en ‘Voorraad behouden (minuten)’ (Hold Stock (minutes)) instellingen. Op het moment dat voorraadbeheer is ingeschakeld en het aantal minuten van het vasthouden van de voorraad groter is dan 0 zullen bestellingen de status ‘in afwachting’ automatisch geannuleerd worden.

In principe zou een succesvolle iDEAL-betaling er direct voor moeten zorgen dat de WooCommerce bestellingstatus wordt bijgewerkt van ‘in afwachting’ (pending) naar ‘in verwerking’ (processing). In het geval van iDEAL Basic gebeurd dit echter niet als bezoekers vanuit iDEAL niet terug keren naar de webwinkel. WooCommerce gebruikers die werken met de iDEAL Basic variant adviseer ik daarom om de “Voorraad behouden (minuten)” instelling uit te schakelen.

Voorraad behouden (voor onbetaalde bestellingen) voor x minuten. Wanneer deze limiet is bereikt zal de in afwachting bestelling geannuleerd worden. Laat leeg om uit te schakelen.

WooCommerce voorraadbeheer iDEAL Basic

Het is immers niet netjes als klanten na een succesvolle iDEAL-betaling een uur later de melding krijgen dat de bestelling is geannuleerd.

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

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.