Additional resources

Adding plugins and themes without Composer

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:

hooks:
    build: |
        rsync -a plugins/* wordpress/wp-content/plugins/        

Here, you can commit plugins to the repository in a plugins subdirectory, 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 public plugins and themes via Composer

Adding a plugin or theme from WPPackagist is the same as downloading a package through Composer:

# Plugin
$ composer require wpackagist-plugin/cache-control
# Theme
$ composer require wpackagist-theme/neve

This updates your composer.json and composer.lock files. 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.

Set up a WooCommerce site

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.

Adding private plugins and themes via Composer

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 composer.json file.

"repositories":[
    {
       "type":"composer",
       "url":"https://wpackagist.org"
    },
    {
      "type": "path",
      "url": "custom/themes/*",
      "options": {
        "symlink": false
        }
    },
    {
      "type": "path",
      "url": "custom/plugins/*",
      "options": {
        "symlink": false
        }
    }
]

In the snippet above, other packages can still be downloaded from WPPackagist, but now two custom path repositories have been defined from /custom/[themes|plugins] locally. 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.

Updating WordPress, plugins, and themes

Your WordPress site is fully managed by Composer, which means so are updates to WordPress core itself. Run 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.

Local development with Lando

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 recipe attribute.

# 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
name: platformsh-wordpress
recipe: platformsh

# These are tools that are commonly used during development for this template.
tooling:
  wp:
    service: app

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:

lando start

Back