How to Deploy WordPress without Composer 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. This guide will take you through the steps of setting up “vanilla” WordPress - that is, WordPress not managed through Composer, but rather by either fully committing WordPress, themes, and plugins or defining them with submodules - on Platform.sh. It should be noted that this approach comes with certain limitations based on the way Platform.sh works, and for this reason is not recommended. Instead, consider using the “Upgrade to use Composer” guide to modify your project into one that uses Composer.

To get WordPress running on Platform.sh, you have two potential starting places:

• You already have a WordPress site you are trying to deploy. Go through this guide to make the recommended changes to your repository to prepare it for Platform.sh.

• You have no code at this point.

  If you have no code, you have two choices:

  • Generate a basic WordPress site. See an example for doing this under initializing a project.

  • Use a ready-made WordPress template.

A template is a starting point for building your project. It should help you get a project ready for production.

To use a template, click the button below to create a WordPress template project.

Once the template is deployed, you can follow the rest of this guide to better understand the extra files and changes to the repository.

Before you begin

You need:

• Git. Git is the primary tool to manage everything your app needs to run. Push commits to deploy changes and control configuration through YAML files. These files describe your infrastructure, making it transparent and version-controlled.
• A Platform.sh account. If you don’t already have one, register for a trial account. You can sign up with an email address or an existing GitHub, Bitbucket, or Google account. If you choose one of these accounts, you can set a password for your Platform.sh account later.
• The Platform.sh CLI. This lets you interact with your project from the command line. You can also do most things through the Web Console.

Initialize a project

You can start with a basic code base or push a pre-existing project to Platform.sh.

1. Create your first project by running the following command:

   platform create --title PROJECT_TITLE

   Then choose the region you want to deploy to, such as the one closest to your site visitors. You can also select more resources for your project through additional flags, but a Development plan should be enough for you to get started.

   Copy the ID of the project you've created.

2. Get your code ready locally.

   If your code lives in a remote repository, clone it to your computer.

   If your code isn't in a Git repository, initialize it by running git init.

   If you don’t have code, create a new WordPress project from scratch. It’s best to place WordPress core into a subdirectory rather than at the project root. The following commands create a fresh Git repository with WordPress as a subdirectory:

   mkdir wordpress-psh && cd wordpress-psh
   git clone https://github.com/WordPress/WordPress.git wordpress && rm -rf wordpress/.git
   git init

3. Connect your Platform.sh project with Git. You can use Platform.sh as your Git repository or connect to a third-party provider: GitHub, GitLab, or BitBucket.

   • Using Platform.sh
   • Using a third-party provider

   Add a Git remote for the Platform.sh project you just created by running the following command from your repository:

   platform project:set-remote PROJECT_ID

   That creates an upstream called platform for your Git repository.

   When you choose to use a third-party Git hosting service the Platform.sh Git repository becomes a read-only mirror of the third-party repository. All your changes take place in the third-party repository.

   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.

   • BitBucket
   • GitHub
   • GitLab

   Accept the default options or modify to fit your needs.

   All of your existing branches are automatically synchronized to Platform.sh. You get a deploy failure message because you haven’t provided configuration files yet. You add them in the next step.

   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* preview 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 preview environments at any time in the Console. Open your project and select Edit plan. Add additional Environments, view a cost estimate, and confirm your changes.

Now you have a local Git repository, a Platform.sh project, and a way to push code to that project. Next you can configure your project to work with Platform.sh.

Configure repository