URL Selector for Widgets

Nick Groos asked on October 10, 2019 22:24

We have a widget property where users need to be able to add a URL by selecting a page, media item, or by entering a URL. We have used the URL Selector on pages, but have not found an equivalent component that works with a widget property. Ideally we would just do something like: [EditingComponent(URLSelector.IDENTIFIER)]

Is there an OOTB or third party component that can do this on widgets?

If not, should I be able to create my own modal dialog that returns the URL Selector?

Thanks for any info!

Recent Answers

David te Kloese answered on October 11, 2019 09:54

If you're on the Kentico 12 Servicepack (install Hotfix 12.0.29) you'll get access to the

  • Media files selector
  • Page selector
  • Path selector


There is currently not a combination of the 3 available... So you could use the above and in code verify which one is currently not empty.

Keep an eye out to the Marketplace: devnet.kentico.com/marketplace

Or you'll have to customize your own.

2 votesVote for this answer Mark as a Correct answer

Nick Groos answered on October 11, 2019 19:20

Thanks, David. We are pretty new to Kentico so your opinions are very helpful.

Is the typical approach in Kentico to store content on page types as opposed to widgets? We were planning to make most of our content editable on widgets, but page types seems to have better support for editing content (URL Selector, Rich Text Editor).

We are wondering about the editing experience if we switch to using page types. For example I could move my URL field from the widget to a page and then reference that page from the widget. This would allow us to use the URL Selector instead of writing something custom. But our concern is that content authors would then need to go find that page to edit content, instead of editing inline with the widget.

0 votesVote for this answer Mark as a Correct answer

Mike Wills answered on October 14, 2019 06:52

Hi Nick,

It's typically recommended to store the content in page types, and to use widgets for presenting the content. So, you might have a page type that allows you to store some content, including your URL, and then a widget that allows you to pick the page that has the content you want to display. The widget could also have properties that are used to control how the content is rendered, but not to store the content itself.

This will help you achieve a separation of concerns in the design, so that the content is separate from the website layout. There are several benefits:

  • The content is reusable. It can be used in more than one place in your website.
  • You can change how the content is displayed, even use a different widget to display the content, without having to re-enter it.
  • The content can survive a redesign. If you keep the structure of the content semantic, you could create a new set of views and widgets for the same content, without having to re-enter or migrate the content.

This has been the general recommendation with Kentico long before Kentico 12 MVC. It reminds me of one of the most memorable posts by Brenden.


This is my most favorite approach and most recommended by Kentico and any developer/partner who knows what they are doing with Kentico. Kentico is built around document/page types. If you look at how the content tree and navigation are setup you'll see this approach is not much different than using a static or editable text webpart on a page.

I hope this helps.


2 votesVote for this answer Mark as a Correct answer

Nick Groos answered on October 15, 2019 20:55

Thanks so much, that is exactly the type of answer we were looking for.

0 votesVote for this answer Mark as a Correct answer

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