Being

Most of yesterday I was trying to update wordpress on the dev version of my photo website. The problem was that I was getting strict standards errors because the WP_Widget class has bothe PHP4 and PHP5 style constructors.

Researching this, it seems that an error should be thrown, and this is a bug in PHP. I tried rebuilding PHP a few times, but still got the same error I did last time about libgcrypt.la not being found.

So I decided to just turn off strict error reporting for the blog for the moment. But this didn't work, and I still got strict standards errors. I thought that the [PATH] and [HOST] directives in my php.ini must not be taking any effect. Looking in the PHP manual, I found a comment by someone else to a similar effect:

This doesn't seem to work with php-fpm.

The values defined under PATH or HOST will become the new master value for all the processes (as if they were redefined).

So, I looked for a different way that I could use different error reporting levels for my different sites. One solution mentioned on a few websites was .user.ini files. But I found these have no effect under php-fpm.

Next I found that you can set PHP_VALUE flags from the php-fpm config. But this can only be set per pool. So you would need to set up a different pool listening on a different socket for each website. This would create too many php processes and use up to much memory to work for me.

Then I found that you can actually set PHP_VALUE flags from nginx:

set $php_value "pcre.backtrack_limit=424242";
set $php_value "$php_value \n pcre.recursion_limit=99999";
fastcgi_param  PHP_VALUE $php_value;

fastcgi_param  PHP_ADMIN_VALUE "open_basedir=/var/www/htdocs";

However, when I tried this I found that the error_reporting level sent by Nginx seemed to be overridden by the error_reporting level set in php.ini.

I then found that you can use variables within php.ini. But the lack of nestable variables makes that not quite so useful.

I thought that in theory I should be able to have a default value in nginx.conf, like

set $php_value "error_reporting=E_ALL|E_STRICT";

and then override it in the website config, like

set $php_value "error_reporting=E_ALL";

And in php.ini remove all error_reporting directives so that the PHP_VALUE is not overridden.

But then I read that the PHP constants are not available outside of PHP, e.g. in httpd.conf. Instead you need to use the bitmask values.

So this morning I ran a test, using different numbers for [PATH] and [HOST] sections in php.ini and location sections in my site's nginx config. Result:

• PHP_VALUE in nginx config is always overridden by php.ini value.
• PHP_VALUE for location /path/ does not affect sub folders of /path/ (value set for location / is used for /path/subfolder)
• Both [HOST] and [PATH] settings in php.ini do work, and don't seem to be overridden by previous or later settings for different [HOST] and [PATH] blocks

So, why was my blog still showing strict errors when I had E_ALL|E_STRICT set for the host, but E_ALL&~E_DEPRECATED set for the blog's path? In the end it turned out to be very simple - From PHP 5.4.0 E_STRICT has been included within E_ALL. I did read this earlier, but it didn't really sink in, and I didn't think to check my PHP version.

So a lot of work for nothing really, though I did learn some new things (can set PHP_VALUEs from nginx, can use variables in php.ini).

In the afternoon I went out and took some photos.

In the evening I listened to Will Challoner (AKA Wilson Channeller AKA Wilbert AKA Wilmington) with Billy while I worked on my kodak jr. bellows camera bit.