Deploy WordPress on Platform.sh
WordPress is a popular Content Management System written in PHP. The recommended way to deploy WordPress on Platform.sh is by using Composer, the PHP package management suite. The most popular and supported way to do so is with the John Bloch Composer fork script. This guide assumes from the beginning that you’re migrating a Composer-flavored WordPress repository.
Note
With some caveats, it’s possible to deploy WordPress to Platform.sh without using Composer, though not recommended. You can consult the “WordPress without Composer on Platform.sh” guide to set that up, but do consider upgrading to use Composer.
To get WordPress running on Platform.sh, you have two potential starting places:
- You already have a Composer-flavored WordPress site you are trying to deploy. Go through each step to make the recommended changes to your repository to prepare it for Platform.sh.
- You have no code at this point. Platform.sh maintains a ready-made WordPress template that you can deploy. The steps below clarify why the modifications have been made to a base WordPress project.
Note
All of the examples in this deployment guide use the wordpress-composer template maintained by the Platform.sh team. That template is built using the John Bloch Composer fork of WordPress, which is meant to facilitate managing WordPress with Composer, but the template comes with its own assumptions. One is that WordPress core is downloaded by default into a wordpress subdirectory when installed, but other teams would rather specify another subdirectory along with many more assumptions.
An alternative approach is shown in Platform.sh’s Bedrock template, which installs core into web/wp, exports environment customization to a separate config/environments directory, and largely depends on setting environment variables to configure the database. Your are free to follow that template as an example with this guide, though there are slight differences. For its ease of use, the Bedrock approach is often used as a substitute starting point in some of the other WordPress guides in this documentation.
Tools 
Next, you need a couple tools to interact with your project, one of which you likely already have.
-
Git. Git is the primary tool you use to manage everything your app needs to run. Every commit pushed results in a new deployment, and all of your configuration is driven almost entirely by a small number of YAML files in your Git repository (which we will get to in the steps below). Your infrastructure, described in these files, becomes part of your application itself - completely transparent and version-controlled.
-
The Platform.sh CLI. This lets you interact with your project from the command line. You can also use your browser, but the CLI is the tool you use the most in this guide.
Sign up for Platform.sh and initialize your project
Depending on whether or not you have an existing project you want to migrate to Platform.sh, there are three ways to get started.
With a template
A template is a starting point for building your project. It isn’t yet ready for a production environment, but it should help you get there.
Deploy a WordPress template itself straight to Platform.sh. Use the button below to launch a WordPress template project and create a Platform.sh account along the way. If you don’t want to sign up with an email address, you can sign up using an existing GitHub, Bitbucket, or Google account. If you choose one of these options, you can set a password for your Platform.sh account later.
Once the template is deployed, you can follow the rest of this guide so you can better understand the extra files and tweaks in the repository.
With a brand new code base
You can start with a vanilla code base or push a pre-existing project to Platform.sh.
-
Register for a trial Platform.sh account.
If you don’t want to sign up with an email address, you can sign up using an existing GitHub, Bitbucket, or Google account. If you choose one of these options, you can set a password for your Platform.sh account later.
-
Create your first project.
Since you’re providing your own code, use the Blank project option. Give the project a title and choose the region closest to your site visitors. You can also select more resources for your project, although a
developmentplan should be enough for you to get started.
-
Initialize or clone your Git repository with existing code or create a new Composer-based project from scratch. The commands below create a brand new WordPress project using Composer, which you can then modify according to the rest of this guide.
git clone https://github.com/johnpbloch/wordpress && cd wordpress
-
Add a Git remote for the Platform.sh project you just created.
The easiest way to get the ID of the project is to run
plaformon its own, which lists all of your projects. As you have only one project, you can copy its ID. Then in your Git repository run:platform project:set-remote <PROJECT_ID>That creates an upstream called
platformfor your Git repository. Don’t push to it yet.
Once the project is fully configured, you can push to the remote you’ve created and have the project build automatically.
From a third party Git provider
Platform.sh also supports third party Git hosting services, such as GitHub, GitLab, or BitBucket. In that case, the Platform.sh Git repository becomes a read-only mirror of the third party repository, which you can continue to use as normal.
-
Register for a trial Platform.sh account.
If you don’t want to sign up with an email address, you can sign up using an existing GitHub, Bitbucket, or Google account If you choose one of these options, you can set a password for your Platform.sh account later.
-
Create your first project.
Since you’re providing your own code, use the Blank project option. Give the project a title and choose the region closest to your site visitors. You can also select more resources for your project, although a
developmentplan should be enough for you to get started. -
Add an integration to your existing third party repository.
The process varies a bit for each supported service, so check the specific pages for each one.
Accept the default options or modify to fit your needs.
All existing branches you have are automatically synchronized to Platform.sh. The deploy on Platform.sh reports a failure at this point. That’s expected because you haven’t provided configuration files yet. You add them in the next step. Remember to have a local clone of your project.
Note
If you’re integrating a repository to Platform.sh that contains a number of open pull requests, don’t use the default integration options. Projects are limited to three* development environments (active and deployed branches or pull requests) and you would need to deactivate them individually to test this guide’s migration changes. Instead, each service integration should be made with the following flag:
platform integration:add --type=<service> ... --build-pull-requests=false
You can then go through this guide and activate the environment when you’re ready to deploy
* You can purchase additional development environments at any time in the Console. Open your {{ .Get “name” }} project and select Edit plan. Add additional Environments, view a cost estimate, and confirm your changes.
Now that you have a local Git repository, a Platform.sh project, and a way to push code to that project, you’re all set to continue.