Using HREFExchanger and Google SiteMap components for DotNetNuke on a multi-portal site

Posted on by Shifty

DotNetNuke (DNN) is an open-source portal system for ASP.NET. It is pretty good, but out-of-the-box it is not the most search engine optimised (SEO) software that there is. Two components that can help are HREFExchanger ($29.95) and
Google SiteMap ($37.00).

HREFExchanger rewrites the URLs of a site as friendly URLs, such that:

   http://dnn.domain.com/Default.aspx?tabid=109

becomes

   http://dnn.domain.com/contact+us.domain

This is much nicer for the search engines, and will help your new visitors find you.

The Google SiteMap component generates an XML file called a … you guessed it … Google Sitemap. This file tells Google where all of your pages are and helps ensure that your site is fully crawled. I have noticed a big difference since adding sitemaps to my sites. The L-Space Sitemap component is the most expensive for DNN, and also the best. It is the only one that works properly with HREFExchanger, and the support is fantastic. It is worth the extra money.

I have happily combined these two components on a few DotNetNuke sites, but today I ran across two snags. I was adding HREFExchanger and Google SiteMap to an existing site with multiple portals and it was not working. The SiteMaps came out with only two pages listed and with non-friendly URLs. Using the site as such, the URLs were correct, but not in the SiteMap.

The first problem was due to a false assumption I had made. I assumed that Portal4’s SiteMap would be at http://portal4/GoogleMap.aspx and that Portal5’s would be at http://portal5/GoogleMap.aspx. This turns out not to be the case. The true URL for the sitemap is http://portal4/GoogleMap.aspx?portalID=4. Using this URL solved the first problem, now all of the pages on the portal were listed in the SiteMap. But they did not have friendly URLs.

According to the HREFExchanger site, in a multi-portal site with Google SiteMap, you need to make the following (example) additions to your web.config file:

<hrefExchanger extension=".aspx" w3c-output="transitional">
    <portal portalid="1" extension=".page" w3c-output="none">
        <url path="GoogleMap.aspx" action="filter" />
        <urlpath="images/SomeImage.aspx?getimage=1" action="ignore" />
    </portal>
    <portal portalid="2" extension=".dnn" w3c-output="strict" />
</hrefExchanger>

this is not correct. In a multi-portal site, the line <url path="GoogleMap.aspx" action="filter" /> should actually read <url path="GoogleMap.aspx?portalID=1" action="filter" />. Once I discovered this and made the changes, it all worked perfectly.

Hopefully the developers of these components will render this post obsolete in future versions of their products, but for now you need to make these changes.

pinkjoint,shifty,dotnetnuke,dnn,seo,HREFExchanger

Getting friendly URLs to work for WordPress on IIS

Posted on by Shifty

Friendly URLs make a site a lot easier for both humans and search engines to understand. For example, this post can be accessed by two URLs, a friendly URL and traditional URL.

The friendly URL:
https://www.pinkjoint.com/archives/software/blog-systems/getting-friendly-urls-to-work-for-wordpress-on-iis/

The traditional URL:
https://www.pinkjoint.com/?p=8

You are probably wondering why such a long URL would be considered friendly; after all who would want to type out all of that? You would be right on that point, but that is not what we mean by ‘friendly’. What makes this URL friendly is that it is made of words, so the URL gives you an idea of the subject matter. So ‘friendly’ = easier to understand.

So what does this have to do with WordPress or IIS?

WordPress is a blog publishing system written in PHP and using a MySQL database. PHP sites are more commonly run on Apache, and that Apache is likely running on a server using the Linux operating system. Apache can run on Windows, and the Windows web server (Internet Information Services or IIS) can be made to serve PHP pages.

Since WordPress is most likely to be run on an Apache server, the developers have made it capable of taking advantage of some of Apache’s features. One of these is mod_rewrite, which can rewrite a URL on the fly, using the URL as a query string and passing it to a php file for interpretation. So you could consider mod_rewrite as being able to process virtual URLs. mod_rewrite gets its configuration information from a file called .htaccess.

When you first setup WordPress on an IIS server it is by default configured to use traditional URLs, which work fine. After a bit of a look around you will find the Permalinks page, which is inside Options in Site Admin. It gives a few examples and allows you to enter your own URL structure. So you enter a structure, such as /index.php/archives/%category%/%postname%/, and test it out. You get a blank page. Perhaps you did something wrong? You try a few combinations, and even the examples give you the same result: a blank page. This is because IIS does not have mod_rewrite, or .htaccess files, and there is an undocumented step that needs to be taken before your beautifully crafted friendly URLs will work. You need to make a change to the php.ini file that is in the root directory of your WordPress installation.

First, if you have a php.ini file already, BACK IT UP. You will need the following two lines added to the file:

cgi.fix_pathinfo = 1
cgi.force_redirect = 0

If you don’t feel like copying and pasting all of that, here’s one I made earlier. Just save it as php.ini and upload to the root of your WordPress installation. Like magic, your friendly URLs will just work.