Skip to content
This repository was archived by the owner on Nov 19, 2024. It is now read-only.

Commit 7419370

Browse files
authored
Port content updates after doc site maintenance (#4914)
Restored updates to v2.2 and 2.3 routes documentation topics
1 parent 7696bda commit 7419370

File tree

6 files changed

+111
-91
lines changed

6 files changed

+111
-91
lines changed

guides/v2.2/cloud/project/project-routes-more-cache.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -8,6 +8,8 @@ functional_areas:
88

99
{{site.data.var.ee}} enables you to use caching in your environment. If you disable caching, {{site.data.var.ee}} directly serves the files.
1010

11+
{% include cloud/note-route-all-placeholder.md %}
12+
1113
## Set up caching {#cloud-cache-setup}
1214

1315
Enable caching in your Magento application's `.magento/routes.yaml` as follows:

guides/v2.2/cloud/project/project-routes-more-ssi.md

Lines changed: 1 addition & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -6,9 +6,7 @@ functional_areas:
66
- Setup
77
---
88

9-
[Server side includes](http://httpd.apache.org/docs/current/howto/ssi.html){:target="_site"} (SSI) are directives in [HTML](https://glossary.magento.com/html) pages that get evaluated on the server while the pages are being rendered. Use of [server side](https://glossary.magento.com/server-side) includes enables you to add dynamically generated content to an existing HTML page without having to serve the entire page.
10-
11-
More information about [nginx SSI](http://nginx.org/en/docs/http/ngx_http_ssi_module.html).
9+
[Server side includes](http://nginx.org/en/docs/http/ngx_http_ssi_module.html) (SSI) are directives in [HTML](https://glossary.magento.com/html) pages that get evaluated on the server while the pages are being rendered. Use of [server side](https://glossary.magento.com/server-side) includes enables you to add dynamically generated content to an existing HTML page without having to serve the entire page.
1210

1311
You can activate or deactivate SSI on a per-route basis in your
1412
`.magento/routes.yaml`; for example:

guides/v2.3/cloud/project/project-conf-files_routes.md

Lines changed: 50 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -6,15 +6,15 @@ functional_areas:
66
- Setup
77
---
88

9-
{{site.data.var.ee}} processes an incoming URL using a *route*. The `routes.yaml` file—located at `.magento/routes.yaml` in your project—defines routes for the Integration environment. The deploy script uses values defined in the configuration files in the `.magento` directory and deletes the directory after deployment. Your local workspace is not affected.
9+
The `routes.yaml` file in the `.magento/routes.yaml` directory defines routes for your {{ site.data.var.ece }} Integration, Staging, and Production environments. Routes determine how Magento processes incoming HTTP requests.
1010

11-
{% include cloud/note-pro-using-yaml-support.md %}
11+
{% include cloud/note-pro-missing-self-service-options.md %}
1212

13-
The following is the default `routes.yaml` file:
13+
The default `routes.yaml` file contains the following code:
1414

1515
```yaml
1616
"http://{default}/":
17-
type: upstream
17+
type: upstream
1818
upstream: "mymagento:php"
1919
```
2020
@@ -31,26 +31,58 @@ magento-cloud environment:routes
3131
| http://{default}/ | upstream | mymagento:php |
3232
+-------------------+----------+---------------+
3333
```
34+
{: .no-copy}
3435

3536
## Route templates
3637

37-
The `routes.yaml` file is a list of templated routes and their configurations. A route template looks similar to this: `http://www.{default}/` or `https://{default}/blog`, where `{default}` is the qualified domain name configured for the project. For example, the routes for `example.com` domain resolve to the following:
38+
The `routes.yaml` file is a list of templated routes and their configurations. You can use the following placeholders in route templates:
3839

39-
- `http://www.example.com/`
40-
- `https://example.com/blog`
40+
- `{default}` represents the qualified domain name configured as the default for the project. For example, if you have a project with the default domain `example.com`, the route templates `http://www.{default}/` and `https://{default}/blog` resolve to the following URLs in a production environment:
4141

42-
{{site.data.var.ee}} also generates URLs for every active environment, so you can test that system. In a test system, `{default}` is replaced with the following:
42+
```text
43+
http://www.example.com/
4344
44-
```
45+
http://www.example.com/blog
46+
```
47+
{: .no-copy}
48+
49+
In a non-production branch, the project ID and environment ID replace the `{default}` placeholder when the project is deployed.
50+
51+
- `{all}` represents all the domain names configured for the project. For example, if you have a project with `example.com` and `example1.com` domains, the route templates `http://www.{all}/` and `https://{all}/blog` resolve to routes for all domains in the project:
52+
53+
```text
54+
http://www.example.com/
55+
56+
http://www.example.com/blog
57+
58+
http://www.example1.com/
59+
60+
http://www.example1.com/blog
61+
```
62+
{: .no-copy}
63+
64+
The `{all}` placeholder is useful for projects configured for multiple domains. In a non-production branch `{all}` is replaced with the project ID and environment ID for each domain.
65+
66+
If a project does not have any domains configured, which is common during development, the `{all}` placeholder behaves in the same way as the `{default}` placeholder.
67+
68+
{{site.data.var.ee}} also generates URLs for every active environment, so you can test that system. In a test system, `{default}` is replaced with the following domain name:
69+
70+
```text
4571
[branch]-[project-id].[region].magentosite.cloud
4672
```
73+
{: .no-copy}
74+
75+
For example, the `refactorcss` branch for the `mswy7hzcuhcjw` project hosted in the `us` cluster has the following the domains:
4776

48-
For example, if the project ID is `mswy7hzcuhcjw` on a branch called `refactorcss` hosted in the `us` cluster, the domains are:
77+
```text
78+
http://www-refactorcss-mswy7hzcuhcjw.us.magentosite.cloud/
4979
50-
- `http://www-refactorcss-mswy7hzcuhcjw.us.magentosite.cloud/`
51-
- `https://refactorcss-mswy7hzcuhcjw.us.magentosite.cloud/blog`
80+
https://refactorcss-mswy7hzcuhcjw.us.magentosite.cloud/blog
81+
```
82+
{: .no-copy}
5283

53-
<!-- {{site.data.var.ece}} also supports [multiple applications]({{ page.baseurl }}/cloud/project/project-conf-multi.html) per project. Each project has a single `routes.yaml` file that defines which request is routed to which application. -->
84+
{:.bs-callout-info}
85+
{{site.data.var.ece}} also supports [multiple applications]({{ page.baseurl }}/cloud/project/project-multi-sites.html) per project. Each project has a single `routes.yaml` file that defines which request is routed to which application.
5486

5587
## Route options
5688

@@ -64,10 +96,10 @@ Property | Description
6496
`redirects:` | Controls [redirect rules]({{ page.baseurl }}/cloud/project/project-routes-more-redir.html).
6597
`ssi:` | Controls enabling of [Server Side Includes]({{ page.baseurl }}/cloud/project/project-routes-more-ssi.html).
6698

67-
6899
## Simple routes
69100

70-
The following sample routes the apex domain and the `www` subdomain to the `frontend`application. This route does not redirect HTTPS:
101+
The following sample routes the apex domain and the `www` subdomain to the `frontend`application. This route does not redirect HTTPS requests:
102+
71103

72104
```yaml
73105
"http://{default}/":
@@ -119,10 +151,13 @@ If you examine the routes of this sample application, you see:
119151
```bash
120152
echo $MAGENTO_CLOUD_RELATIONSHIPS | base64 --decode | json_pp
121153
```
154+
{: .no-copy}
122155

123156
```terminal
124157
https://*.add-theme-projectID.us.magentosite.cloud/
125158
```
159+
{: .no-copy}
160+
126161

127162
{: .bs-callout .bs-callout-info}
128163
Some projects provisioned before December 8, 2017, use the triple dash (\-\-\-) as a separator for the subdomain.

guides/v2.3/cloud/project/project-routes-more-cache.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -8,6 +8,8 @@ functional_areas:
88

99
{{site.data.var.ee}} enables you to use caching in your environment. If you disable caching, {{site.data.var.ee}} directly serves the files.
1010

11+
{% include cloud/note-route-all-placeholder.md %}
12+
1113
## Set up caching {#cloud-cache-setup}
1214

1315
Enable caching in your Magento application's `.magento/routes.yaml` as follows:

guides/v2.3/cloud/project/project-routes-more-redir.md

Lines changed: 55 additions & 70 deletions
Original file line numberDiff line numberDiff line change
@@ -6,142 +6,127 @@ functional_areas:
66
- Setup
77
---
88

9-
Managing redirection rules is a common requirement for web applications, especially in cases where you do not want to lose incoming links that have changed or been removed over time. The following demonstrates how to manage redirection rules on your {{site.data.var.ece}} projects.
9+
Managing redirection rules is a common requirement for web applications, especially in cases where you do not want to lose incoming links that have changed or been removed over time.
1010

11-
If the redirection methods discussed in this topic do not work for you, you can use caching headers to do the same thing.
11+
The following demonstrates how to manage redirection rules on your {{site.data.var.ece}} projects using the `routes.yaml` configuration file. If the redirection methods discussed in this topic do not work for you, you can use caching headers to do the same thing.
12+
13+
{% include cloud/note-route-all-placeholder.md %}
1214

1315
## Whole-route redirects {#cloud-route-whole}
1416

15-
Using whole-route redirects, you can define very basic routes using the `routes.yaml` file. For example, you can redirect from a naked domain to a `www` subdomain as follows:
17+
Using whole-route redirects, you can define simple routes using the `routes.yaml` file. For example, you can redirect from an apex domain to a `www` subdomain as follows:
1618

1719
```yaml
1820
http://{default}/:
1921
type: redirect
2022
to: http://www.{default}/
2123
```
2224
23-
## Partial redirects {#cloud-route-partial}
25+
## Partial-route redirects {#cloud-route-partial}
2426
25-
In the [`.magento/routes.yaml`]({{ page.baseurl }}/cloud/project/project-conf-files_routes.html) file you can also add partial [redirect](https://glossary.magento.com/redirect) rules
26-
to existing routes:
27+
In the [`.magento/routes.yaml`]({{ page.baseurl }}/cloud/project/project-conf-files_routes.html) file, you can also add partial redirect rules to existing routes based on pattern matching:
2728

2829
```yaml
2930
http://{default}/:
3031
redirects:
3132
expires: 1d
3233
paths:
33-
"/from": { "to": "http://example.com/" }
34-
"/regexp/(.*)/matching": { "to": "http://example.com/$1", regexp: true }
34+
"/from": { to: "http://example.com/" }
35+
"/regexp/(.*)/matching": { to: "http://example.com/$1", regexp: true }
3536
```
3637

37-
This format is more rich and works with any type of route, including routes served directly by the application.
38+
Partial redirects work with any type of route, including routes served directly by the application.
3839

3940
Two keys are available under `redirects`:
4041

41-
- `expires`: Optional, the duration that the redirect is cached.
42-
Examples of valid values include `3600s`, `1d`, `2w`, `3m`.
43-
44-
- `paths`: The paths to apply the redirects to.
45-
46-
The following defines each rule under `paths`:
47-
48-
- A key that describes the expression to match against the request path
49-
- A value object describing both the destination to redirect to with detail on how to handle the redirection.
42+
- **expires**—Optional, specifies the amount of time to cache the redirect in the browser. Examples of valid values include `3600s`, `1d`, `2w`, `3m`.
5043

51-
The value object is defined with the following keys:
44+
- **paths**—One or more key-value pairs that specify the configuration for partial-route redirect rules.
5245

53-
- [`to`](#cloud-route-partial-to)
54-
- [`regexp`](#cloud-route-partial-regexp)
55-
- [`prefix`](#cloud-route-partial-prefix)
56-
- [`append_suffix`](#cloud-route-partial-append)
57-
- [`code`](#cloud-route-partial-code)
46+
For each redirect rule, the key is an expression to filter request paths for redirection. The value is an object that specifies the target destination for the redirect and options for processing the redirect.
5847

59-
### `to` {#cloud-route-partial-to}
48+
The value object has the following properties:
6049

61-
Required, a partial (`"/destination"` or `"//destination"`) or full URL (`"http://example.com/"`).
50+
Property | Description
51+
----------| -----------
52+
`to` | Required, a partial absolute path, URL with protocol and host, or pattern that specifies the target destination for the redirect rule.
53+
`regexp`| Optional, defaults to `false`. Specifies whether the path key should be interpreted as a PCRE regular expression.
54+
`prefix` | Specifies whether the redirect applies to both the path and all its children, or just the path itself. Defaults to `true`. This value is not supported if `regexp` is `true`.
55+
`append_suffix`| Determines if the suffix is carried over with the redirect. Defaults to `true`. This value is not supported if the `regexp` key is `true` *or* if the `prefix` key is `false`.
56+
`code` | Specifies the HTTP status code. Valid status codes are [`301` (Moved Permanently)](https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2), [`302`](https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3), [`307`](https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.8), and [`308`](https://tools.ietf.org/html/rfc7238). Defaults to `302`.
57+
`expires`| Optional, specifies the amount of time to cache the redirect in the browser. Defaults to the `expires` value defined directly under the `redirects` key, but at this level you can fine-tune the cache expiration for individual partial redirects.
6258

63-
### `regexp` {#cloud-route-partial-regexp}
59+
### Examples
6460

65-
Optional, defaults to `false`. Specifies whether the path key should be interpreted asa PCRE regular expression.
61+
The following examples show how to specify partial-route redirects in the `routes.yaml` file using various `paths` configuration options.
6662

67-
{% collapsible Click to show/hide content %}
63+
#### Regular expression pattern matching {#redirect-with-regex}
6864

69-
In the following example, a request to `http://example.com/regexp/a/b/c/match` redirects to `http://example.com/a/b/c`:
65+
Use the following format to configure redirect requests based on a regular expression.
7066

7167
```yaml
7268
http://{default}/:
7369
type: upstream
7470
redirects:
75-
paths:
76-
"/regexp/(.*)/match":
77-
to: "http://example.com/$1"
78-
regexp: true
71+
paths:
72+
"/regexp/(.*)/match": { to: "http://example.com/$1", regexp: true }
7973
```
8074

81-
{% endcollapsible %}
82-
83-
### `prefix` {#cloud-route-partial-prefix}
84-
Specifies whether or not to redirect both the path and all its children or just the path itself. Defaults to `true`, but is not supported if `regexp` is `true`.
75+
This configuration filters request paths against a regular expression and redirects matching requests to `https://example.com`. For example, a request to `https://example.com/regexp/a/b/c/match` redirects to `https://example.com/a/b/c`.
8576

86-
{% collapsible Click to show/hide content %}
77+
#### Prefix pattern matching {#redirect-with-prefix}
8778

88-
For example,
79+
Use the following format to configure redirect requests for paths that begin with a specified prefix pattern.
8980

9081
```yaml
9182
http://{default}/:
9283
type: upstream
9384
redirects:
94-
paths:
95-
"/from":
96-
to: "http://{default}/to"
97-
prefix: true
85+
paths:
86+
"/from": { to: "https://{default}/to", prefix: true }
9887
```
9988

100-
In the preceding example, if `prefix` is set to `true`, `/from` redirects to `/to` and `/from/another/path` will redirect to `/to/another/path`
89+
This configuration works as follows:
10190

102-
If `prefix` is set to `false`, `/from` triggers a redirect, but `/from/another/path` does not.
91+
- Redirects requests that match the pattern `/from` to the path `http://{default}/to`.
10392

104-
{% endcollapsible %}
93+
- Redirects requests that match the pattern `/from/another/path` to `https://{default}/to/another/path`.
10594

106-
### `append_suffix` {#cloud-route-partial-append}
107-
Determines if the suffix is carried over with the redirect. Defaults to `true`, but not supported if `regexp` is `true` *or* if `prefix` is `false`.
95+
- If you change the `prefix` property to `false`, requests that match the pattern `/from` trigger a redirect, but requests that match the pattern `/from/another/path` does not.
10896

109-
{% collapsible Click to show/hide content %}
97+
#### Suffix pattern matching {#redirect-with-suffix}
11098

111-
For example,
99+
Use the following format to configure redirect requests which append the path suffix from the request to the target destination.
112100

113101
```yaml
114102
http://{default}/:
115103
type: upstream
116104
redirects:
117-
paths:
118-
"/from":
119-
to: "http://{default}/to"
120-
append_suffix: false
105+
paths: { "/from": { to: "https://{default}/to", append_suffix: false }
121106
```
122107

123-
The preceding example results in `/from/path/suffix` redirecting to just `/to`.
108+
This configuration works as follows:
124109

125-
If `append_suffix` is set to its default value of `true`, `/from/path/suffix` redirects to `/to/path/suffix`.
110+
- Redirects requests that match the pattern `/from/path/suffix` to the path `https://{default}/to`.
126111

127-
{% endcollapsible %}
112+
- If you change the `append_suffix` property to `true`, then requests that match `/from/path/suffix` redirect to the path `https://{default}/to/path/suffix`.
128113

129-
### `code` {#cloud-route-partial-code}
114+
#### Path-specific cache configuration {#redirect-with-custom-cache}
130115

131-
Specifies the HTTP status code. Valid status codes are [`301` (Moved Permanently)](https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2), [`302`](https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3), [`307`](https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.8), and [`308`](https://tools.ietf.org/html/rfc7238). Defaults to `302`.
132-
133-
### `expires` {#cloud-route-partial-expires}
134-
135-
Optional, the duration to cache redirect. Defaults to the `expires` value defined directly under the `redirects` key, but at this level you can fine-tune the expiration of individual partial redirects:
116+
Use the following format to customize the time to cache a redirect from a specific path:
136117

137118
```yaml
138119
http://{default}/:
139120
type: upstream
140121
redirects:
141-
expires: 1d
142-
paths:
143-
"/from": { "to": "http://example.com/" }
144-
"/here": { "to": "http://example.com/there", "expires": "2w" }
145-
```
122+
expires: 1d
123+
paths:
124+
"/from": { to: "https://example.com/" }
125+
"/here": { to: "https://example.com/there", expires: "2w" }
126+
```
127+
128+
This configuration works as follows:
129+
130+
- Redirects from the first path (`/from`) are cached for 1 day.
146131

147-
In the preceding example, redirects from `/from` expire in one day, but redirects from `/here` expire in two weeks.
132+
- Redirects from the second path (`/here`) are cached for 2 weeks.

guides/v2.3/cloud/project/project-routes-more-ssi.md

Lines changed: 1 addition & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -6,9 +6,7 @@ functional_areas:
66
- Setup
77
---
88

9-
[Server side includes](http://httpd.apache.org/docs/current/howto/ssi.html){:target="_site"} (SSI) are directives in [HTML](https://glossary.magento.com/html) pages that get evaluated on the server while the pages are being rendered. Use of [server side](https://glossary.magento.com/server-side) includes enables you to add dynamically generated content to an existing HTML page without having to serve the entire page.
10-
11-
More information about [nginx SSI](http://nginx.org/en/docs/http/ngx_http_ssi_module.html).
9+
[Server side includes](http://nginx.org/en/docs/http/ngx_http_ssi_module.html) (SSI) are directives in [HTML](https://glossary.magento.com/html) pages that get evaluated on the server while the pages are being rendered. Use of [server side](https://glossary.magento.com/server-side) includes enables you to add dynamically generated content to an existing HTML page without having to serve the entire page.
1210

1311
You can activate or deactivate SSI on a per-route basis in your
1412
`.magento/routes.yaml`; for example:

0 commit comments

Comments
 (0)