Application updates for PHP containers

PHP was Platform.sh’s first supported language, and so has had a few quirks as we’ve grown to support more programming languages. Those quirks have resulted in a few limitations to functionality that we didn’t like, and you probably didn’t like, either.

Fortunately, we’ve refactored our container support to reduce the uniqueness of PHP and added a bit of functionality along the way.

There’s two main improvements for PHP containers and one small change.

.environment

On all languages, we now support an extra configuration file named  .environment , which should be at the top-level of an application (as a sibling of the  .platform.app.yaml  file in a multi-app setup). This file will get sourced as a bash script by the system when a container boots up, as well as on all SSH logins. The main use for it is to set extra environment variables or modify the PATH. The latter case is useful to allow tools like Drush, Drupal Console, or the Symfony Console to be installed locally by Composer but still available to execute without explicitly specifying a full path name.

See the documentation for more details.

web.commands.start

In Node.js, Ruby, and Python, there are several application runners available such as uwsgi and gunicorn for Python, Unicorn for Ruby, and pm2 for Node.js. To allow users to pick their own, we support a directive in the application configuration file to start a process when a container boots up after deploy. For example, most Node.js applications will have a block like this in their  .platform.app.yaml  file:

web:
  commands:
    start: "PM2_HOME=$PLATFORM_APP_DIR/run pm2 start index.js --no-daemon"

While on Ruby, it would look something like this:

web:
  commands:
     start: "unicorn -l $SOCKET -E production config.ru"

That option wasn’t available for PHP as PHP only has one applicable application runner, PHP-FPM. With the latest changes, though, it is now available for any container, including PHP.

What can you do with it? Any command you want. Let us know what cool things you’ve done with it.

Be aware, however, that using  web.commands.start  will skip starting the PHP-FPM runner. If you still want it to run, you can start FPM yourself in addition to your own commands. The effective default if you don’t specify anything is:

web:
  commands:
    start: "/usr/sbin/php-fpm7.0"

(Adjust for your appropriate PHP version.)

Log files change

This isn’t as much a feature as it is a heads-up. Previously, PHP error messages from your application would get logged to  /var/log/php.log . Every other app container would log messages from your application to  /var/log/app.log . With the latest changes, all containers now use  app.log .

That means as of your next deploy, your PHP error logs will be in  /var/log/app.log . That likely won’t have any impact on you, unless you have an auxiliary script that is reading the PHP log file. (Of course, we know your code is perfect and never has errors so it shouldn’t matter anyway.)