Tag Archives: php

Posted on
by

As part of (one of) my day jobs, I have had to yet again bash together a set of REST APIs. This is so we can start wiring up some proper micro services AWS style scalable architecture into the monolithic beast that is the current incarnation of the software I’m working on.

Anyway, here are a few gotchas for this if you intend to start using proper REST style HTTP verbs (PUT/PATCH/DELETE), rather than doing everything via GET and POST like most everyone.

No easy way to access variables

If you’re familiar with the standard $_POST mechanism to access passed variables, you’ll be disappointed that PHP doesn’t by default provide a nice way of access these for PUT and PATCH.

So, you’re going to have to extract them yourself. Not overly tricky, but irritating:

So, for example:

parse_str(file_get_contents('php://input'), $patch);
if (is_array($patch)) {
  $this->data = array_merge($this->data, $patch);
}

Requests not coming through

If you find that your APIs work fine on your local machine but break when deployed, you might want to check your server configuration.

It is quite common for web servers (especially on shared hosts) to block access to HTTP verbs other than most common GET and POST. Modsecurity’s default config definitely blocks these methods.

You should also check that any proxies or load balancers that you have in front of your REST endpoint. These may need some configuration tweaks as well.

Hopefully this will save you some time and frustration!

Posted on
by

PHP 7 is now out, and Travis-CI supports it as part of their standard configuration (rather than forcing you to use the PHP nightly build). Last night I submitted a pull request to add PHP 7 support to the Known Travis build, which was a little bit problematic.

Known uses Apache + PHP-FPM, rather than the Travis default nginx setup, and while there are guides for getting this working on the Travis site, it seems that they’re not quite there for the PHP 7 build.

The PHP 7 build was running into this error:

[15-Feb-2016 23:14:58] WARNING: Nothing matches the include pattern '/home/travis/.phpenv/versions/7.0.3/etc/php-fpm.d/*.conf' from /home/travis/.phpenv/versions/7.0.3/etc/php-fpm.conf at line 125.
[15-Feb-2016 23:14:58] ERROR: No pool defined. at least one pool section must be specified in config file
[15-Feb-2016 23:14:58] ERROR: failed to post process the configuration
[15-Feb-2016 23:14:58] ERROR: FPM initialization failed
/home/travis/build.sh: line 45: 25862 Segmentation fault      (core dumped) ~/.phpenv/versions/$(phpenv version-name)/sbin/php-fpm

This took a little while to diagnose, but in the end the fix was pretty simple. Basically it looks like the Travis PHP7 build of PHP-FPM expects, but can not find, a pool definition. You don’t need to customise it, just put a default one into PHP-FPM’s config directory.

So, I packaged a default template with the Known patch, and in my .travis.yml added the following to before_script:

- if [[ ${TRAVIS_PHP_VERSION:0:3} == "7.0" ]]; then sudo cp Tests/build/www.conf ~/.phpenv/versions/$(phpenv version-name)/etc/php-fpm.d/; fi

I also modified the Apache vhost example and added ServerName localhost to the definition (although this might not be needed).

After this, the build completes successfully.

PHP7 is new, so I suspect Travis will fix this shortly. However, hopefully this will prevent some hair-pulling in the mean time!