# 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

• 7.4
• 7.3 (default)
• 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: []
    # 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

# Toggling xdebug

You can enable the xdebug extension by setting xdebug: true. Lando will also automatically configure xdebug.remote_enable and xdebug.remote_host for you. This means that xdebug should be ready to receive connections out of the box.

Note that unlike in previous versions of Lando, xdebug: false will now disable the xdebug extension instead of just disabling xdebug.remote_enable.

# 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 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.