Configure WordPress for Platform.sh
Back to home
On this page
You now have a project running on Platform.sh. In many ways, a project is just a collection of tools around a Git repository. Just like a Git repository, a project has branches, called environments. Each environment can then be activated. Active environments are built and deployed, giving you a fully isolated running site for each active environment.
Once an environment is activated, your app is deployed through a cluster of containers. You can configure these containers in three ways, each corresponding to a YAML file:
- Configure apps in a
.platform.app.yamlfile. This controls the configuration of the container where your app lives. - Add services in a
.platform/services.yamlfile. This controls what additional services are created to support your app, such as databases or search servers. Each environment has its own independent copy of each service. If you’re not using any services, you don’t need this file. - Define routes in a
.platform/routes.yamlfile. This controls how incoming requests are routed to your app or apps. It also controls the built-in HTTP cache. If you’re only using the single default route, you don’t need this file.
Start by creating empty versions of each of these files in your repository:
# Create empty Platform.sh configuration files
mkdir -p .platform && touch .platform/services.yaml && touch .platform/routes.yaml && touch .platform.app.yamlNow that you’ve added these files to your project, configure each one for WordPress in the following sections. Each section covers basic configuration options and presents a complete example with comments on why WordPress requires those values.
Configure apps in .platform.app.yaml 
Your app configuration in a .platform.app.yaml file is allows you to configure nearly any aspect of your app.
For all of the options, see a complete reference.
The following example shows a complete configuration with comments to explain the various settings.
There are a few things to notice in this file specific to running non-Composer variants of WordPress on Platform.sh. Defined in the dependencies block, all of the packages needed to run the WordPress CLI in both the application container and via SSH are installed in the first stages of the build process using Composer. Also, the web.locations block will expose wordpress/index.php under the primary route.
# This file describes an application. You can have multiple applications
# in the same project.
# The name of this app. Must be unique within a project.
name: app
# The runtime the application uses.
type: "php:8.1"
dependencies:
php:
wp-cli/wp-cli-bundle: "^2.4"
psy/psysh: "^0.10.4"
# The relationships of the application with services or other applications.
# The left-hand side is the name of the relationship as it will be exposed
# to the application in the PLATFORM_RELATIONSHIPS variable. The right-hand
# side is in the form `<service name>:<endpoint name>`.
relationships:
database: "db:mysql"
variables:
php:
session.gc_maxlifetime: '200000'
session.cookie_lifetime: '2000000'
pcre.backtrack_limit: '200000'
pcre.recursion_limit: '200000'
# The configuration of app when it is exposed to the web.
web:
locations:
"/":
# The public directory of the app, relative to its root.
root: "wordpress"
# The front-controller script to send non-static requests to.
passthru: "/index.php"
# Wordpress has multiple roots (wp-admin) so the following is required
index:
- "index.php"
# The number of seconds whitelisted (static) content should be cached.
expires: 600
scripts: true
allow: true
rules:
^/composer\.json:
allow: false
^/license\.txt$:
allow: false
^/readme\.html$:
allow: false
"/wp-content/cache":
root: "wordpress/wp-content/cache"
scripts: false
allow: false
"/wp-content/uploads":
root: "wordpress/wp-content/uploads"
scripts: false
allow: false
rules:
# Allow access to common static files.
'(?<!\-lock)\.(?i:jpe?g|gif|png|svg|bmp|ico|css|js(?:on)?|eot|ttf|woff|woff2|pdf|docx?|xlsx?|pp[st]x?|psd|odt|key|mp[2-5g]|m4[av]|og[gv]|wav|mov|wm[av]|avi|3g[p2])$':
allow: true
expires: 1w
# The size of the persistent disk of the application (in MB).
disk: 2048
# The mounts that will be performed when the package is deployed.
mounts:
"wordpress/wp-content/cache":
source: local
source_path: "cache"
"wordpress/wp-content/uploads":
source: local
source_path: "uploads"
hooks:
deploy: |
wp cache flush
wp core update-db
wp cron event run --due-now
source:
operations:
auto-update:
command: |
# get our pub directory as defined in the application
pubDir=$(echo $PLATFORM_APPLICATION | base64 --decode | jq -r '.web.locations."/".root')
# grab the latest version of WordPress, save locally based on pubDir name
curl https://wordpress.org/latest -o "${PLATFORM_CACHE_DIR}/${pubDir}.tar.gz"
cd "${PLATFORM_CACHE_DIR}"
tar -xvf "${pubDir}.tar.gz" && rm "${pubDir}.tar.gz"
# the archive always expands into a "wordpress" directory
rsync -av wordpress/ "${PLATFORM_SOURCE_DIR}/${pubDir}"
cd "${PLATFORM_SOURCE_DIR}"
git add --all
confirm=$(git status --porcelain=1);
if [ -z "${confirm}" ]; then
echo "No changes to commit."
else
git commit -m "Auto updated via source operations"
fi
Add services in .platform/services.yaml
You can add the managed services you need for you app to run in the .platform/services.yaml file.
You pick the major version of the service and security and minor updates are applied automatically,
so you always get the newest version when you deploy.
You should always try any upgrades on a development branch before pushing to production.
We recommend the latest MariaDB version for WordPress.
You can add other services if desired, such as Solr or Elasticsearch. You need to configure to use those services once they’re enabled.
Each service entry has a name (db in the example)
and a type that specifies the service and version to use.
Services that store persistent data have a disk key, to specify the amount of storage.
# The services of the project.
#
# Each service listed will be deployed
# to power your Platform.sh project.
db:
type: mariadb:10.4
disk: 2048
Define routes
All HTTP requests sent to your app are controlled through the routing and caching you define in a .platform/routes.yaml file.
The two most important options are the main route and its caching rules.
A route can have a placeholder of {default},
which is replaced by your domain name in production and environment-specific names for your preview environments.
The main route has an upstream, which is the name of the app container to forward requests to.
You can enable HTTP cache.
The router includes a basic HTTP cache.
By default, HTTP caches includes all cookies in the cache key.
So any cookies that you have bust the cache.
The cookies key allows you to select which cookies should matter for the cache.
Generally, you want the user session cookie, which is included in the example for WordPress.
You may need to add other cookies depending on what additional modules you have installed.
You can also set up routes as HTTP redirects.
In the following example, all requests to www.{default} are redirected to the equivalent URL without www.
HTTP requests are automatically redirected to HTTPS.
If you don’t include a .platform/routes.yaml file, a single default route is used.
This is equivalent to the following:
https://{default}/:
type: upstream
upstream: <APP_NAME>:httpWhere <APP_NAME> is the name you’ve defined in your app configuration.
The following example presents a complete definition of a main route for a WordPress app:
# The routes of the project.
#
# Each route describes how an incoming URL is going
# to be processed by Platform.sh.
"https://{default}/":
type: upstream
upstream: "app:http"
cache:
enabled: true
# Base the cache on the session cookies. Ignore all other cookies.
cookies:
- '/^wordpress_logged_in_/'
- '/^wordpress_sec_/'
- 'wordpress_test_cookie'
- '/^wp-settings-/'
- '/^wp-postpass/'
- '/^wp-resetpass-/'
"https://www.{default}/":
type: redirect
to: "https://{default}/"