Take the community feedback survey now.

Magnus Rahl
Jan 22, 2018
  5728
(8 votes)

Increased Flexibility in Commerce Catalog URLs

As all of you probably know there are two built-in ways to route to catalog items in Episerver Commerce: The hierarchical route composed of the catalog/category/entry hierarchy and the "SEO" route which uses a single url segment, which for obvious reasons needs to be globally unique in the site. The hierarchical route story is a different one and we are now improving it in line with partner and customer feedback.

Default: Require Unique URL Segments to Avoid Conflicts

The default hierarchical URL/route is basically going to be /{catalog name}/{category segment}/{entry segment} (this varies a bit depending on setup, but assume this for the sake of argument) where there can of course be multiple categories nested in the URL. But since an entry can be linked to multiple categories there can also be multiple routes to the same entry. This is where the uniqueness gets tricky.

To make entries routable in all categories, Commerce requires the entry segments to be globally unique. That way there is no risk an entry can be linked to a category where another entry is already using the same segment, causing the two to have the same URL in that category. However, in some catalogs it is clear that you would ideally want to use the same url segment for different entries in different categories, and this constraint does more harm than good.

New Option: Avoid Conflicts when Publishing and Monitor Conflicts Later

In Commerce 11.7.1 (soon to be released) we are introducing the AppSetting episerver:commerce.UseLessStrictEntryUriSegmentValidation, which when set to true will drop the global uniqueness constraint for entry segments. Instead, it will ensure uniqueness only with entries/categories in the same category.

However, this validation only happens when publishing the entry and only for its main parent category. This means that if you link entries to multiple categories you risk creating conflicts. For that reason, we are also introducing a new scheduled job Find Catalog Uri Conflicts. The job will find conflicts and write information about them to three places:

  • Write WARN messages to the log.
  • Send emails to addresses specified in the episerver:commerce.UriSegmentConflictsEmailRecipients AppSetting (semicolon separated list of email addresses).
  • Write to the scheduled job output.

Here is some example output:

Image uri-conflict-mail.png

Jan 22, 2018

Comments

valdis
valdis Jan 25, 2018 10:08 PM

nice. mail is sent via element settings, right?

Magnus Rahl
Magnus Rahl Jan 26, 2018 06:25 AM

@Valdis correct, it uses SmtpClient with the default smtp settings.

Please login to comment.
Latest blogs
Automating Cleanup Tasks with Optimizely Scheduled Jobs

Scheduled jobs in Optimizely CMS are a powerful way to automate any background tasks like content cleanup, indexing, or reporting. I created a simp...

Madhu | Nov 29, 2025 |

Implementing Custom Line Item Pricing in Optimizely Commerce 14

In many enterprise commerce implementations, business users often need the flexibility to override product pricing at the cart level - especially...

Sunil | Nov 28, 2025

Using Okta and OpenID Connect with Optimizely CMS 12

Modern CMS solutions rarely live in isolation. Your editors already log into other systems with SSO, and they expect the same from Optimizely CMS. ...

Sanjay Kumar | Nov 28, 2025

Optimizely Opal — working notes from me

A short, practical orientation I use when introducing Opal. Lately I’ve been helping customers and developers understand Opal, and I kept finding...

Pär Wissmark | Nov 26, 2025 |

How to setup Entra ID (formerly Azure AD) for CMS 12 site

Recently, I created a doc about configuring AAD with CMS 12, but it has been posted internally only So today, I would like to introduce it again in...

Tuan Anh Hoang | Nov 25, 2025

Running Optimizely CMS 12 on .NET 10 in Azure

Upgrade your Optimizely CMS website to .NET 10!

Tomas Hensrud Gulla | Nov 21, 2025 |