Siteaccess Matching

Siteaccess matching is done through eZ\Publish\MVC\SiteAccess\Matcher objects. You can configure this matching and even develop custom matchers.

Configuration

You can configure siteaccess matching in your main ezpublish/config/ezpublish.yml :

ezpublish.yml

You need to set several parameters:

ezpublish.siteaccess.default_siteaccess
ezpublish.siteaccess.list
(optional) ezpublish.siteaccess.groups
ezpublish.siteaccess.match

ezpublish.siteaccess.default_siteaccess is the default siteaccess that will be used if matching was not successful. This ensures that a siteaccess is always defined.

ezpublish.siteaccess.list is the list of all available siteaccesses in your website.

(optional) ezpublish.siteaccess.groups defines which groups siteaccesses are member of. This is useful when you want to mutualize settings between several siteaccesses and avoid config duplication. Siteaccess groups are considered as regular siteaccesses as far as configuration is concerned.

A siteaccess can be part of several groups.

A siteaccess configuration has always precedence on the group configuration.

ezpublish.siteaccess.match holds the matching configuration. It consists in a hash where the key is the name of the matcher class. If the matcher class doesn't start with a \, it will be considered relative to eZ\Publish\MVC\SiteAccess\Matcher (e.g. Map\Host will refer to eZ\Publish\MVC\SiteAccess\Matcher\Map\Host)

Every custom matcher can be specified with a fully qualified class name (e.g. \My\SiteAccess\Matcher) or by a service identifier prefixed by @ (e.g. @my_matcher_service).

In the case of a fully qualified class name, the matching configuration will be passed in the constructor.
In the case of a service, it must implement eZ\Bundle\EzPublishCoreBundle\SiteAccess\Matcher. The matching configuration will be passed to setMatchingConfiguration().

Available matchers

Name	Description	Configuration	Example
`URIElement`	Maps a URI element to a siteaccess. This is the default matcher used when choosing URI matching in setup wizard.	The element number you want to match (starting from 1). Important: When using a value > 1, it will concatenate the elements with _	URI: `/ezdemo_site/foo/bar` Element number: 1 Matched siteaccess: ezdemo_site Element number: 2 Matched siteaccess: ezdemo_site_foo
`URIText`	Matches URI using pre and/or post sub-strings in the first URI segment	The prefix and/or suffix (none are required)	URI: `/footestbar/my/content` Prefix: foo Suffix: bar Matched siteaccess: test
`HostElement`	Maps an element in the host name to a siteaccess.	The element number you want to match (starting from 1).	Host name: `www.example.com` Element number: 2 Matched siteaccess: example
`HostText`	Matches a siteaccess in the host name, using pre and/or post sub-strings.	The prefix and/or suffix (none are required)	Host name: `www.foo.com` Prefix: www. Suffix: .com Matched siteaccess: foo
`Map\Host`	Maps a host name to a siteaccess.	A hash map of host/siteaccess	Map: www.foo.com => foo_front admin.foo.com => foo_admin Host name: www.example.com Matched siteaccess: foo_front
`Map\URI`	Maps a URI to a siteaccess	A hash map of URI/siteaccess	URI: `/something/my/content` Map: something => ezdemo_site foobar => ezdemo_site_admin Matched siteaccess: ezdemo_site
`Map\Port`	Maps a port to a siteaccess	A has map of Port/siteaccess	URL: `http://ezpublish.dev:8080/my/content` Map: 80: foo 8080: bar Matched siteaccess: bar
`Regex\Host`	Matches against a regexp and extract a portion of it	The regexp to match against and the captured element to use	Host name: `example_sa` regex: `^(\\w+)_sa$` itemNumber: 1 Matched siteaccess: example
`Regex\URI`	Matches against a regexp and extract a portion of it	The regexp to match against and the captured element to use	URI: `/footestbar/something` regex: ^/foo(\\w+)bar itemNumber: 1 Matched siteaccess: test

Compound siteaccess matcher

The Compound siteaccess matcher allows to combine several matchers together, which is performed using the legacy host_uri.

For that, the following matchers can be used in your siteaccess match:

Compound\LogicalAnd
Compound\LogicalOr

ezpublish.yml

Matching by request header

It is possible to define which siteaccess to use by setting a X-Siteaccess header in your request. This can be useful for REST requests.

In such case, X-Siteaccess must be the siteaccess name (e.g. ezdemo_site).

Matching by environment variable

It is also possible to define which siteaccess to use directly via an EZPUBLISH_SITEACCESS environment variable.

This is recommended if you want to get performance gain since no matching logic is done in this case.

You can define this environment variable directly from your web server configuration:

Apache VirtualHost example

This can also be done via PHP-FPM configuration file, if you use it. See PHP-FPM documentation for more information.

Note about precedence

The precedence order for siteaccess matching is the following (the first matched wins):

Request header
Environment variable
Configured matchers

URILexer and semanticPathinfo

In some cases, after matching a siteaccess, it is neecessary to modify the original request URI. This is for example needed with URI-based matchers since the siteaccess is contained in the original URI and it is not part of the route itself.

The problem is addressed by analyzing this URI and by modifying it when needed through the URILexer interface.

URILexer interface

Once modified, the URI is stored in the semanticPathinfo request attribute, and the original pathinfo is not modified.