2014-09-21 02:07:58 +02:00
summary: An overview of the steps involved in delivering a SilverStripe web page.
2011-02-07 07:48:44 +01:00
# Execution Pipeline
## Introduction
2014-11-15 04:01:47 +01:00
In order to transform a HTTP request or a commandline exeuction into a response,
SilverStripe needs to boot its core and run through several stages of processing.
2011-02-07 07:48:44 +01:00
2014-11-15 04:01:47 +01:00
## Request Rewriting
2011-02-07 07:48:44 +01:00
2014-11-15 04:01:47 +01:00
The first step in most environments is a rewrite of a request path into parameters passed to a PHP script.
This allows writing friendly URLs instead of linking directly to PHP files.
2015-06-13 01:08:25 +02:00
The implementation depends on your web server; we'll show you the most common one here:
2014-11-15 04:01:47 +01:00
Apache with [mod_rewrite ](http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html ).
Check our [installation guides ](/getting_started/installation ) on how other web servers like IIS or nginx handle rewriting.
2011-02-07 07:48:44 +01:00
2014-11-15 04:01:47 +01:00
The standard SilverStripe project ships with a `.htaccess` file in your webroot for this purpose.
By default, requests will be passed through for files existing on the filesystem.
Some access control is in place to deny access to potentially sensitive files in the webroot, such as YAML configuration files.
If no file can be directly matched, control is handed off to `framework/main.php` .
2011-02-07 07:48:44 +01:00
### SILVERSTRIPE START ###
2014-11-15 04:01:47 +01:00
# Deny access to templates (but allow from localhost)
2011-02-07 07:48:44 +01:00
< Files * . ss >
2014-11-15 04:01:47 +01:00
Order deny,allow
Deny from all
Allow from 127.0.0.1
2011-02-07 07:48:44 +01:00
< / Files >
2014-11-15 04:01:47 +01:00
# Deny access to IIS configuration
< Files web . config >
Order deny,allow
Deny from all
< / Files >
2014-09-21 02:07:58 +02:00
2014-11-15 04:01:47 +01:00
# Deny access to YAML configuration files which might include sensitive information
< Files ~ " \.ya ? ml $" >
Order allow,deny
Deny from all
< / Files >
2011-02-07 07:48:44 +01:00
2014-11-15 04:01:47 +01:00
# Route errors to static pages automatically generated by SilverStripe
ErrorDocument 404 /assets/error-404.html
ErrorDocument 500 /assets/error-500.html
2011-02-07 07:48:44 +01:00
2014-11-15 04:01:47 +01:00
< IfModule mod_rewrite . c >
SetEnv HTTP_MOD_REWRITE On
RewriteEngine On
2014-08-16 02:51:17 +02:00
2014-11-15 04:01:47 +01:00
# Deny access to potentially sensitive files and folders
RewriteRule ^vendor(/|$) - [F,L,NC]
RewriteRule silverstripe-cache(/|$) - [F,L,NC]
RewriteRule composer\.(json|lock) - [F,L,NC]
2014-08-16 02:51:17 +02:00
2017-10-02 13:30:24 +02:00
# Non existant files passed to requesthandler
# Try finding the module in the vendor folder first
2014-11-15 04:01:47 +01:00
RewriteCond %{REQUEST_URI} ^(.*)$
RewriteCond %{REQUEST_FILENAME} !-f
2017-10-02 13:30:24 +02:00
RewriteRule .* ../vendor/silverstripe/framework/main.php?url=%1 [QSA]
2014-11-15 04:01:47 +01:00
# If requesting the main script directly, rewrite to the installer
RewriteCond %{REQUEST_URI} ^(.*)/framework/main.php$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule . %1/install.php? [R,L]
2014-08-16 02:51:17 +02:00
2014-11-15 04:01:47 +01:00
< / IfModule >
### SILVERSTRIPE END ###
2014-08-16 02:51:17 +02:00
2014-11-15 04:01:47 +01:00
SilverStripe can also operate without this level of rewriting, in which case all dynamic requests go
through an `index.php` script in the webroot.
< div class = "notice" markdown = "1" >
Running SilverStripe without web server based rewriting is not recommended since it
can leave sensitive files exposed to public access (the `RewriteRule` conditions from above don't apply).
< / div >
2014-12-02 23:56:38 +01:00
## Bootstrap
2014-11-15 04:01:47 +01:00
2017-06-22 12:50:45 +02:00
The `constants.php` file is included automatically in any project which requires silverstripe/framework.
This is included automatically when the composer `vendor/autoload.php` is included, and performs its
tasks silently in the background.
2014-11-15 04:01:47 +01:00
2017-06-22 12:50:45 +02:00
* Tries to locate an `.env`
2017-01-30 16:34:55 +01:00
[configuration file ](/getting_started/environment_management ) in the webroot.
2017-10-09 01:41:34 +02:00
* Sets constants based on the filesystem structure (e.g. `BASE_URL` , `BASE_PATH` and `TEMP_PATH` )
2017-06-22 12:50:45 +02:00
2017-10-02 13:30:24 +02:00
All requests go through `main.php` , which sets up the core [Kernel ](api:SilverStripe\Core\Kernel ) and [HTTPApplication ](api:SilverStripe\Control\HTTPApplication )
2017-06-22 12:50:45 +02:00
objects. See [/developer_guides/execution_pipeline/app_object_and_kernel] for details on this.
The main process follows:
* Include `autoload.php`
2017-07-03 03:22:12 +02:00
* Construct [HTTPRequest ](api:SilverStripe\Control\HTTPRequest ) object from environment.
2017-06-22 12:50:45 +02:00
* Construct a `Kernel` instance
* Construct a `HTTPApplication` instance
* Add any necessary middleware to this application
* Pass the request to the application, and request a response
2014-11-15 04:01:47 +01:00
While you usually don't need to modify the bootstrap on this level, some deeper customizations like
adding your own manifests or a performance-optimized routing might require it.
An example of this can be found in the ["staticpublisher" module ](https://github.com/silverstripe-labs/silverstripe-staticpublisher/blob/master/main.php ).
The modules instructs web servers to route through its own `main.php` to determine which requests can be cached
before handing control off to SilverStripe's own `main.php` .
## Routing and Request Handling
2017-07-03 03:22:12 +02:00
The `main.php` script relies on [Director ](api:SilverStripe\Control\Director ) to work out which [controller ](../controllers/ ) should handle this request. It parses the URL, matching it to one of a number of patterns,
2014-11-15 04:01:47 +01:00
and determines the controller, action and any argument to be used ([Routing](../controllers/routing)).
2017-07-03 03:22:12 +02:00
* Creates a [HTTPRequest ](api:SilverStripe\Control\HTTPRequest ) object containing all request and environment information
2014-11-15 04:01:47 +01:00
* The [session ](../cookies_and_sessions/sessions ) holds an abstraction of PHP session
2015-02-28 01:09:15 +01:00
* Instantiates a [controller ](../controllers/ ) object
2017-07-03 03:22:12 +02:00
* The [Injector ](api:SilverStripe\Core\Injector\Injector ) is first referenced, and asks the registered
2015-02-28 01:09:15 +01:00
[RequestFilter ](../controllers/requestfilters )
2014-11-15 04:01:47 +01:00
to pre-process the request object (see below)
2017-07-03 03:22:12 +02:00
* The `Controller` executes the actual business logic and populates an [HTTPResponse ](api:SilverStripe\Control\HTTPResponse )
2014-11-15 04:01:47 +01:00
* The `Controller` can optionally hand off control to further nested controllers
* The `Controller` optionally renders a response body through `SSViewer` [templates ](../templates )
2017-07-03 03:22:12 +02:00
* The [RequestProcessor ](api:SilverStripe\Control\RequestProcessor ) is called to post-process the request to allow
2014-11-15 04:01:47 +01:00
further filtering before content is sent to the end user
* The response is output to the client
## Request Preprocessing and Postprocessing
The framework provides the ability to hook into the request both before and
after it is handled to allow binding custom logic. This can be used
2015-06-13 01:08:25 +02:00
to transform or filter request data, instantiate helpers, execute global logic,
2014-11-15 04:01:47 +01:00
or even short-circuit execution (e.g. to enforce custom authentication schemes).
2015-02-28 01:09:15 +01:00
The ["Request Filters" documentation ](../controllers/requestfilters ) shows you how.
2014-11-15 04:01:47 +01:00
## Flushing Manifests
If a `?flush=1` query parameter is added to a URL, a call to `flush()` will be triggered
2015-02-09 10:55:59 +01:00
on any classes that implement the [Flushable ](flushable ) interface.
2014-11-15 04:01:47 +01:00
This enables developers to clear [manifest caches ](manifests ),
for example when adding new templates or PHP classes.
Note that you need to be in [dev mode ](/getting_started/environment_management )
or logged-in as an administrator for flushing to take effect.
2014-12-02 23:56:38 +01:00
[CHILDREN]