On this page
As previously mentioned, Composer is strongly recommended, but it’s possible to use some non-Composer plugins and themes in your site, provided that they don’t require write access at runtime. In your build hook, include:
rsync -a plugins/* wordpress/wp-content/plugins/
Here, you can commit plugins to the repository in a
which are placed into the WordPress installation during the build.
It’s assumed that these packages stick to best practices and don’t write to the file system at runtime and when enabling them.
You can get around this issue by defining a mount where a plugin requires write access,
but you need to remember that the contents at that mount location are wiped when deployment begins,
so you need to copy and re-copy accordingly.
Adding a plugin or theme from WPPackagist is the same as downloading a package through Composer:
$ composer require wpackagist-plugin/cache-control
$ composer require wpackagist-theme/neve
This updates your
Once you push the change to Platform.sh, the package is downloaded during the WordPress build.
All that’s left is to sign in to the administration dashboard on your deployed site
and enable plugins and themes from the Plugins and Appearance settings, respectively.
Platform.sh maintains a WooCommerce template that you can deploy quickly from the button in its README, but using Composer you can quickly install WooCommerce yourself:
composer require woocommerce/woocommerce
Push those changes on a new environment and configure your store through the administration panel.
If your plugins aren’t accessible from WPPackagist or Packagist, but are still valid packages,
you can use them in your project by defining local
repositories for them in your
In the snippet above, other packages can still be downloaded from WPPackagist,
but now two custom
path repositories have been defined from
Adding packages from these sources then only requires
composer require author/custom_plugin
to ensure that the plugin at
/custom/plugin/author/custom_plugin is installed by Platform.sh when WordPress is built.
Your WordPress site is fully managed by Composer,
which means so are updates to WordPress core itself.
composer update periodically to get new versions of WordPress core, as well as any plugins or themes your have installed.
Commit the resulting changes to your
composer.lock file and push again to Platform.sh.
The Composer documentation has more information on options to update individual modules or perform other tasks.
Note that updating modules or core through the WordPress UI isn’t possible, as the file system is read-only. All updates should be done through Composer to update the lock file, and then push to Git.
Lando is a local development tool. Lando can read your Platform.sh configuration files for WordPress and produce an approximately equivalent configuration using Docker See a guide on using Lando with Platform.sh.
Templates come configured for use already with a base Landofile,
as in the following example.
It can be helpful getting started with Lando without the need to have a project on Platform.sh.
This file sets up good defaults for Lando and Platform.sh-configured codebases,
most notably through the
# This file sets some good defaults for local development using this Platform.sh
# template with Lando.
# Note that you should not edit this file so it can continue to receive upstream
# updates. If you wish to change the values below then override them in your
# normal .lando.yml.
# These both allow you to test this template without needing a site on Platform.sh
# However you will want to replace them in your .lando.yml
# These are tools that are commonly used during development for this template.
This Landofile is also where you can configure access to tools that would normally be available within a Platform.sh app container (such as the WordPress CLI) and that you also want to access locally.
You can replicate this file or follow the guide on using Lando with Platform.sh. Once you have completed the configuration, you can start your local environment by running: