Rewriting URLs / specFilters

I am developing a wine site that uses spec filters for all navigation i.e. there is just one category, "wine". I am in the process of putting in links for the top menu, so that, for example, a user can quickly jump to red wine. Instead of having a category I will redirect them to the “wine” category with the red filter preselected. I can do this currently by setting the URL to /wine#/specFilters=14m!#-!436. However, it would be nice both from a user’s perspective and for SEO purposes to make the URL /redwine.

I have looked through the core nop code and I can see how the standard routing is set up to route /wine to the correct controller with the correct id, but I am struggling to work out how to manage the specFilters part of the URL i.e. #/specFilters=14m!#-!436.

Can you point me in the right direction for this? Is this part of the URL being read by one of your DLLs (which I have no access to the code for) or is there something in your javascript that I can modify so that I can achieve what I need?

Hi,

We understand your position, but unfortunately there is no way to achieve this via the files you have access to.
We have a QueryBuilder which handles the building of the url, the change you are asking for won't be straightforward and that is why we could not provide you with a modified version that will work just for you.

To add to Iliyan's answer:

It is not just a matter of having access to the dll files.

Actually if you open this link in your browser "www.yourstore.com/some_category_name#/specFilters=14m!#-!436" you will not be able to get this part "#/specFilters=14m!#-!436" on the server as it is not transferred to the server at all.

The way the Ajax Filters plugin works is also important here.

The Ajax Filters are loaded via Ajax and they are not directly accessible via a URL.
The links that you have are not direct links to a specific controller's action and that is why they can't be accessed via the regular SEO Slugs in nopCommerce.

Let me illustrate this with an example. Let's say you open this link "www.yourstore.com/some_category_name#/specFilters=14m!#-!436".

1. This actually opens the some_category_name in nopCommerce.

2. When the page loads in the browser the javascript of the Ajax Filters sees that there is some hash code #/specFilters=14m!#-!436 and makes a new request via Ajax to simulate the clicking of these specification filters by the client.

So the page loads with all the products in that category and then an ajax called is made to filter them. So it doesn't make sense to make this URLs to be SEO friendly as this pages never get accessed by the search engines.

I hope this makes sense!

Thanks Boyko. I presume then, if this is done in the javascript, we could hack in to that javascript and make some changes so that store.com/category/friendlyurl submits the ajax request as it would for store.com/category#/specFilters=14m!#-!436?

Not really as you still have 2 separate requests. One to load the whole page with all the products and another one that returns a partial view with the filtered products.
Let me explain again assuming you have hacked the javascript.
1. Open store.com/category/friendlyurl in your browser.
2. The whole page loads as it is store.com/category
3. Another request is made to get the filtered products based on friendlyurl.

Now lets say you have 2 links in the menu:
store.com/category/friendlyurl1 and store.com/category/friendlyurl2

Both of them will load the same category page, so for google they are actually the same links as they open the exact same page with the exact same markup (same products).

What you are trying to do is the following:
When you open store.com/category/friendlyurl1 then the markup that the server return should contain already filtered products.
When you open store.com/category/friendlyurl2 then the markup returned by the server should contain another set of filtered products.
This way google can index these 2 pages as if they are 2 different ones.
But this is not possible with the current architecture of the Ajax Filters.
We need to completely rewrite the backend and the frontend of the Ajax Filters to support what you want.

I hope it is clear now!