Platform from Scratch - Basic PHP setup

In case you missed it, here’s the first post in the series - “Platform in a Nutshell”.

Hello, and welcome back to “Platform.sh from scratch”. The goal here will be to augment the official documentation with a short tutorial that shows how to set up a project for proper functioning on Platform.sh. We’ll dive into the “why” as little as possible here. For now let’s dive straight into the “how”.

We’re going to start with a very basic application, the example Silex app on the front page of the Silex website. This will be a standard Composer based project, so we’ll need a  composer.json  file to start with.

The project structure will look like this –

├── app
│   └── index.php
├── composer.json
└── composer.lock

The  composer.json  file can be created by running  composer require silex/silex , or you can just copy this into  composer.json  at the root of your project directory –

{
    "require": {
        "silex/silex": "^2.0"
    }
}

Run a quick  composer install  and the rest of the dependencies will be pulled down and placed into the standard  vendor  directory. We’re going to be using Git here, and in general you don’t want to version 3rd party dependencies like those that Composer downloads. Let’s create a  .gitignore  file and add the vendor directory to it.

echo "vendor" >> .gitignore

The entirety of the application codebase looks like this –

<?php
// in app/index.php
require_once __DIR__.'/../vendor/autoload.php';
$app = new Silex\Application();
$app->get('/hello/{name}', function($name) use($app) {
return 'Hello '.$app->escape($name);
});

No, this is not the most beautiful file, but all you really need to know about this is that all URLs that enter this project will either have a base URL of

• www.whatever.foo  and will be routed to your codebase, or they’ll be
• whatever.foo  and will be redirected to  www . See step 1.

Another file that you need to have in place is the  .platform.app.yaml  file, which is a file that describes the high level requirements of this application. The most bare bones file is all that we need and it’ll look like this –

# .platform.app.yaml
The name param is linked to the "upstream" parameter in
routes.yaml. If you called the app "foo", then the
upstream parameter would look like upstream: "foo:http"
name: app
The "type" parameter takes the form "language:version"
This could be python:3.5 for example
type: php:5.6
Look for a composer.lock (or composer.json) and download
the listed dependencies
build:
flavor: composer
How much disk space will this app need? This is primarily used for
user uploaded assets, so for this application you don't really need
anything here, 256 would be fine. You can always grow
this later, so this is a safe starting point. (in MB)
disk: 2048
Now that a request has gotten this far, how do you want
it handled? We'll go into more detail about these params
in a later post. This section can be thought of as
somewhat analogous to an Apache or Nginx config file