Wildcard URLs

Wildcard URLs provide a way to load content dynamically depending on the page URL. By using wildcards, you can pass the values of query string parameters directly as part of the URL path.

For example, wildcard URLs allow you to display user profiles of various site users on a single page:

1. Open the Pages application in the Kentico administration interface.
2. Create a new page containing the User public profile web part.
3. Switch to the Properties -> URLs tab of the page.
4. Under the Page URL Path section, set the following value into the Path or pattern field: /Members/{UserName}
5. Click Save.

The {UserName} part of the URL path is the wildcard. For example, if you type <domain>/Members/Andy into your browser, the new page opens. The system converts the wildcard part of the URL (Andy) into a query string parameter, so that the internal URL actually looks like <domain>/<page alias path>?username=Andy. The name of the parameter is taken from the name of the wildcard, and the value is the matching part of the entered URL. The User public profile web part on the page processes the username query string parameter in the rewritten URL and displays the profile for the user Andy.

Default wildcard values

You can set default values for wildcards in URLs. Use the following format in the URL path: {<wildcard name>;<Default value>}. Default values are useful when you want to have a wildcard in a page’s URL path, but expect that the wildcard part may not always be present in the URL. The default value ensures that the system always generates the URL with a certain value in the wildcard.

For example:

1. Open the Pages application in the Kentico administration interface.
2. Select the page created in the basic wildcard example (the page displaying user profiles).
3. Switch to the Properties -> URLs tab and type /Members/{UserName;Andy} into the Path or pattern field.
4. Click Save.

If you now access the page on the live site without specifying the wildcard part of the URL path, the page displays Andy’s profile by default.

Additionally, the current value of a wildcard is always used as the default value in all other URLs on the given page that contain the same wildcard. For example, imagine a scenario with two pages that use a wildcard in their URL path: the first set to /Profile/{UserName} and the other to /Profile/{UserName}/Details. When the first page is accessed through the URL <domain>/Profile/Andy, navigation links to the second page are automatically generated as <domain>/Profile/Andy/Details. The current value is used even for wildcards that have a different default value set in the URL path.

Using wildcard URLs on multilingual sites

The Page URL Path is unique for each language version of a page. As a result, you may encounter problems when referring to a page using a wildcard URL on multilingual sites.

For example, if you create a second language versions of a page with the Page URL Path set to /Members/{UserName}, the language variant’s Page URL Path is automatically changed to /Members/{UserName}-1. This happens because the URL path needs to be unique for every page.

Now assume that you have the following link leading to the page: <domain>/Members/Andy. In the original version, the link works fine. But if you try to click the link in the second language version, no profile is found, because the URL in this language version is <domain>/Members/Andy-1. The modification added to the end of the URL path changes the wildcard value representing the user name, which makes it impossible to find a matching user profile.

If you want to keep such links functional in all language versions, you need to define the /Members/{UserName} path via the Page aliases section, as described in Setting page aliases. When creating the alias, select (all) in the Culture drop-down list. Before you can do this, you need to erase the Page URL Path value for both language versions of the page.

Dots in wildcard URLs

You may encounter problems when a string containing a dot character (“.”) gets into the wildcard parts of URLs.

For example, the problem can occur in a page that has a Page URL Path set to /Members/{UserName}. For the username jack.smith, the URL is <domain>/Members/jack.smith. Because the last part of the URL after the last dot (smith in this case) represents the extension, the URL results in a 404 error.

One way to prevent such problems is to add validation rules that block registration for user names containing dots. If you need to allow dots in user names and use wildcard URLs with user names at the same time, move the wildcard to the middle of the URL path, for example: /Members/{UserName}/Profile