# PHP

PHP is a popular scripting language that is especially suited for web development. It is often served by either apache or nginx.

You can easily add it to your Lando app by adding an entry to the services top-level config in your Landofile.

# Supported versions

• 8.0
• 7.4 (default)
• 7.3
• 7.2
• 7.1
• 7.0
• 5.6
• custom

# Legacy versions

You can still run these versions with Lando but for all intents and purposes they should be considered deprecated (e.g. YMMV and do not expect a ton of support if you have an issue).

• 5.5
• 5.4
• 5.3

# Patch versions

Because we use our own custom images for php, specifying a patch version is not currently supported.

If you really need to lock down to a patch version, you could consider using either a custom compose service or a service overrides.

# Configuration

Here are the configuration options, set to the default values, for this service. If you are unsure about where this goes or what this means, we highly recommend scanning the services documentation to get a good handle on how the magicks work.

Also note that options, in addition to the build steps and overrides that are available to every service, are shown below:

services:
  myservice:
    type: php:7.3
    via: apache:2.4
    ssl: false
    webroot: .
    xdebug: false
    composer: []
    composer_version: '2.0.7'
    # Below only valid for via: cli
    command: tail -f /dev/null
    config:
      php: SEE BELOW
      server: SEE BELOW
      vhosts: SEE BELOW

# Choosing a server, or no server

By default, php services will be served by the default version of our apache service but you can switch this to either nginx or cli.

Like with apache, nginx will use the the default version of our nginx service while cli will just spin up a php container without a web server. The latter is useful if you just want to work on a CLI utility or lock down what version composer runs with.

# With Apache (default)

services:
  myservice:
    type: php
    via: apache

# With nginx

services:
  myservice:
    type: php
    via: nginx

# As CLI

services:
  myservice:
    type: php
    via: cli

In CLI mode you can optionally tell the php cli service to boot up with an arbitrary command, this is good for php worker services like queues.

services:
  myservice:
    type: php
    via: cli
    command: php /app/src/artisan horizon

# Using xdebug

You can enable the xdebug extension by setting xdebug: true and doing a lando rebuild. When the extension is enabled Lando will automatically set the needed configuration for remote debugging. This means that xdebug should be ready to receive connections out of the box.

If you are using xdebug version 3, which is installed by default for php 7.2+ you can optionally specify the mode.

services:
  myservice:
    type: php:7.3
    xdebug: "debug,develop"

For this version of xdebug setting xdebug: true will set xdebug.mode=debug. You can read more about xdebug.mode here.

# Configuring xdebug

If you'd like to override Lando's out of the box xdebug config the easiest way to do that is by setting the XDEBUG_CONFIG environment variable as a service level override.

services:
  myservice:
    type: php:7.3
    xdebug: "debug,develop"
    overrides:
      environment:
        XDEBUG_CONFIG: "discover_client_host=0 client_host=localhost"

Note that you cannot set every xdebug configuration option via XDEBUG_CONFIG, see this. If you need to configure something outside of the scope of XDEBUG_CONFIG we recommend you use a custom php.ini.

You can also modify or unset XDEBUG_MODE in a similar way. For example if you wanted to manage xdebug.mode in your own php.ini you could so something like

services:
  myservice:
    type: php:7.3
    xdebug: true
    overrides:
      environment:
        XDEBUG_MODE:
    config:
      php: config/php.ini

# Setting up your IDE for XDEBUG

While Lando will handle the server side configuration for you, there is often a considerable amount of pain lurking in the client side configuration. To that end, some helpful info about a few popular clients is shown below:

ATOM

An example config for ATOM's php-debug plugin is shown below:

"php-debug":
  {
    ServerPort: 9000
    PathMaps: [
      "/app/www;/Users/pirog/Desktop/work/lando/examples/lando/www"
    ]
  }

The first part of a pathmap will be the location of your code in the container. Generally, this should be /app. Also note that if your app is in a nested docroot, you will need to append that to the paths. The example above uses an app with a nested webroot called www.

VSCODE

Setup XDebug in Visual Studio Code Guide

# Troubleshooting Xdebug

If you have set xdebug: true in your recipe or service config and run lando rebuild but are still having issues getting xdebug to work correctly, we recommend that you remove xdebug: true, run lando rebuild and then set the relevant xdebug config directly using a custom a php.ini (see examples above on how to set a custom config file). Your config file should minimally include something as shown below:

xdebug.max_nesting_level = 256
xdebug.show_exception_trace = 0
xdebug.collect_params = 0
xdebug.remote_enable = 1
xdebug.remote_host = YOUR HOST IP ADDRESS

You can use lando info --deep | grep IPAddress to help discover the correct host ip address but please note that this can change and will likely differ from dev to dev.

# Installing composer

As of Lando 3.0.17 you can configure the version of composer you would like to install. This should respect any of the versions listed on the Composer download page but it is required you specify down to the patch version.

services:
  myservice:
    type: php
    composer_version: "1.10.1"

You can also choose to ignore the composer install step by setting composer_version: false. This will use whatever version of composer was last bundled with our php image. The following "convenience flags" are also available:

# Install the latest stable 1.x version
composer_version: 1
composer_version: 1-latest

# Install the latest stable 2.x version
composer_version: 2
composer_version: 2-latest

# Install latest pre-release version
composer_version: preview

# Install latest commit
composer_version: snapshot

# Installing global dependencies

You can also use the composer key if you need to require any global composer dependenices. This follows the same syntax as your normal composer.json except written as YAML instead of JSON.

An example of globally installing phpunit/phpunit ^6.5 is shown below:

services:
  myservice:
    type: php
    composer:
      phpunit/phpunit: ^6.5

An example of using a build step to automatically composer install your dependencies before your app starts is shown below:

services:
  myservice:
    type: php
    build:
      - composer install

# Using custom config files

You may need to override our default php config with your own.

If you do this, you must use files that exist inside your application and express them relative to your project root as shown below:

Note that the default files may change based on how you set both ssl and via. Also note that the vhosts and server config will be either for apache or nginx depending on how you set via. We highly recommend you check out both the apache and nginx if you plan to use a custom vhosts or server config.

If you set via: cli then, as you might suspect, vhosts and/or server is not going to do anything.

A hypothetical project

Note that you can put your configuration files anywhere inside your application directory. We use a config directory but you can call it whatever you want such as .lando in the example below:

./
|-- config
   |-- default.conf
   |-- nginx.conf
   |-- php.ini
|-- index.php
|-- .lando.yml

Landofile using custom php config

services:
  myservice:
    type: php
    config:
      php: config/php.ini
      server: config/nginx.conf
      vhosts: config/default.conf

# Path Considerations

Lando will set the PATH hierarchy for this service as follows:

[
  # The line below should be where your app's composer.json binaries live
  '/app/vendor/bin',
  '/app/bin',
  '/usr/local/sbin',
  '/usr/local/bin',
  '/usr/sbin',
  '/usr/bin',
  '/sbin',
  '/bin',
  # The line below should be where global composer binaries live
  '/var/www/.composer/vendor/bin',
]

This is useful to note if you are not using absolute paths in any tooling routes and are getting the unexpected version of a particular utility.

# Installed Extensions

Note that xdebug is off by default but you can enable it by setting your php services config to xdebug: true. Read more about this in "Configuration" above.

# Adding or removing extensions

There are a few ways you can extend or modify our php images below:

• Using build steps.
• Using your own image with service overrides.
• Building from your own local Dockerfile service overrides.

Consider the example that uses build steps to install the memcached php extension as follows:

services:
  myservice:
    type: php
    build_as_root:
      - apt-get update -y
      - apt-get install libmemcached-dev -y
      - pecl install memcached
      - docker-php-ext-enable memcached

Note the usage of docker-php-ext-enable. Our images extend the official Docker php images which ship with a bunch of helpful utility scripts to manage php extensions.