Brew update PHP 5.6 tidy: Unable to initialize module

Na het update van Brew pakketten liep ik tegen de volgende foutmelding aan:

PHP Warning: PHP Startup: tidy: Unable to initialize module
Module compiled with build ID=API20131226,NTS
PHP compiled with build ID=API20131226,NTS,debug
These options need to match
 in Unknown on line 0

Dergelijke problemen zijn vaak eenvoudig op te lossen door pakketten even opnieuw te installeren vanuit de bron:

brew reinstall php56-tidy --build-from-source

HostGator cURL outdated, disappointing support

Today i came in contact with an Pronamic IDEAL plugin user who was getting “Problem with the SSL CA cert (path? access rights?)” errors. The website was hosted at HostGator and after a quick Google search I noticed that more WordPress users had similar issues. The problems are caused by an outdated cURL library version 7.19.7. I requested HostGator to update to the latest stable version of cURL but their support doesn’t really help.

I think it’s very clear that the cURL library is outdated and needs an update. HostGator support however requires me to send the billing details of our client. How will the billing details help to get cURL updated? Since I don’t have these details HostGator support is not really helping. The helpdesk also forwarded me to their “What Software and Program Versions Does HostGator Offer?” page. On this page HostGator clients can read that they run cURL version 7.15.x:

cURL 7.15.x (also libcurl and PHP/CURL)

Right after that the helpdesk is saying:

We do our best to keep software and program versions as up to date as possible. Our technical team regularly evaluates software updates and pushes updates across HostGator’s servers as they are deemed secure and appropriate for HostGator’s shared hosting environment.

How credible is that since cURL version 7.15 was launched 8.9 years ago? Below you can find the whole chat conversation with HostGator. I don’t have further experience with HostGator but my advice would be to not host at HostGator.

Chat ID: 14642039.
Question: Problem with the SSL CA cert (path? access rights?)

(1:30:55pm) System: Customer has entered chat and is waiting for an agent.

(1:31:49pm) William L.: Hello and welcome to Hostgator LiveChat. My name is William and I’d be glad to assist you with any questions you may have today. How are you?

(1:33:29pm) Remco: Hello William, i’m good. Only have an issue on http://**********.com/ with remote request to an https:// URL. We use WordPress and are getting an HTTP request failed error.

“Problem with the SSL CA cert (path? access rights?)

(1:34:11pm) Remco: Did soms research on Google and see other users of Hostgator had also this issue

(1:34:14pm) Remco: https://wordpress.org/support/topic/http-error-problem-with-the-ssl-ca-cert-path-access-rights

(1:34:18pm) Remco: https://wordpress.org/support/topic/http-error-problem-with-the-ssl-ca-cert-path-access-rights-1

(1:34:47pm) Remco: I quote: “Asking Hostgator to update CURL to the latest stable version will fix this issue, it’s an easy thing for a host to do. A hosting company that size should know what to do..”

(1:35:45pm) William L.: For security reasons, before I am allowed to make changes or provide information to a user’s account, I am required to verify that this is the owner of the account. Please enter your billing login information in the verification box. Thank you.

(1:37:15pm) Remco: I’m not the owner of this account, i’m contacting you on behalf of our client. She however already had contact about this earlier.

(1:37:16pm) William L.: May I have your primary email address on account please?

(1:37:39pm) William L.: Unfortunately, in order to further investigate, I will need full verification in order to proceed to look into this.

(1:38:51pm) Remco: Our client doesn’t have an technical background… so it’s a bit hard for her to give you all the details. I think it’s clear that you have to update the cURL library. I don’t see why you need full verification for this…

(1:39:45pm) William L.: Okay. Regardless, I would still need the full verification details so I can pull up your account, as well as seeing if there is a SSL installed on the site itself.

(1:40:03pm) William L.: I apologized for the trouble but it would be required.

(1:40:14pm) William L.: All i need would only be the email address on account and the password.

(1:40:38pm) Remco: Ok, i have the e-mailadress ******@**********.com

(1:40:55pm) Remco: And the following details

(1:40:58pm) Remco: https://*********.hostgator.com:2083 <https://*********.hostgator.com:2083/>
User: ********
Password: ***********

(1:41:23pm) William L.: May I have your account security pin please? It is a 4 to 8 digits when you first registered for this account.

(1:42:01pm) Remco: I don’t have that information, you just said you would only need the email address and the password :).

(1:42:29pm) William L.: The password would refer to the billing password.

(1:42:31pm) William L.: Do you have that as well?

(1:42:36pm) William L.: If so, I will re-send the pop up box.

(1:42:45pm) William L.: The security pin is an alternative method of verifying for the account fully.

(1:42:50pm) Remco: Nope, this is all the information i have.

(1:43:03pm) William L.: Sure. Let me see what I can do with those information. Just a moment.

(1:45:18pm) William L.: May I ask what plugin are you attempting to use for the remote request to the HTTPS:// URL?

(1:46:01pm)Remco:The “Pronamic iDEAL” plugin… for an Dutch payment provider connection

(1:46:25pm) William L.: Thank you, Remco.

(1:46:31pm) William L.: Please bear me with a few minutes over here.

(1:50:36pm) William L.: In order to update curl, unfortunately you would need root access to complete this. As such you will want to look into upgrading to a VPS ( http://www.hostgator.com/vps-hosting/ ) or dedicated server ( http://www.hostgator.com/dedicated ) if this is something that is mission critical for you. I apologize for any inconvenience this has caused you.

You would either need to contact with the plugin developer in regards of such issue or update your server package to a VPS or a dedicated server in order to update cURL to the latest and stable version.

(1:52:52pm) Remco: Hmm, and why don’t you update cURL on this server to the latest and stable version? There is a bug in cURL version 7.19.7 so i think it’s your responsibility to update to fix the issue.

(1:55:16pm) William L.: I will be able to request of such for you. However, in order to do so, I will need to fully verify you. Are you able to obtain the billing password, or security pin?

(1:57:35pm) Remco: I probably can obtain this information, but again i don’t see why you need this. The cURL library is outdated, you guys just have to update. Version 7.19.7 o cURL was launched in 2009, we are now 2015. Can you guarantee an update if i get this billing password?

(1:58:23pm) William L.: I will not be able to guaranteed anything as this task will be performing by our support admin, which is why verification is mandatory prior to updating curl since we are going to be performing change on account.

(2:00:38pm) Remco: Hmm, this approuch is not very client friendly… it will only delay an solution… and you can’t even guarantee an solution… since it’s very clear that the cURL library is outdated…

(2:01:54pm) William L.: http://support.hostgator.com/articles/hosting-guide/hardware-software/what-software-and-program-versions-does-hostgator-offer

cURL 7.15.x (also libcurl and PHP/CURL)

We do our best to keep software and program versions as up to date as possible. Our technical team regularly evaluates software updates and pushes updates across HostGator’s servers as they are deemed secure and appropriate for HostGator’s shared hosting environment.

(2:03:54pm) Remco: That’s not really credible, cURL version 7.15 was launched 8.9 years ago. And still you say you do your best to keep software and program version as up to date as possible?

(2:04:03pm) William L.: Okay.

(2:04:08pm) William L.: I am sorry for the frustration.

(2:04:31pm) William L.: If you would like to proceed, please provide the billing details as the verification method and I would have this ticket generate for you so that our admins can work on it.

(2:05:59pm) Remco: I don’t have that information now, i think you have enough details to proceed anyway…

(2:06:47pm) William L.: Remco, please understand I am attempting to assist with you. However, without the verification details, I will not be able to proceed. You can always contact us when you do have the information and we will be glad to generate the ticket for you.

(2:10:00pm) William L.: I hate to bother, are you still with me?

(2:10:14pm) Remco: Ok, i’m disappointed in the way you handle this. I will ask my client to mail you this conversation so you can proceed and hopefully fix this issue asap. I will also recommend to consider switching to another hosting company.

(2:11:19pm) William L.: I am very sorry in regards of such experience you are currently experiencing. Please understand that we take account’s security matter very seriously hence the verification process before we perform changes on account.

Is there anything else you might need assistance with?

(2:12:54pm) Remco: I understand you take account’s security matter very seriously… maybe you contact the client yourself and make sure the problem is solved… i really think your client would appreciate that!

(2:13:19pm) William L.: Absolutely. I understand. May I ask if you have any further question for me today?

(2:15:37pm) William L.: This chat will now be terminated due to inactivity. If you need anything else, please start a new live chat session. We would be glad to assist you further. Take care and have a great day!

(2:15:42pm) System: This chat has ended. Click Rate And Exit to rate the representative and our company!

After this our client contacted HostGator for the cURL update, their response:

Hello, and thank you for contacting HostGator.com,

We maintain the same version of cURL across all of our shared servers. Unfortunately, we are unable to upgrade cURL for only your account as it would affect our other customers and their sites on the server. If you need an different version of cURL, you will need to upgrade to either a VPS or a dedicated server. We recommend these for our customers who are wanting specialized setups or different versions of software on their server.

If you are interested in upgrading, I would suggest looking ove rthe types of hosting that we offer: http://support.hostgator.com/articles/hosting-guide/hosting-plan-comparison/shared-environment-vs-dedicated-environment

http://support.hostgator.com/articles/hosting-guide/hosting-plan-comparison/articles/hosting-guide/hosting-plan-comparison/how-do-i-choose-which-hosting-plan-is-right-for-me

Read more about why you need to avoid HostGator on https://yoast.com/avoid-hostgator/.

WordPress en emoji

WordPress 4.2 ondersteund nu ook emoji 😄, via OSX kun je je WordPress berichten nu in de editor met de toetsencombinatie cmd + ctrl + spatie verfraaien met smileys en andere emoji iconen.

😎

Een WordPress multisite/network omzetten naar een single WordPress installatie

Als je een WordPress site binnen een WordPress multisite/network wilt omzetten naar een individuele WordPress installatie zul je na een zoektocht op internet al snel het advies krijgen om de content te exporteren en te importeren. Dit heeft echter als nadeel dat gebruikers, instellingen, plugins, thema’s, etc. niet meegenomen worden. In de blog “The Return from Multiste” is te lezen hoe dit ook via enkele database queries gerealiseerd kan worden.

Aangezien ik veel gebruik maak van Gravity Forms, Pronamic iDEAL en Redirection moest ik nog de volgende extra queries uitvoeren:

RENAME TABLE 
OLDPRE_OLDNUM_rg_form TO NEWPRE_rg_form, 
OLDPRE_OLDNUM_rg_form_meta TO NEWPRE_rg_form_meta, 
OLDPRE_OLDNUM_rg_form_view TO NEWPRE_rg_form_view, 
OLDPRE_OLDNUM_rg_lead TO NEWPRE_rg_lead, 
OLDPRE_OLDNUM_rg_lead_detail TO NEWPRE_lead_detail, 
OLDPRE_OLDNUM_rg_lead_detail_long TO NEWPRE_lead_detail_long, 
OLDPRE_OLDNUM_rg_lead_meta TO NEWPRE_rg_lead_meta, 
OLDPRE_OLDNUM_rg_lead_notes TO NEWPRE_rg_lead_notes;
RENAME TABLE 
OLDPRE_OLDNUM_rg_ideal_feeds TO NEWPRE_rg_ideal_feeds, 
OLDPRE_OLDNUM_pronamic_ideal_configurations TO NEWPRE_pronamic_ideal_configurations, 
OLDPRE_OLDNUM_pronamic_ideal_payments TO NEWPRE_pronamic_ideal_payments;
RENAME TABLE 
OLDPRE_OLDNUM_redirection_404 TO NEWPRE_redirection_404, 
OLDPRE_OLDNUM_redirection_groups TO NEWPRE_redirection_groups,
OLDPRE_OLDNUM_redirection_items TO NEWPRE_redirection_items,
OLDPRE_OLDNUM_redirection_logs TO NEWPRE_redirection_logs,
OLDPRE_OLDNUM_redirection_modules TO NEWPRE_redirection_modules;

Daarnaast heb ik via de active_sitewide_plugins meta key in de OLDPRE_sitemeta tabel en http://www.unserialize.com/ nog even gecontroleerd welke plugins sitewide geactiveerd waren.

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

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

Website kopie maken met HTTrack

Soms wil je even een statische kopie van een website maken voor offline gebruik of als backup. Met behulp van wget kan eenvoudig een kopie gemaakt worden:

wget --mirror --convert-links --adjust-extension --page-requisites --no-parent http://example.org

De wget tool neemt echter niet altijd alle gekoppelde stylesheets, scripts, afbeeldingen, etc. mee. Om een betere kopie te krijgen kan het daarom handig zijn om gebruik te maken van HTTrack. Met behulp van brew is deze tool eenvoudig te installeren op een Mac:

brew install httrack

Vervolgens kan met het httrack commando eenvoudig een kopie van een website gemaakt worden.

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

Homebrew MariaDB MySQL server has gone away

Bij het importeren van een grote WordPress database in mijn lokale MariaDB database server liep ik tegen de volgende fout aan:

ERROR 2006 (HY000) at line 40786: MySQL server has gone away

Na wat zoeken op internet kom je al snel berichten tegen dat dit te maken heeft met de ‘max_allowed_packet‘ configuratie instelling.

Na wat zoeken heb ik in mijn gebruikersmap (~) een MySQL configuratie bestand (~/.my.cnf) aangemaakt volgens de MariaDB documentatie.

https://mariadb.com/kb/en/mariadb/documentation/getting-started/configuring-mariadb-with-mycnf/#location-in-linux-unix-mac

Door hier het volgende in te zetten is de ‘max_allowed_packet’ instelling eenvoudig te verhogen.

[mysqld]
max_allowed_packet=1073741824

Vervolgens kan MariaDB database server eenvoudig herstart worden met behulp van het volgende commando:

mysql.server restart

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