URL Filtering in Built-in Content Widgets

The built-in content modules in Sitefinity are the backbone of many projects. That’s why we’ve included a lot of functionality in them that you can use out of the box. Examples of this are paging and filtering on public pages. In some tricky scenarios, those features might not behave like you expect them to with their default configuration. This blog post tries to explain how paging and filtering through the URL works in all built-in content widgets.

Redirects instead of postbacks

From the first line of Sitefinity code that was written, we made the decision to avoid postbacks alltogether, and use AJAX and redirects instead. Unlike in 3.X, all the user interface now either redirects to a different URL or fetches data asynchronously. This includes public widgets. We’ll take paging of items in the News module as an example.

When you have a good number of news items, they are not all shown at once in the public News widget. It has a default page size setting of 20.

In the frontend, this setting displays links to change between the pages on the bottom of the news item list. Notice that when you click a different page, the URL is changed to contain the page number, and the browser does a redirect.

This redirect has several advantages:

• Readability – users of our site can clearly see which page they are currently viewing
• SEO benefits – each page of news items will have a unique URL.
• Link sharing – we can copy and paste the URL to a friend and he will be able to open the same page

If we had used a postback here, we wouldn’t have any of the above. The URL would stay the same.

Filtering by multiple parameters

Another case where this behavior of the News Widget is also present is filtering by taxon (categories or tags). In the screenshot below, I have created two categories and put a Categories widget on the page. Clicking the business category will filter all news items and only show those associated with the “business” category. Notice the URL is changed again.

As long as we have such a URL, the news widget will know that it has to filter items. Having the list of filtered items, we might again decide to page through them and click the link for the second page. In this case, however, the result may surprise us. Clicking the pager changes the URL, but removes the category filter. With this setup, there is no way to page through a filtered list of news items.

The reason for this behavior is that the page does not keep any state. Keeping any state would mean using postbacks and showing different content for the same URL. In this case, search engines will index only the initial version of our page. The nature of the HTTP protocol is stateless and search engines embrace the HTTP protocol. So if we want to do SEO, keep our page rank high, and please search engines, we need to provide different URLs for different content.

With our specific example, this means that both the page number and the category we filter by, have to be present in the URL. If we work with this constraint, we have several options for the URLs:

localhost:60876/home/page/2/-in-Category/Categories/business
localhost:60876/home/-in-Category/Categories/business/page/2

The problem with both of those is that slashes usually represent hierarchical structure and going deeper into the site. This means we don’t have a fixed URL structure and customers visiting our site may get confused. Also, if we want to support both of the above, the problem of parsing and retrieving information from that URL becomes much harder. We need to go through segments, decide which ones are related and what their order is. On the other hand, if we want a fixed order, we need to configure our widgets somehow to tell them whether the page goes first, or the category.

This scenario complicates things quite a bit, and this is the reason that Sitefinity does not support filtering by multiple parameters in the root URL. Instead, we’ve decided to use the query string for the purpose.

Filtering in query string

The query string is the part of the URL that is separated from the core part by a question mark. In that part, we can pass name-value pairs to the page. This gives us a chance to resolve our hard URL parsing problems, because now we have a way of naming our parameters. We can know which parameter is for paging and which is for filtering.

To instruct Sitefinity to use the query string, we need to set a property of all widgets that take part in the process. The property we have to set is called UrlEvaluationMode and is in the advanced section of the widget designers.

Once we change the value of that property to “QueryString”, all widgets will generate URLs accordingly. Here is what our URL would be, if we want to display the second page of a news item list, filtered by the business category:

In this evaluation mode, each parameter that we want to filter by will be added by its name (page, taxon, etc.). These URLs are ugly, but they give us a lot more flexibility when we have complicated scenarios. They are also unique, so all our content is indexed by search engines. One thing to note is that the UrlEvaluationMode property is applied globally to all widgets on the page. We cannot have two content widgets working in two different modes. If we want events to display their page in the URL and news to use the query string, we need to put them on different pages.

The parameters that have built-in evaluators in Sitefinity are:

• Page Number
• Items per page
• Taxonomy & Taxon
• Author
• Date

We can have each of those in the URL at the same time, and the content widgets will work by applying the correct behavior according to each parameter.

These advanced options allow site owners to achieve a lot with the built-in Sitefinity modules, and still optimize their sites for search engines. In a future blog post, we will take a look at even more advanced scenarios with several widgets per page. Happy filtering and optimizing.