DocumentUrlPath remains empty after setting the "Use Name Path for Url Path"

George Tselios asked on March 19, 2020 16:53

Dear All,

In our current project (Kentico 12SP MVC), we have recently set to true the "Use name path for URL path" setting of the "Page Urls" section in the "URLs & SEO" Global Settings.

As a result, all pages of page types that created afterwards hold the expected value in the TreeNode.DocumentUrlPath field.

The problem we are facing has to do with the pages that belong to page types that were created before the above configuration setting change. For these pages the value of the TreeNode.DocumentUrlPath still remains null, even after we re-save these pages in the Kentico Admin.

We would like some clarifications regarding the following:

  1. Is there a way or a work around in order to enable the creation of the DocumentUrlPath for the pages that we have created before the configuration change?

  2. As we understand the DocumentUrlPath is a field that is eligible to use as the live url of a page. In this context the value of the field is constructed by the value of the DocumentNamePath after undergoing a kind of url sanitization, is this correct? In other words, is the DocumentUrlPath a safe field to use for page live urls?

  3. Does the DocumentUrlPath holds a unique value? (In cases that two or more nodes have the same name path)

  4. We noticed that in the CMS_Document table, the DocumentNamePath field has a max length of 1500 chars while the DocumentUrlPath has a field length of 450 chars. Does this mean that for long name paths the DocumentUrlPath is truncated?

Thanks in advance,

Correct Answer

Dmitry Bastron answered on March 19, 2020 18:25

Hi George,

This setting and this behavior is not relevant to MVC development model. Please look at the documentation page regarding these settings - it is only for Portal Engine. Use the following article to learn more about MVC URLs.

1 votesVote for this answer Unmark Correct answer

Recent Answers

George Tselios answered on March 19, 2020 19:43

Dear Dmitry,

Please let me elaborate more about our real need regarding the DocumentUrlPath field.

In our current project a key requirement is to provide the ability to authors to create live (friendly) urls for the content pages that would reflect the structure of the content tree (e.g. the Name Path) and would be totally customizable. Also, the produced urls have to be culture dependent, meaning that the same node/page has to be able to provide a different live url for each supported locale.

In order to fulfill this requirement, we have introduced a string field (named LocalizedUrlPath) in each page type whose page has to be accessible by a url. Also, we have created a module in the Admin application that manages the value of this field. The module is "listening" for a node's Create, Update or Move event and after a url creation and sanitizing process based on the value of the DocumentNamePath, it stores the result in the above field.

In the same context, in our page types we set the "Url Pattern" to /{%ToLower(DocumentCulture)%}{%ToLower(LocalizedUrlPath)%}. In this way the urls produced by our solution have two parts, the first is the culture code (e.g. en-us) and the second part is the "friendly" url.

In order to route this type of urls, we have created a convention-based routing system which routes each page type to a designated controller depending on the page's ClassName (e.g. NodeClassName). In our routing system, we initially take the incoming url and perform a MultiDocumentQuery by using the second part (friendly url) of the incoming url, for any page that has this value stored in the LocalizedUrlPath. Then we use the resulting node's ClassName so as to forward the request to the corresponding controller.

This is the point that we face our biggest problem regarding performance. The generated SQL statement for above query is very slow and does not perform well at all. Imagine that for 25 page types that support access by url, the generated SQL statement is consisting of 25 individual SQL blocks (with two left outer joins each) for each page type and then combine all 25 of these blocks with UNION ALL. Also, such a statement cannot be cached, since at this point, we do not know either the ClassName, the AliasPath or the ID of the resulting node.

I realize by your answer that the DocumentUrlPath is indented for the Portal Engine development model, but my idea was to use this field (since its value is a valid url generated by the Document Name Path) instead of our custom LocalizedUrlPath field.

In this way, first, the management of the field is done automatically by the system and not a custom-made module (that will require support from our side).

Secondly, in the routing process, the MutliDocumentQuery that queries for a node against its DocuemntUrlPath generates a very simple SQL statement targeting the CMS_Document table, which is very performant since DocumentUrlPath is an indexed field, which solves our (big) performance issue.

Also, in this direction, we just need to alter the "Url Pattern" of our page types to something like: :/{%ToLower(DocumentCulture)%}{%ToLower(DocumentUrlPath)%}.

Is such a solution possible in the MVC development model?

Thanks in advance,

0 votesVote for this answer Mark as a Correct answer

Brenden Kehren answered on March 19, 2020 22:12

Just a quick answer, have you looked into DynamicRouting?

1 votesVote for this answer Mark as a Correct answer

George Tselios answered on March 20, 2020 09:36

Dear Brenden,

Thanks you for the suggestion. We did not know that an automatic routing package existed for Kentico MVC. Is this package going to be included in future service packs/versions of the product?

We checked it out and it seems to be close to what we have already implemented. Unfortunately, regarding our current project time plan, we do not have the time to remove the existing routing system and introduce and test a new one. Our routing system was developed in a previous Kentico MVC 12 project which is currently live, so it is heavily tested and working as expected. So in our current project we ported the routing system as is.

What we really need is to enhance the performance of the initial MutliDocumentQuery, so the DocumentUrlPath seemed like a perfect candidate for the job.

Why can't we use this field in the MVC development model? I mean, (depending on the answers of my questions in my previous post), the field stores a url, is managed by the system and there is an existing macro to use in the "URL Pattern" of content pages.

If indeed we cannot use the DocumentUrlPath, is there any other way to introduce a custom field in the CMS_Document table for this purpose?

Thanks in advance,

0 votesVote for this answer Mark as a Correct answer

Dmitry Bastron answered on March 20, 2020 09:56

Dear George,

It's a good question, what the transition will look like. For the next version you can check out Kentico 2020 Beta 2 that has already dynamic routing implemented. It should give you a good idea how it will be in next release. Also, I know that Trevor (author of dynamic routing package) is working closely with Kentico to have a migration path from this module to Kentico official one in the next release.

As per initial question, I'd suggest contacting support directly. Even if it's officially unsupported, Kentico team can give you a workaround I believe.

1 votesVote for this answer Mark as a Correct answer

Juraj Ondrus answered on March 20, 2020 10:24

Well, Kentico support will give the same answer - either use the dynamic routing from Trevor or wait for the next Kentico release. Otherwise it would be a custom development as the logic should be done in the MVC app anyway. Kentico is just a content storage in this case and they can add a custom field into each page type which will hold the URL value they want - the value editors can add or delete and then they can use custom code in the MVC app to work with that value. Or, I believe this is very similar what was already discussed here

1 votesVote for this answer Mark as a Correct answer

   Please, sign in to be able to submit a new answer.