When you implement supporting pages in your custom feature, you may wish to use friendly URLs for detail pages to improve SEO (Search Engine Optimization) of the content in your custom feature. You can do this the same as it is done in existing features such as the Blog which uses friendly URLs for blog post detail, WebStore which uses friendly URLs for product detail and offer detail pages, and Event Calendar Pro which uses friendly URLs for event detail pages. In fact, I recommend you study the /Blog/EditPost.aspx.cs and WebStore/AdminProductEdit.aspx.cs to see examples where friendly URLs are created.

So, a typical scenario is that you have the ModuleControl.ascx part of the feature which is the part that plugs into a CMS page (i.e., a page in the menu). It serves as the entry point to your feature, and you may have a list of items displayed in the ModuleControl that need to link to supporting page(s). Suppose for example it is a list of products and you want to link to a product detail page which would be a physical .aspx implemented by you and ideally inheriting from mojoBasePage.

So, the URL for your detail page might be /featurefolder/Detail.aspx?pageid=x&mid=y&yourcustomid=z

You need to pass the pageid and module id from your ModuleControl to keep the security context of the current CMS page, to keep the menu highlighted correctly, and to be able to easily make a link to get back to the CMS page from your detail page. In addition, you would pass your custom id for whatever item you are showing details for.

Now obviously this URL with lots of query string parameters is not the prettiest URL and not as SEO friendly as we would like. So, what you do is create a friendly URL record in the database that maps a friendlier URL to this real URL that has all the parameters. Our FriendlyUrl class provides what you need to do this as you will see when you study the code linked above. Once the friendly URL is created in the database our built in URL re-writer will detect URL requests for your friendly URL and it will re-write them to the real URL that is stored with the friendly URL record. The user will see only the friendly URL in the browser navigation bar, but your page will execute using the real URL with the parameters.

You need to of course store the SiteId also on the FriendlyUrl, and you should set the PageGuid on the Friendly URL to a GUID associated with your item. So, on your item table you need a field with a unique GUID for each item row, and you also need to store the relative friendly URL on your item record. This is needed so you can build links to your detail pages from the ModuleControl using the friendly URLs. If your item table is not using a GUID (aka uniqueidentifier) as the primary key, you can still add a uniqueidentifier column and use the sql newid() function for the default value, or you can pass in a .NET GUID when creating the data.

If you delete one of your items you should also delete the friendlyurl passing in the GUID of the item you are about to delete.