Then the UrlRewriting would no longer be enough, because it cannot be rewritten to the querystring that contains the Id's, and that would eventually populate the site context. Is there a provider model for resolving the site context? That would of course mean that I would need to do my own mapping from "myproduct" to the actualy product ID, but would it even be possible? Another option would be to create a UrlRewriterProvider that looks up the id's and puts them in the rewritten querystring.
I think you're absolutely right in the last part. The challenge is in mapping the URL part to the product or the cateogry. Especially if the name of the product/category contains characters that are not legal to use in a URL.
What I think you need to do (and I'm just spit balling here, one of the uCommerce devs may have a better answer), is to create a property on both your product and category definitions and call it something like "URL". Hook into the event when a product/category is saved (not 100% sure if this is actually possible), and have it populate a URL friendly version of the products/categorys name. Fx. translate "Rosa's brød" to "rosas-broed". Then write two extensions that can look up the product/category from the URL property. (I wonder if it is possible to hook into Umbraco's character mapping routine? That would be the smart way to do it)
I've done something a bit similar with Filabel.dk (ex. http://www.filabel.dk/shop/Piget%C3%B8j/Pige+Heldragte/pr-4FUNK-10067.aspx). The category part of a product's URL is mapped to the categorys name, not the ID. However I haven't addressed the problem of illegal characters, but just instructed the shop owner of not using any of those characters when creating new categories (I know, don't laugh :-))
The product part of a products URL consists of the prefix "pr-" followed by the products SKU. I probably could have defined it as "product-name"-"pr"-"sku", and have the URL Rewriter just ignore the product-name part, but then I'd for sure run into illegal character issues. But back when I build that solution it wasn't possible to hook into events in uCommerce, so I couldn't have solved the problem with the URL property method.
Disclaimer: Remember, I'm no dev, it's Sunday, and I haven't tought this answer fully trough. There may easily be a way better and smarter way to accomplish this :-)
I hope it answers your question or leads you down the right path.
I'm not sure I need the additional field. I was thinking something like loading categories/products into some static dictionaries on app start, where I would do the "remove dirty chars" stuff, and then use the same dictionary when reading and writing url's.
The question is where to hook in the "reading" part, in order to make the SiteContext class work. Also there is the issue of renaming of products/categories. When the url does not contain an ID, then I would need to store some sort of "history" of names, in order to resolve old url's to the correct product. And that in turn would make a possible clash with new categories/products that might get those new names.
So it might introduce more problems than solutions.
If I were to stay with keeping the ID's in the urls, is there any preference to having the ID as first or last part of the url segment?
Which version of Umbraco are you using? If you are using the 6.1 you "should" be able to do a combination of a sitemap and UrlRewriting.Net to remove id's for the categories at least. I haven't tried this myself yet but I certainly will.
My thought is if you create a RewriteRule with UrlRewriting.Net then you can inside this rule ask the sitemap provider whether the current page is a CategorySiteMapNode (for instance). If the current page is of that type than you know you have to do a rewrite. I'm not sure whether uCommerce has a index on the name or displayname (I don't think so). So to make it more efficient to get the category you save the id of the category on a property on the sitemapnode. When creating the sitemap (and iterate through categories) you set the category id.
It should be durable now when Umbraco "fixed" the issue of creating an UmbracoContext yourself. As far as I know this is only durable in 6.1. (or before 4.11).
I'm using Umbraco 4.9.1, so context shouldn't be a problem. In general, it's not the UmbracoContext I'm worried about, but uCommerces SiteContext which provides access to the current product/category etc.
I don't think I need a sitemap. Just a flat Dictionary<string, int> to map between a url snippet and a category/product ID.
With regards to maintaining a backwards compatability, I would need to hook into every Save action of a category and product. The same actions would also need to possibly trigger an update of the cached url map. But as far as I can tell, there is no such event, so I'm not sure how to do that. It could also be an option to refresh the entire map every time an unknown url is requested, but that could lead to bad performance if the url does not actually exist, and is requested often.
Maybe the safest rout for now is to just go with the option that has
/c-1234-mycategory/p-234-myproduct
At least that would not break anything, and there is no complexity in the caching etc.
You can replace the implementation of ICatalogContext (which SiteContext uses) - it's a pretty simple interface. Create your own implementation, update core.config and you should be ready to roll :)
If you can't add info to the URL you're generating that uniquely identifies the product/category/catalog you can use an alternate solution.
In this solution the actual URL is saved on the product instead of being generated on the fly. In effect making the URL the key you're looking up your product on.
The downside of course is that if the product moves around you may end up in a situation where the URL doesn't necessarily make any sense based on the current location in the catalog.
An option is to update the URL in the SaveProduct pipeline so it matches the current location. Also keep in mind that you need to handle changing URLs to maintain redirects from the old URL to the new one.
Changing uCommerce urls for products and categories
I'm looking in to the options I have for changing the product and category urls for uCommerce.
By default, they look something like this:
Category: /mycategory/c-23/c-1234
Product: /mycategory/myproduct/c-23/c-1234/p-2345
So I can see that I could create my own IUrlService to write the urls: http://www.publicvoid.dk/NiceURLsOptimizeWebshopGooglePageRankWithUCommerceEcommerceFrameworkForUmbraco.aspx
And that could quite easily give me something like:
Category: /mycategory-23-1234
Product: /mycategory-23-1234/myproduct-2345
But what if I wanted to take it a step further? Something like
Category: /mycategory
Product: /mycategory/myproduct
I think you're absolutely right in the last part. The challenge is in mapping the URL part to the product or the cateogry. Especially if the name of the product/category contains characters that are not legal to use in a URL.
What I think you need to do (and I'm just spit balling here, one of the uCommerce devs may have a better answer), is to create a property on both your product and category definitions and call it something like "URL". Hook into the event when a product/category is saved (not 100% sure if this is actually possible), and have it populate a URL friendly version of the products/categorys name. Fx. translate "Rosa's brød" to "rosas-broed". Then write two extensions that can look up the product/category from the URL property.
(I wonder if it is possible to hook into Umbraco's character mapping routine? That would be the smart way to do it)
I've done something a bit similar with Filabel.dk (ex. http://www.filabel.dk/shop/Piget%C3%B8j/Pige+Heldragte/pr-4FUNK-10067.aspx). The category part of a product's URL is mapped to the categorys name, not the ID. However I haven't addressed the problem of illegal characters, but just instructed the shop owner of not using any of those characters when creating new categories (I know, don't laugh :-))
The product part of a products URL consists of the prefix "pr-" followed by the products SKU. I probably could have defined it as "product-name"-"pr"-"sku", and have the URL Rewriter just ignore the product-name part, but then I'd for sure run into illegal character issues. But back when I build that solution it wasn't possible to hook into events in uCommerce, so I couldn't have solved the problem with the URL property method.
Disclaimer: Remember, I'm no dev, it's Sunday, and I haven't tought this answer fully trough. There may easily be a way better and smarter way to accomplish this :-)
I hope it answers your question or leads you down the right path.
/SoerenS
I'm not sure I need the additional field. I was thinking something like loading categories/products into some static dictionaries on app start, where I would do the "remove dirty chars" stuff, and then use the same dictionary when reading and writing url's.
The question is where to hook in the "reading" part, in order to make the SiteContext class work. Also there is the issue of renaming of products/categories. When the url does not contain an ID, then I would need to store some sort of "history" of names, in order to resolve old url's to the correct product. And that in turn would make a possible clash with new categories/products that might get those new names.
So it might introduce more problems than solutions.
If I were to stay with keeping the ID's in the urls, is there any preference to having the ID as first or last part of the url segment?
/1234-mycategory or /mycategory-1234
Hi Morten,
Which version of Umbraco are you using? If you are using the 6.1 you "should" be able to do a combination of a sitemap and UrlRewriting.Net to remove id's for the categories at least. I haven't tried this myself yet but I certainly will.
My thought is if you create a RewriteRule with UrlRewriting.Net then you can inside this rule ask the sitemap provider whether the current page is a CategorySiteMapNode (for instance). If the current page is of that type than you know you have to do a rewrite. I'm not sure whether uCommerce has a index on the name or displayname (I don't think so). So to make it more efficient to get the category you save the id of the category on a property on the sitemapnode. When creating the sitemap (and iterate through categories) you set the category id.
It should be durable now when Umbraco "fixed" the issue of creating an UmbracoContext yourself. As far as I know this is only durable in 6.1. (or before 4.11).
Hope it's usefull.
Best regards Martin
I'm using Umbraco 4.9.1, so context shouldn't be a problem. In general, it's not the UmbracoContext I'm worried about, but uCommerces SiteContext which provides access to the current product/category etc.
I don't think I need a sitemap. Just a flat Dictionary<string, int> to map between a url snippet and a category/product ID.
With regards to maintaining a backwards compatability, I would need to hook into every Save action of a category and product. The same actions would also need to possibly trigger an update of the cached url map. But as far as I can tell, there is no such event, so I'm not sure how to do that. It could also be an option to refresh the entire map every time an unknown url is requested, but that could lead to bad performance if the url does not actually exist, and is requested often.
Maybe the safest rout for now is to just go with the option that has
/c-1234-mycategory/p-234-myproduct
At least that would not break anything, and there is no complexity in the caching etc.
You can replace the implementation of ICatalogContext (which SiteContext uses) - it's a pretty simple interface. Create your own implementation, update core.config and you should be ready to roll :)
- Lasse
If you can't add info to the URL you're generating that uniquely identifies the product/category/catalog you can use an alternate solution.
In this solution the actual URL is saved on the product instead of being generated on the fly. In effect making the URL the key you're looking up your product on.
The downside of course is that if the product moves around you may end up in a situation where the URL doesn't necessarily make any sense based on the current location in the catalog.
An option is to update the URL in the SaveProduct pipeline so it matches the current location. Also keep in mind that you need to handle changing URLs to maintain redirects from the old URL to the new one.
is working on a reply...