Content tree-based routing
With content tree-based routing, the system automatically generates and matches page URLs based on their position in the website’s content tree. You do not need to perform any manual route mapping and configuration on the side of the MVC application. All routing logic is handled for you by the system.
This method of routing is not a full replacement of the standard ASP.NET routing model. Instead, it augments the routing pipeline, automatically handling requests targeting the site’s pages. You can still set up additional routes for your MVC application.
This simplified diagram models request handling when using content tree-based routing:
Incoming requests are matched against a general route and their target URL compared with existing pages in the system. If there is a match, the system takes over the routing logic. Otherwise, the request continues matching against routes registered further down the routing table using conventional ASP.NET routing.
Once the request is taken over by Xperience, all routing happens automatically. You only need to supply a view providing the desired output formatting. However, you can also customize the processing logic, providing your own controllers and view models as required.
Page URL generation
The system does not automatically generate URLs for all nodes (pages) in the content tree. A URL is generated only for pages whose page type has the URL feature enabled. A page URL is generated when:
- a new page is created
- the URL slug of an existing page is updated
The overall URL is driven by the page’s location in the site’s content tree:
- The system takes all of the page’s ancestors up to the site’s root (‘/’):
- If an ancestor has the URL feature enabled for its page type, it contributes a segment to the page’s resulting URL. All other ancestors are skipped.
- By default, the segment is formed from the page’s title converted to a URL-sanitized string. A page’s title is the value of a field specified by the page type’s Page name source field setting (configured on the page type’s Fields tab).
The following diagram illustrates how URLs are generated based on a page’s position in the content tree and the configuration of its ancestors:
The Articles section holds a collection of articles (Article 1 and Article 2). All pages are based on page types with the URL feature enabled. As a result, both articles also contain their parent node segment (Articles) in their URL.
The Landing pages section holds a collection of landing pages (Page 1 and Page 2). Only the landing pages are based on a page type with the URL feature enabled. As a result, the URLs of both landing pages do not include their parent.
URL generation on multilingual sites
On multilingual sites, a page URL is generated for all culture versions supported by the site.
If a culture version of a page that does not yet exist – only its generated URL is saved in the database – is requested, the result depends on the Combine with default culture setting.
- If the setting is enabled, the page is returned in the site’s default culture.
- If the setting is disabled, the system responds with the 404 (Not Found) status code.
The system generates such URLs as placeholders to ensure requests made for non-existing language versions do not match against other application routes. When a page for the culture version is added, the URL becomes accessible. Furthermore, these URLs also ensure a clear pattern for the URLs of child pages.
Adding or removing cultures on a site with content tree-based routing causes the system to generate a URL for every suitable page of that culture. Depending on the number of pages on your site and the performance of your environment, this operation may be time-consuming.
Handling of non-existing language versions or unpublished pages
Once a URL is generated for a page, it persists until the corresponding page (including all language variants) is deleted. This includes cases when:
- the page is unpublished
- the version of the page does not exist in the requested culture version and there is no fallback to a default culture configured.
If a request targets such a page, the system responds with the HTTP 404 (Not Found) status and the request does not continue matching against other routes. This is to prevent accidentally matching requests intended to be handled by Xperience against other loosely constrained routes registered further down the routing table. You can use conventional 404 error handling for such cases.
Configuring your project to use content tree-based routing
To start using content-tree based routing in your project: