Understanding 301 Redirects 

Posted by Bruce on Wednesday, June 25, 2008 to DotNetNuke, SEO, DNN Tips and Tricks

From Tom:
Please welcome Bruce Chapman as a seablick.com guest blogger. If you are a “regular” around here, Bruce won’t need much of an introduction as he has made a name for himself in the DNN community as a developer of SEO-focused modules and components. In upcoming blog posts, Bruce will shed light onto the technical side of DNN, SEO, and DNN SEO and I’m thrilled to have him on board … welcome Bruce!

The most important piece of advice for obtaining and maintaining a high position in search engine result pages for your website is to get relevant, one-way, inbound links from other respected websites. Relevant in that the link originates from a page with content related to yours, and the link anchor text preferably contains the keywords you wish to rank highly for. Respected websites are those not involved in shady practices such as link farms, and, ideally, represent an authoritative source.

This advice is given just about everywhere - and for good reason. It's good advice, and quality inbound links will have a greater effect on your search result placement than any other optimization technique. However, there's a problem with collecting inbound links that may not be obvious straight away. The problem appears down the road when you decide to change your site in some way. You may need to reorganize your content into a new structure, or perhaps you want to change the platform the site runs on (not that you ever want to move away from DNN :)- You might wish to change the URL scheme, or simply change the URL of a given page. All of these actions have the same effect: the location of the page has changed.

Here's an example:

You set up a page called http://mydomain.com/myverycoolthing.html.

It's an interesting page, and someone submits it to a social news site. As a result, you get plenty of inbound links to it, and you start to rank well in the search results for searches of 'very cool thing.' But after reading a few articles, you decide the URL would be better if it separated out the keywords with a hyphen. So you rename the page 'my-very-cool-thing.html.'

Once you change the URL of a page in any way, here's what happens:

1. visitors following that link from the source page will arrive at a page that no longer exists ('page not found' error)
2. visitors who have bookmarked that page will return to find the page no longer exists
3. search engine robots will revisit the link to discover it no longer exists and remove it from the search index
4. search engine robots following the link from the source pages will discover it no longer exists, and the "vote" of those incoming links is removed from your site

You'll start to slip down the search engine results pages, and soon enough you'll disappear from it altogether. You've undone all of that hard work by renaming the page URL.

Enter the Redirect

The solution, of course, is to redirect all requests for 'myverycoolthing.htm' to 'my-very-cool-thing.htm.' A redirect means that if anyone requests the 'old' URL, they will get forwarded to the 'new' URL. Redirects are nothing new - in fact they are as old as the World Wide Web itself.

The most common redirect you see on websites is called the '302' redirect. 302 refers to the Http status code (see sidebar), and it will temporarily redirect the request to the specified new location (the new location is supplied along with the status code.)

A 302 redirect will ensure that people requesting the Url will get to see the content they expected (points 1 and 2 above). It will also direct search engine robots to the new page and ensure it doesn't get removed (point 3). However, search engine bots will vary in how they treat the weighting of the link (point 4).

It's like when you go away from your house for a while, and get the mail forwarded. Should people update their address books to your new address? Not really, because forwarded mail generally means you'll be back at the original address at some point. A 302 redirect is equivalent to telling the post office to send your mail to a beach house for the holidays, and to stop when you return.

Part of the problem with using a 302 redirect is that it is has been misused by people trying to trick search engines, and it indicates a temporary shift in the URL. So some search engines will update their index to the new URL, others won't, and the end result is not what you are after.

Matt Cutt's blog (Matt works for Google) has an interesting post on the difficulties in interpreting 302 redirects. It's well worth a read for more details on the issue.

A 301 Will Do

A 301 redirect (again, 301 refers to the Http status code) means a permanent redirect, as in 'the resource has permanently moved.' Reverting to the mail metaphor, if you move into a new house, you get the mail redirected to your new location, and at least where I live, the post office takes care of informing your bank, insurance company and government agencies that you have permanently changed your address. A 301 is equivalent to this scenario : we've moved and we're not coming back.

When search engines receive a 301 redirect status code, they know the URL in question has permanently changed, and they will go and investigate and index the new page. They will also assign any link weighting from incoming links over from the old URL to the new URL. This means your page, even if it has completely new content and a new URL, will retain the Google PageRank of your old page. Your page has permanently moved to a new location.

If you search around the Internet long enough, you'll find all sorts of conflicting information about using 301's and search engines. But I'm here to tell you this: it works, and it works well. I've changed the URL on many, many pages on websites, and without exception, it works well.

An Example Using 301 Redirects

I'm always tinkering with my own site, ifinity.com.au. I read my search keyword statistics and make adjustments to URLs and site structure based on what people are actually searching (and finding) the site with.

Originally, I set up a section / subsection in my website called 'What We Do.' I thought this title sounded more personable. But really, I found that people never search for 'what we do.' They search for things like 'products', 'services', 'consultants' and keywords like that. I made the decision to change 'what we do' to 'services.' It's the sort of language that people actually use, and as people speak, so do they search.

The menu structure before the change is shown on the image at the left. Because my site is built with DNN, the URLs are based on the page names, which are also used to generate the menu items. This resulted in a URL of 'What_we_do/Software_Development' for the page.

You can see a screenshot of the Google search results for 'ifinity software development' below. (the fact that Google assumes I mispelled the name - we'll just skip over and cover another day).

The screenshot was taken on May 21, 2008, the day I made the change to the site structure. The relevant URL for the page has been highlighted in red.

The menu structure after the change is shown in the image on the left. The new URL looks like this 'services/software_development/.' It's important to note that I also changed the entire content of the page, rewriting the copy for the page to better reflect what I think people are looking for when they find this page. In terms of search engines, the page is completely different - different URL, different content.

When I changed the page over, I also created a 301 redirect from the old URL 'What_We_Do/Software_Development' to the new page 'Services/Software_Development.' I then monitored search engine bots visiting the new page and whether or not the Google index was properly updated. Within a week, I had my answer from the Google:

This screenshot was taken a week later, for the same search term. As you can see in the red-highlighted area, the page URL was updated, and the page maintained its position in the search results (overall, the site jumped one position, which may or may not be related.) The 301 redirect did its magic, and did so within a week of being issued. Now, you can't rely on 'a week' as the time it takes to get updated. It certainly isn't instantaneous, and it can take much, much longer. There are still some links (a month later) in the index which haven't been updated since my reorganization - these are links which rank low in search results. However, the higher ranked your page, the faster the index will get updated.

Incidentally, you can see my change in the page meta description field, with my 'new' copy intended to encourage more click-throughs from the search results. I'm interested in feedback which seems more 'clickable.'

Checking the Logs

If you're the technical type, like me, you might want to check your website log files to see if the redirect is working as intended. Here is an excerpt from the log files of ifinity.com.au:

 2008-05-22 17:22:25 GET /What_we_do/Software_Development/ - 80 HTTP/1.0 Mozilla/5.0+(compatible;+Yahoo!+Slurp;) - www.ifinity.com.au 301 0 0 473 267 250 2008-05-22 17:22:26 GET /Services/Software_Development/ - 80 HTTP/1.0 Mozilla/5.0+(compatible;+Yahoo!+Slurp;) - www.ifinity.com.au 200 0 0 27433 215 1015 

The first line is the Yahoo bot reading the old URL it expects : 'What_We_Do/Software_Development'. It receives the 301 status code (shown after the domain name) and, 1 second later, returns looking for the new Url of 'Services/Software_Development.' This is the page that ultimately gets indexed and kept, and all old references in the search index are updated. You can see the '200' status code returned after the second URL to indicate that all went OK.

Note: I took some detail out of the log lines for simplicity.

301 Redirects as Repair Strategies

We all make mistakes, and I make quite a few with my own website as I often try out new ideas and software before releasing it to anyone else. One of those mistakes in the past was somehow making the IP address available as domain name. This resulted in a complete, duplicate indexing of my site with associated dilution of ranking and all sorts of other dramas. Once I realized this had happened, I need to correct the index by removing the 'wrong' domain name (the IP address.) You can go through removal tools, but there was a chance that someone had linked to my site using the IP-based domain name. And besides, the site was in the index, I might as well try and merge the sites (ifinity.com.au and the IP address) together.

You can see the problem in the Google result on the left. You definitely don't want this to happen to your site, and if it does, you do want to correct it as quickly as possible.

Again, the 301 redirect is the answer. I built a custom tool which intercepted the IP address based domain, and issued a 301 redirect to the equivalent page using the www.ifinity.com.au domain - in effect, telling search engines that the old domain of 202.60.91.201 no longer exists, and to find all that same information at www.ifinity.com.au'.

The results were successful, a short time after putting in the fix, all of the old IP address indexing had been migrated across to the correct domain name. Although it's not without problems as are still a few references to the IP address still floating around in the search indexes. At least the 301 redirect does put the visitor onto the right page if they click on it, though.

Other Popular Uses of 301 Redirects

Now that you have a basic understanding of using 301 redirects to update search engine indexes, it's time to discuss other applications of the 301 redirect. Mostly, these center around creating 'canonical URLs.' A canonical URL is one that is the 'best' URL for a page - or, if you like, a single URL to unite all the different ways pages can be represented. You absolutely want to encourage canonical URLs for your pages, so that each page in your site only has one single representation. For this it's important to think of a 'page' as a unique piece of content, referenced by a unique URL. So, while /products.aspx?productid=45 and /products.aspx?productId=46 refer to the same physical .aspx page, as far as search engines are concerned, they are two different pages of content.

Taking the products.aspx page a step further, perhaps that same page can be access through additional URLs such as : /products/productid/45.aspx or /products/45/my-cool-product.aspx. These might all show the same content, but the problem is that a search engine might index the first, 5 people link to the second one, and 3 other people link to the third version. You've got the potential for three separate pages to show up in the index, and probably one or more of them will show up in 'supplemental results', otherwise known as 'duplicate content.'

In this case, what needs to happen is for a canonical URL to be chosen by you, and all requests for the page end up at the same URL. The end result is that search engines index a single URL, and anyone linking to your content does so through the same URL. That way, all the value from the incoming links is concentrated onto a single page, giving it a much greater chance of ranking success.

Again, Matt Cutts' blog has a very informative post on this topic : SEO Advice Url Canonicalization.

Having a canonical URL means a single URL for each page of content, no exceptions. When I ended up with an IP address for a domain name, it was the absolute opposite of having canonical URLs. Every single page in my site was available as a duplicate URL.

While you may not have this problem with your own site, you may have another, more common problem : www vs no-www. It's really your choice as a web administrator whether you want to advertise your site as domain.com or www.domain.com. Certainly it makes little difference from a search engine point of view, but what you should be doing is redirecting all the 'www' to no-www, or the 'no-www' to 'www' URLs.

You can take this as far as you want - right down to forcing all versions of a URL to be in the same case (Domain.com -> domain.com) and adding/removing forward slashes (domain.com -> domain.com/). Personally I don't bother with this level as it is my belief that search engines are smart enough to know that 'domain.com' and 'Domain.com' are the same thing. Sure, some Web servers allow content to be differentiated by different case URLs, but most of the time websites will give you the same content, regardless of what case it is requested in. But it's up to you as the website owner and person ultimately responsible for search traffic to make sure it functions the way you would like.

301 Redirects and DotNetNuke

How does all this apply to DotNetNuke-based websites you ask? For a start, there isn't any 301 functionality 'baked' into the DNN core framework. But that's OK, because DNN runs on top of IIS, and IIS has plenty of functionality for forwarding and redirecting. For those in a shared hosting environment without direct access to IIS there is the option of installing third-party products to set up custom redirects.

The three biggest problems with DNN URLs and search engine optimization, as I see them, are:

1. No canonical URL functionality:
   The home page is typically available on the site root (/), /default.aspx?tabid=36, /tabid/36/default.aspx, /home/tabid/36/default.aspx, home.aspx and just plain old /default.aspx.
2. No separation of keywords in the generated Page URLs"
   'My Cool Thing' ends up being 'mycoolthing.'
3. No redirection of deleted or changed pages:
   Once you delete a page, it won't forward you on or show any content.

These three issues can all be remedied by using 301 redirects. There are many ways to do this - either by setting up individual redirects in IIS, using a third-party IIS tool for setting up redirects, or using a dedicated DNN 301 module, of which there are multiple available.

Of course, now is the right time to plug my Url Master DNN Url Redirecting and Rewriting module. This DNN module provide a solution to all of the above problems, and many more. It features automatic 301 redirects to enforce canonical URLs, plus the ability to add custom redirects to handle all types of situations where content has been moved or deleted.

Summing Things Up

With any luck, you have learned what a 301 redirect is, and why you should be using them to maintain and increase your position in the search engine results pages. Once you have established yourself in the indexes, it's important you manage your URLs effectively otherwise all your hard work might just be undone.

Do you disagree with anything? Do you have more to add? Submit your thoughts using the comments field below.

 Permalink       3 Comments       RSS feeds       Email updates

DNN SSL: Securing the Login, Register, Admin and Host Pages 

Posted by Tom on Thursday, May 22, 2008 to DotNetNuke, Ecommerce, DNN Tips and Tricks

I am trying to SSL enable the Login, Register, Admin and Host pages, however, I see no way to do that in DotNetNuke. I am using version 4.8.2, and when I go to the pages section under admin I see no Register, Login or admin/host pages listed there.
So this begs the question, how do you mark the Secure Login checkbox on those pages when they aren't visible in the pages listing?

The other day I came across the above question on the dotnetnuke.com forum and it felt like a good opportunity to revisit the topic as its been well over a year since I first blogged about it.

Most of you are probably aware of the fact that native SSL support made its way into DNN with version 4.5.4. And right around that time John Mitchell published a short and sweet tutorial that shows you how to take advantage of the DNN’s new SSL capabilities and I urge you to first digest John’s post before following along here.

As you may have noticed, John’s walkthrough doesn’t directly address the common scenario of securing the DNN Login, Register, Admin, and Host pages, which is not as simple as you might expect. To SSL secure the Login and Register pages follow these steps:

1. Create “custom” Login and Register pages by adding 2 new pages to your website.
2. Drop the Account Login module onto your new Login page and drop the User Account module onto your new Register page.
3. Then tell DNN about your newly created Login and Register pages by pointing to them via Admin > Site Settings > Advanced Settings > Page Management.
4. Finally, mark the 2 pages as “Secure” via Page Settings > Advanced Settings > Other Settings > Secure as described in John’s tutorial.

Again, not as straightforward as it should be, but it certainly works.

What about the Admin and Host pages you say? Well, that’s a totally different dilemma, which I have not figured out yet - short of “hacking” the Tabs database table directly. And even that I have not tested yet, but I don’t see why it wouldn’t work. What certainly works is a 3rd party component that I’ve come to rely on (food for another blog post.)

With that said, does DNN support SLL natively? It sure does, but as with many initial attempts, it’s a little rough around the edges. What I would like to see in Cambrian (also known as DNN 5) is 3 additional checkboxes under Admin > Site Settings > Advanced Settings > SSL Settings to secure the Login, Register, and Admin pages. Will that work or does it spell trouble for multi-portal installations? What about the Host pages? Suggestions anyone?

 Permalink       1 Comments       RSS feeds       Email updates

Customizing FCKeditor Toolbars 

Posted by Heidi on Tuesday, April 15, 2008 to DotNetNuke, DNN Tips and Tricks

FCKeditor has been the default rich-text editor for DotNetNuke for quite a while now. I find it mostly intuitive and easy-to-use right out of the box. It provides more functionality than most website administrators will ever need and behaves much like any familiar Microsoft office application. There are times, however, when you’ll want to trim back some of that capability to avoid confusing your website users.

For example, we use Active Forums on liftkettlebells.com. We intended to give our users some limited text formatting ability, but the default FCKeditor includes a whopping 48 toolbar buttons! Frankly, it looks too busy and no one uses all those buttons when drafting a forum post. We just wanted to offer our visitors a few obvious options to pretty up their posts: bold, italics, bullets, lists, and hyperlinks.

One approach is to make modifications to your toolbars in the fckconfig.js file located in \Providers\HtmlEditorProviders\Fck\Custom, but those changes are then applied globally. I suggest using this method if you want to add/delete single buttons on the toolbars themselves. Let’s save those details for a future blog post.

For now, let’s focus on "hiding" toolbars using the FCKeditor's custom options page. If you are logged in as a host or admin, you will see a Show Custom Editor Options link below the compose window of any FCKeditor instance.

In Active Forums, for example, pick any forum and click the Add New Topic button. Then click Show Custom Editor Options.

Notice the three Settings Type options: Instance, Module, and Portal. These options are meant to confine your custom settings to a single instance of FCKeditor, to every instance within the current module, or portal-wide to every module and instance on your website. Unfortunately, it often doesn’t quite work that way. You may need to experiment with your selection to get the intended results. In this case, I’ve found that Instance modifications actually push my changes out across the entire Active Forums module. A little counter-intuitive to say the least!

Select Editor Toolbar View Options to view your toolbar choices. This is where you "turn off" unwanted toolbars. Select the pencil icon to expand the selected toolbar. For example, DNNDefault. Note, you may need to scroll back down to the Editor toolbar view options section after clicking the pencil icon.

You can disable the toolbar for all users, or a selected subset of users based on role. For our forum, I checked Disabled for All Users. Attention, you must click on the check mark image to the left of the row for your changes to take affect. This is another quirky little detail that took me a few hours to figure out!

You will need to repeat these steps for each toolbar you want to disable. So, I also disabled the Default and NoGallery toolbars. That leaves only the desired Basic toolbar visible to our users.

Once you have disabled the unwanted toolbars, click Apply in the Apply Custom Settings To section with Instance selected in the dropdown box. You should then see a “Settings applied successfully to Instance” message as shown below.

Now close the dialog box. To see your changes, don’t forget to click Refresh Editor at the bottom of the compose window.

And that’s it! These changes are only applicable to Active Forums. So, when I’m editing content using any other modules, I still have access to the full suite of toolbars. But, my forum members get to see a simpler, smaller set of formatting choices:

We would love to hear from you. What have you learned while customizing the FCKeditor for your needs? Please share in the comments below.

 

 Permalink       10 Comments       RSS feeds       Email updates

Fixing the DNN Breadcrumb Skin Object 

Posted by Tom on Tuesday, January 29, 2008 to DotNetNuke, Downloads, DNN Tips and Tricks

We've all seen them; the bar of links usually found at the top of websites with multi-level navigation. Location breadcrumbs aide visitors in traversing content-rich sites by providing feedback on how "deep" visitors have navigated into the site and on how to get back where they came from. If properly implemented as text links, breadcrumbs also provide SEO benefits by allowing search engine spiders to more effortlessly crawl web content.

The DNN breadcrumb skin object, which is installed by default, makes it easy to implement breadcrumbs in your skins so there is really no excuse not to use them. Placing this line <dnn:Breadcrumb runat="server" id="dnnBreadcrumb" RootLevel="0" /> into your ascx-based skin renders the path to the currently selected tab in the form of TabName1 > TabName2 > TabName3. Optionally, you may specify a breadcrumb separator and a CSS class.

The only rub that I have with DNN's breadcrumb skin object is that the last item in the trail also renders as a link. You may think "what's the big deal," but I like to argue that this shortcoming works against the very benefits discussed above. Why would I want to navigate to the page that I'm already on?

So what's a dedicated DNNer to do? Here are 3 approaches one might take to "fix" the DNN breadcrumb skin object:

1. Hack the breadcrumb trail with JavaScript.
2. Modify the DNN skin object code.
3. Write a custom breadcrumb skin object.

Let's look at these approaches one at a time.

JavaScript Hack

We simply target the last item in the breadcrumb trail and remove the href attribute. We then adjust the style due to the fact that even without a href attribute the <a> tag remains, which means it takes on the default link style although it's not a "live" link. Download the script here. Not the most elegant solution, but it works.

Modify the DNN Skin Object Code

This time around we add an additional public property - LastAsSpan - to the Public Members region of breadcrumb.ascx.vb that allows us to enable or disable the rendering of the last item in the breadcrumb trail as a link. Still in breadcrumb.ascx.vb, we then turn our attention to the Page_Load event handler and add a few lines of code that ultimately process our new setting. Download the commented code and then backup and replace breadcrumb.ascx.vb in admin/skins. No recompiling necessary, but you may have to restart DNN to clear the cache. For the politically correct, this constitutes a DNN core change and therefore gets overwritten by subsequent DNN upgrades. So again, far from ideal and more an illustration of concepts then a real-world solution.

Write a Custom Skin Object

This approach makes the most sense on all fronts and follows the "official" guidelines on extending DotNetNuke. Just install the custom skin object, register the new control and change the breadcrumb declaration in your existing skins and you are done. More details in the free download. I'm only a DNN module developer during REM though, so for anyone interested in the nitty-gritty of writing your own skin objects, keep an eye on Mitchel Sellers' blog later this week.

So there you have it, 3 roads to breadcrumb heaven. I'll leave it up to you to decide what approach works best for your unique situation.

In closing, I would like to thank Vasilis Terzopoulos and Mitchel Sellers for their generous contributions to this post. As always, post your comments and questions below. And if you have enjoyed this material, consider subscribing to our RSS feeds or signing up to get blog updates by email.

 

 Permalink       7 Comments       RSS feeds       Email updates

DNN URL Rewriter on Steroids 

Posted by Tom on Wednesday, January 16, 2008 to DotNetNuke, SEO, DNN Tips and Tricks

While fighting and ultimately losing an uphill battle against a commercial URL rewriting module last week, I came across Bruce Chapman's blog. To make a long story short, Bruce picked up Scott McCulloch's Friendly URL's slack and vastly build on it and improved it.

Back in August 2007, Bruce first tackled an issue commonly seen in more complex DNN modules: an abundance of URL query string parameters (see any permalink on this blog for example.) Next, Bruce implemented the ability to "automatically" 301 redirect DNN legacy URLs so that established DNN-based websites who have already been indexed by Google and company won't be penalized for duplicated content while taking advantage of the more "human friendly" URLs provided by Bruce's rewriter. This feature alone means a big leap forward for the world of DNN SEO.

More recently, Bruce took things even further and added, among other things, functionality such as "freedom of extension" (.aspx, .page, or whatever else makes your heart beat faster) or my favorite: no extension at all (who said we can't have those nice WordPress URLs, eh?) Due to popular demand, Bruce also put effort into replacing spaces in tab names with dashes and forcing all generated URLs to be lower case. Most features are configurable via web.config.

I still very much appreciate Scott McCulloch's pioneering in this area, but with Bruce Chapman, DNN finally has the attention of a talented developer with an SEO mindset, which in my opinion is an essential prerequisite for success when working on the "search engine facing" parts of our beloved web application framework.

Free downloads including source and sample web.config files are located here (scroll way down.) And don't hesitate to ask installation and configuration questions here or over on Bruce's blog.

 

 Permalink       6 Comments       RSS feeds       Email updates

Become a DNN Video Star 

Posted by Jeff on Monday, November 19, 2007 to DotNetNuke, DNN Tips and Tricks

If you haven’t noticed, video has become a major part of the Internet experience. From a site visitor’s perspective, a picture is worth a thousand words. A moving picture with audio is worth even more! For SEO purposes, you of course need to make sure your site contains an appropriate amount of relevant text. Get that done if SEO is important to you. Then pay firm attention to the idea that you should always use the medium that will deliver the most insight for the least intake effort for any given topic.

For example, I’ve struggled to explain the importance of RSS to friends and family. Most websites with an RSS button dedicate a page full of text to explaining it. I know what it’s all about and those even put me to sleep! Here’s a beautiful example of making a point that will stick using video:

So, how can you include video within DNN?

There are many options and formats. You could go with Quicktime, Windows Media, or Flash, for example. I’ve tried a ton of delivery methods. My primary concern is having videos that can be seen by the biggest percentage of site visitors. Flash (.flv) is my favorite, but I reached a limit of about 90% success. When I changed to different flash players, it was always 1 step forward and 1 step back. The best solution I've found is to offer a solid FLV option and add a backup link to a Windows Media (.wmv) version of each video. That'll get you as close to 100% overall coverage as is possible!

There are a couple of DNN video modules on Snowcovered. I’m sure they are fine if you only need to put your video in a specific pane of a specific page. More than likely, however, you’re going to want to embed a video in-line within a Text/HTML or blogging module. For that reason, I suggest looking into a method that will allow you to place snippets of code in the “source” view of any rich text editor.

As long as you aren't expecting an insane amount of site traffic, you can easily purchase some cheap hosting to store your video assets. Then just point back to those files from your main website in these code snippets. The videos will be delivered as "progressive download" and will work just fine. There is no need to go spend bigtime cash on a streaming solution.

For self-hosted Flash players, I like the guys at Earth Science Agency. They have been very responsive when customizing players for me. ESA offers a standard javascript code snippet format, or you can get into some interesting XML based playlist players. Alternately, here is a popular free Flash player from Jeroen Wijering. Self-hosting is a good option if you don’t want advertising and don’t need viral distribution tools.

If you are hoping to attract traffic to your site through viral marketing, you’ll want to use an outside video service. YouTube is the big dog in this arena and still the best choice for most people. The downside is relatively poor video quality and occasional advertising overlays.

There are dozens of good services competing for Youtube’s dinner, such as Veoh, Revver, and Brightcove. Many of them offer superb video quality and other unique features. For instance, check out Viddler’s interactive commenting technology. Almost all of these services remain free for you by injecting pre-roll, mid-roll, post-roll, or overlay advertising messages on your videos. Many of them will even share as much as 50% of this advertising revenue with you. So, you could actually make money from inserting videos on your site! Don’t plan to buy a new car with the proceeds, though. A super-sized McDonald’s value meal might be more plausible.

I really like using these services because it's their job to make damn sure the players function properly for the widest audience possible. It also takes my attention off the code snippets. I don't really care to read or understand the code. I just want to cut and paste it into DNN. Just go to any Text/HTML module, open a rich text editor (such as FCK Editor), click the "source" or "HTML" view, and paste the code in. Voila, instant video! I usually switch back to the WYSIWYG view as quickly as possible and get on with writing my copy.

I hate Google Adsense. Sure, you can pretty it up with colors, fonts, backgrounds, and placement. But, let’s say you’ve done your job and created a beautiful, content rich, interactive website. To me, adding an Adsense sidebar is like vomiting on a van Gogh. Video ad placements can actually be far worse than text-based Adsense. Pre-roll video ads are particularly nasty. A pre-roll ad is usually an 8-12 second video clip from some company like Crest, Chevrolet, or Verizon that “rolls” immediately after your site visitor hits the “play” button. The ad plays before the content your visitor actually wanted to see. Pre-roll ads are a sure way to drive people away from your site. Show me the candy first, then show me your commercial.

I give YouTube high marks here as well. Their video overlay ads cover just the bottom quarter or so of your video while it plays. More importantly, your site visitor has the power to click “x” to banish the ad if she so chooses.

My favorite video service based on video quality and features is easily Brightcove. They get one huge blackmark in my book for the use of pre and post-roll ads, however. If Brightcove would just adopt the YouTube overlay ad style, it would be unbeatable. Brightcove offers a wildly convenient conversion/upload tool that resides on your local machine and handles all your video uploads with a fantastic batch process. You get full control to customize the look and feel of your players, and it is very easy to create slick multi-title players. I also like that Brightcove offers both Javascript and IFrame embed codes. Unlike many other tools (like Wordpress), DNN will actually allow you to use these codes! Why is that important? Because it avoids the ugly “click to activate” issue in IE.

I have been labeled “perfectionist” and a few other four letter words in my life. So take this with the appropriate grain of salt. I really dislike the little gray bounding box and “click to activate” message that appears when you hover over an html embedded video for the first time. See the video at the beginning of this post, for example. If that’s not a big deal to you, then ignore this last bit. If it in fact offends your artistic sensibilities, then I highly recommend you check out Vasilis Terzopoulos’ fix for this issue: Add Flash content to your skins, the right way.

I’ve just learned that this issue should be a thing of the past in the near future. See this article on Microsoft’s permanent fix for the problem scheduled to hit sometime in 2008. Of course, you've all probably been around software long enough to avoid premature celebration. I'm sure it will take them awhile to roll this out. Plus, it looks like you'll also need to wait for every websurfer to install an IE Cumulative Update. Hmmm ... you might want to stick with Vasilis' recommendation for now.

Adding video content to DNN based websites is very easy. Surprisingly, I don’t see it often enough. I recommend you take a hard look at your website. Look for wordy concepts that might be more exciting and straightforward in video. Scour YouTube for videos that support your textual content. Shake things up by delivering an occasional blog post of yourself speaking on film. Bring some warm humanity into your online creation and your site visitors will thank you.

 Permalink       9 Comments       RSS feeds       Email updates

An Introduction to the DNN Folder Structure 

Posted by Mary on Tuesday, September 25, 2007 to DotNetNuke, DNN Tips and Tricks

Now that I have covered the DotNetNuke installation process, I would like to begin “dissecting” the application from a developer’s position to gain a better understanding of what is going on “under the hood.”

This week I’m taking a closer look at the folder structure, which presents itself after opening the DNN solution file in Visual Studio. This lays the foundation for my continued quest of “how to” develop with DotNetNuke.

Upon opening DNN in Visual Studio, the folder structure resembles an ASP.NET web site in its basic form. Digging deeper, I discovered some cool features that DNN has already “laid out” for us. After all, isn’t this the biggest perk of using DNN? I am working with Visual Studio 2005 and DNN 4.5.3 for this discussion. There will be slight variations depending on which version of DNN and Visual Studio you are using.

When you start an ASP.NET web site (in VS 2005: File | New | Web Site | ASP.NET Web Site) a basic files and folder structure is created: default.aspx and web.config files minimally. DNN adds a number of folders and files to this basic structure, which I will not be able to cover in its entirety as this is a much larger topic than my allotted space allows. The folders I’m discussing below have, for the most part, a specific bearing on DotNetNuke:

1. Admin
2. App_Code
3. App_Data
4. App_GlobalResources
5. Bin
6. Controls
7. DesktopModules
8. Portals
9. Providers

1. Admin Folder

After a successful DNN install, you can browse your portal and it acts as a basic “shell” for your website. You can begin adding users, roles and pages without writing a stitch of code. Most of this administrative functionality lives in the admin folder and its corresponding database objects. These files and folders should be left untouched unless you truly understand what you are doing. However, it is a good place to start looking around to gain a better understanding of the DotNetNuke core.

2. App_Code Folder

The App_Code folder has a special status in the ASP.NET world as well as in DotNetNuke. Place common code such as the business logic layer (BLL) and the data access layer (DAL) for your DNN modules into this folder, with an individual sub-folder for each module. For example, for the “HelloWorld” module, I placed my DataProvider.vb, HelloWorldController.vb, HelloWorldInfo.vb and SqlDataProvider.vb files into this folder.

3. App_Data Folder

This folder contains the SQL Server Express database (.mdf file), which is used as the default data store in the web.config file.

4. App_GlobalResources Folder

This folder contains global resource files and other localization files in support of the DNN localization system. This is another folder that is typically not modified and its design is the reason why DNN cannot be pre-compiled.

5. Bin Folder

This folder contains compiled assemblies (.dll files) for modules, data providers, 3^rd party components, ect. You will see quite a few existing assemblies by default and the number will only increase as you install modules.

6. Controls Folder

DotNetNuke comes with a set of web controls that have been written specifically for the DNN environment. They extend or abstract the functionality of existing ASP.NET components and allow module developers to access native DNN controls such as the text editor, label control, and URL Control. Each control is implemented as a standard .ascx file that can be referenced by custom modules. For details visit Jon Henning’s blog as he leads the development and documentation of DNN web controls.

7. DesktopModules Folder

DotNetNuke modules are built in 3 tiers: DAL, BLL and the Presentation Layer. I briefly noted above that the DAL and BLL files are in the App_Code folder. The Presentation Layer resides in DesktopModules. For each module you create or install, a sub-folder is created. Within that module sub-folder, the following files can be found for the HelloWorld module:

• local resources (.resx files)
• documentation
• SQL scripts (.SqlDataProvider files, typically inside a Providers folder)
• view/edit pages (.ascx files)
• settings.ascx (accessed from the “Settings” action menu item)
• module manifest file (.dnn file)

This sub-folder, along with the App_Code (BLL/DAL) folder, contains all the code necessary to run the HelloWorld module. Among other things, a module’s .dnn manifest file specifies the folder name for the module and you must be sure to provide a unique name for each of your modules.

8. Portals Folder

A single DotNetNuke installation can support multiple portals (websites.) The default portal configured during DNN installation occupies folder 0. This association is made based on the assigned “PortalID” value from the Portals database table. When you add additional parent or child portals, a new sub-folder is created under the Portals folder according to its PortalID (1, 2 ...) Visit DNN Creative Magazine for a nice illustration of this process.

9. Providers Folder

In this folder you will see a DataProviders\SqlDataProvider sub-folder, which contains xx.xx.xx.SqlDataProvider files. These files are the SQL scripts for each DNN version/upgrade. Notice that the last xx.xx.xx.SqlDataProvider file is 04.05.03.SqlDataProvider as we’re working with a DNN 4.5.3 install. Besides data providers, you’ll also find at least the html editor providers and logging providers in this folder. Think of providers as exchangeable components similar to modules only that providers act more “behind the scene” in support of modules. For instance, if you don’t like the default FCK text/html editor, you can easily replace it with the Telerik text/html editor. Just add a folder under /Providers/HtmlEditorProviders for the Telerik provider and modify the <providers> selection in the web.config to point to the provider.

I hope that this blog post helps aspiring DNN developers to take the next steps on their path down DotNetNuke lane. As always, feedback and comments are most appreciated.

 Permalink       5 Comments       RSS feeds       Email updates

A Newbie’s Guide to Installing DotNetNuke 

Posted by Mary on Monday, September 10, 2007 to DotNetNuke, DNN Tips and Tricks

Welcome to my first contribution to the Seablick Consulting blog! When Tom Kraak first asked me to write a “how-to style” blog post, I was thinking to myself, “what can I offer in regards to DotNetNuke? I’m a newbie!” Then I began to realize how much I have learned in a very short amount of time. I also realized that I am looking at DNN from a different point of view than someone with years of experience. So I may (and will) ask a lot of questions and I DO like feedback. One thing that I was very impressed with right from the beginning was the community’s assistance and reassurance of my success. So for my first post, I decided to detail my experience of learning how to do a local DNN install.

Installation is murky when you are new. As a developer, I like to know what is going on, where it’s going on and who it’s going on with. At first, I didn’t understand how the database “fit” into the architecture of a DNN site. Once I had a clean install up and running, I was able to go into SQL Server Management Studio (or the like) and actually look at the tables, select on them and see what the install had created. That’s when I began to get a bigger picture of how DNN works.

My local setup consists of a Windows XP Pro machine running IIS 6, SQL Server 2005, and the .NET 2.0 Framework.

There are 5 basic steps to a clean install. I will cover each individually in more detail below.

1. Download the .zip file from dotnetnuke.com.
2. Create the database and a SQL Server login
3. Create the website folder and unzip the downloaded .zip file.
4. Create virtual directory in IIS and configure the website
5. Run the DNN install wizard in your favorite web browser.

1. Download the .zip file from dotnetnuke.com.

After you have logged into dotnetnuke.com, navigate to “Downloads”, select the desired file and save to your C: drive (for our example, I selected and downloaded the 4.5.3 INSTALL (DotNetNuke_04_05_03_Install.zip.)

2. Create the Database, SQL Server Login, and Database User

There are two things you need to do in SQL Server Management Studio. First, create a database. Second, create the SQL Server login for that very same database. Make sure that your database server runs in “mixed authentication mode” (SQL Server and Windows Authentication mode” is checked.) You can find this setting by right-clicking on your server (first node in the SQL Server Management Studio tree on the left), then Properties | Security.

Create the Database

• Open SQL Server Management Studio
• Select your desired server from the drop-down list and connect
• Expand the tree on the left-hand side so you can see “Databases”
• Right-click on "Databases"
• Select “New Database”
• In the "Database Name" field enter a name for your database and click OK. For this example, I entered “DNN453”
• You now have an empty database called DNN453

Creating a login for your database:

• Expand the Security node of your server
• Right-click on Logins
• Select “New Login”
• Enter your desired login name. You must remember this login name and password as we will use it later. For my purposes here, I’ve entered “DNN453Login” (without the quotes) as my login name.
• Select “SQL Server Authentication” and enter a password. I entered “test” as my password.
• Uncheck “Enforce Password expiration/User must change password at next login”
• Click “User Mapping” on the left
• Select/Check the new database you created in the top grid “Users mapped to this login:”
• Select/Check db_owner in the bottom list “Database role membership for: “
• Click OK
• Now look in the Security node under your database (DNN453) and you will see a newly created database user listed, meaning we also created a new database user by mapping our SQL Server login to our database.

The database portion is now complete.

Create the site folder and unzip the downloaded .zip file.

In this step, we create a folder and unzip the DNN install .zip file to this directory. You can put it directly under C:\inetpub\wwwroot or C:\foldername. For this example, I used C:\DNN453.

• In Windows Explorer, create a new folder called DNN453 on your C: drive. This will be the folder where your website files will live.
• Extract (unzip) the DotNetNuke_04_05_03_Install.zip file that you downloaded earlier into your desired folder (C:\DNN453 in our example)
• After extraction is complete, the folder contains a web.config file that needs to be modified. Remember how I stated in the beginning that DotNetNuke and the database “fit” together? We must now tell DotNetNuke which database our website is using. We do this in the web.config file. The default web.config file even gives us “samples” of connection string entries so that we only need to modify these based on our database setup.
• Open the web.config file and find the <connectionStrings> tag. You can use Notepad, Visual Studio or any other text editor to accomplish this. There you see two entries of connection string statements – one for SQL Server Express and one for SQL Server 2005. By default, DNN uses SQL Server Express. The connection string for SQL Server 2005 is commented out. For our example (we are using SQL Server 2005), we must reverse this and comment out the SQL Server Express statement and “uncomment” the SQL Server 2005 statement. After that, we need to enter the correct values for server, database, uid and pwd according to the database we set up above. In the below screenshot, XP1234 is my machine/my local SQL Server (please note, if you are using server instances, it is entered as: XP1234\MYINSTANCE where MYINSTANCE is the name of the SQL Server instance). DNN453 is the database name (as specified in step 2.) Enter "DNN453Login" and “test” for uid and pwd, respectively.
• We must also modify the key for the “SiteSqlServer” under the <appSettings> tag. Again, SQL Server Express is the default, with SQL Server 2005 commented out. We must comment out SQL Server Express and uncomment SQL Server 2005 and again, enter the correct values for server, database, uid and pwd for our database.
• Save and close the web.config file
• Lastly, you must change the access permissions of your folder. The Windows account that is used to access your site must have full control over your DNN root folder. To set this, right-click on the root folder of your site (C:\DNN453). Click Sharing and Security. Click the Security tab. If you do not see the Security tab, you must “turn off” simple file sharing for the folder. To do this, select the root folder (C:\DNN453) in Windows Explorer. Click Tools | Folder Options. Select the View tab. Uncheck “Use simple file sharing.” Click OK. You can now right-click the folder and access the Security tab.
• On the Security tab, you will see a list of users who have access to your folder. Windows XP uses the ASPNET account and Windows 2003 uses the NETWORK SERVICE account. Add the account and give it full control permissions.

4. IIS – create virtual directory and set-up

Now that the database and file system are in place, we can create the virtual directory in IIS.

• Open IIS and expand the tree to see “Default Web Site”. (You can find IIS in Start | Control Panel | Administrative Tools.)
• Expand the "Default Web Site" node.
• If you have placed your DNN root folder under C:\inetpub\wwwroot, you will already see your website and can bypass this step. If not, you will need to add a virtual directory.
• Right-click on "Default Web Site"
• Click New | Virtual Directory
• Enter an alias – "DNN453" will do
• Click Next and enter/browse to the path to the root folder of your website.
• Click Next and leave access permissions as is (should be set to Read/Run Scripts.)
• Click Next and Finish

Now that a virtual directory is in place, you’ll need to modify its properties.

• Click on the "Documents" tab
• An entry for “default.aspx” needs to be added. Add default.aspx and move it to the top of the default documents list.
• Click on the "Directory Security" tab
• In the “Anonymous access and authentication control” group box, click "Edit"
• Make sure that “Anonymous Access” is checked as well as “Integrated Windows authentication”
• Next, click on the "ASP.NET" tab and make sure that “2.0.50727” is select for the ASP.NET version
• Click OK to save your changes

5. Run the DNN install wizard in your favorite web browser to complete the installation process.

The very last step is to initiate the DNN install via a web browser. The install wizard takes over. In doing so, it creates tables and stored procedures in your database and adds the needed data rows to these tables to house your site. You will be prompted to test your folder’s permissions, test the database connection and lastly, enter your desired user name and password for your host and admin user. Write these down!

• Open your web browser of choice and navigate to http://localhost/DNN453 (replace DNN453 with the name of your IIS virtual directory)
• You will be guided through an install wizard. Test your folder permissions when requested.
• Verify your database connection when asked.
• You will see the wizard running the script for each version.
• On successful completion, click on “Access your Portal” and your new DNN-based website appears.

I hope that this tutorial offers DNN newcomers a better understanding of the DotNetNuke installation process on Windows XP Pro and SQL Server 2005.

Lastly, I would like to thank Tom for giving me this opportunity and for his patience and guidance. I’m hoping for a bright future with DNN.

Did I miss something or got something wrong? If so, I want to hear about it. Please leave your comments below as feedback is much appreciated!

 Permalink       45 Comments       RSS feeds       Email updates

Running DotNetNuke on 64-bit Windows 

Posted by Tom on Wednesday, July 11, 2007 to DotNetNuke, DNN Tips and Tricks

On a recent project I was tasked with moving a DNN 3.2.2 based website to Windows Server 2003 x64 Edition. What I ran into is not directly related to DNN, but more so to the .NET 1.1 framework which ASP.NET and DNN rely on.

First I noticed that .NET 1.1 was not installed on the 64-bit box. So I downloaded the redistributable package from Microsoft, who lists the 64-bit version of Windows Server 2003 SP1 as a supported operating system. Shortly after starting the installation though, I was greeted with the following message:

This "incompatibility" refers to the fact that 64-bit processes cannot load 32-bit DLLs. The Windows-32-on-Windows-64 (WOW64) compatibility layer was introduced with Service Pack 1 of Windows Server 2003 and allows IIS 6.0 to run 32-bit Web applications on 64-bit Windows. In other words, you have to scale IIS back to 32-bit mode to run pre-DNN4 versions on 64-bit Windows.

So as instructed, I opened a command prompt and navigated to the %SystemDrive%\Inetpub\AdminScripts directory and ran the following command to put IIS into WOW64 mode:

cscript.exe adsutil.vbs set W3SVC/AppPools/Enable32BitAppOnWin64 “true”

Next I confirmed that ASP.NET was properly registered with IIS and was set to "Allowed" in the Web Service Extension list of IIS.

There was still one piece of the puzzle missing though. There was no ASP.NET tab in the IIS management console. At that point I browsed to my DNN install to see what would happen. An error happened and the error message indicated that DNN was "calling" ASP.NET 2.0. Since this is DNN 3.2.2 I needed it to play with version 1.1, but how do you switch versions without the ASP.NET tab in IIS?

Without being overly concerned about running DNN 4.x on this box or other web applications that require ASP.NET 2.0, I "unregistered" it by navigating to the %SystemDrive%\WINDOWS\Microsoft.NET\Framework\v2.0.50727 directory and running aspnet_regiis -u from the command line. I figured this way there is only ASP.NET 1.1 left and therefore DNN has no versions to "choose" from. And indeed, the website came up error free and functioned properly.

I was still curious about the missing ASP.NET tab in IIS though. As it turns out, it is a knows issue. But you can still run ASP.NET 1.1 and 2.0 side-by-side in 32-bit mode on a 64-bit machine. You'll have to use aspnet_regiis -s <path of the application> to map web applications to specific ASP.NET versions.

To sum up, you can run ASP.NET 1.1 and 2.0 (even concurrently) on a 64-bit Windows box, but you have to put IIS in WOW64 mode to support the 32-bit DLLs of the .NET Framework 1.1. As expected, the Windows-32-on-Windows-64 compatibility layer creates additional overhead and therefore Microsoft does "not recommend this environment for .NET Framework 1.1 applications that demand high performance or scalability, such as high-load ASP.NET applications."  Of course, this only makes sense to begin with if you have to support "legacy" web applications such as DNN 3.2.2. Once you upgrade to DNN 4.x, you also move to the .NET Framework 2.0, which includes native 64-bit support for Itanium-based systems.

It took me quite a while to wrap my head around all this. So if I went off in the wrong directions somewhere please let me know in the comments.

 Permalink       3 Comments       RSS feeds       Email updates

DNN SEO Quickstart Guide 

Posted by Tom on Monday, July 09, 2007 to DotNetNuke, SEO, SEM, DNN Tips and Tricks

This post is meant as a springboard for consultants, designers, programmers and end-users who are well-versed in DNN, but who may have some catching up to do when it comes to search engine optimization and search marketing. While I make some DNN-specific recommendations, most tips given here are applicable to any website, build on DotNetNuke or not. So here are my top ten SEO tips in order of priority. Actually, forget the order, it's not worth the fight. Just try to implement as many of these suggestions as you can.

1. Take care of your meta tags, especially the page title and description. Include your most important keywords, but limit your titles to 65 characters including spaces. Choose modules with SEO in mind, such as Ventrian's News Articles, which writes the article title into the page title for you. Furthermore, write unique page descriptions for all your pages.
   
   
2. Start attracting relevant links to your website. Note the word "relevant", meaning that some links are more valuable that others. If you are running a business around DNN as we do, then one link from dotnetnuke.com is much more beneficial than all the links in footers of client sites. As attractive links are hard to come by, consider submitting your URL to industry specific directories.
   
   
3. Don't skimp on quality copy and content. That's what search engines live off. Use a free tool to do some basic keyword research and then sprinkle them around your copy. Don't forget the spell and grammar check, you are targeting (mainly) people after all. In my opinion, a professional copywriter is the most overlooked member of most web teams.
   
   
4. Create an XML sitemap of your website and submit it to all major search engines. I prefer a tool such as xml-sitemaps.com to build my sitemaps over DNNs dynamically created sitemap file. Don't confuse this with a sitemap page, listing links to all of your pages, which is beneficial as well.
   
   
5. Place a robots.txt file into the root of your site to guide search engine spiders. Take a look at the robots.txt file of the mothership for a DNN-centric example.
   
   
6. Get into the game of local search if your websites promotes a "brick and mortar" business. Many searchers include some kind of local identifier such as the town, city or zip code, which catapults you to the top of the organic search results with minimal effort.
   
   
7. Write well-formed, standard compliant HTML to improve accessibility and "crawlability." Consider excessive in-page JavaScript, HTML layout tables and frames junk food for search engines spiders. I'm well aware that strict XHTML remains a challenge with DNN, but let's make an effort to move away from quirks mode by adhering at least to XHTML transitional.
   
   
8. Seek an alternative to DNN's default solpart menu and lead spiders deeper into and around your site with well-formed internal links (don't use tracking or logging with the announcement module and pay attention to how your editor of choice "builds" links.)
   
   
9. Make DNNs friendly URls even friendlier with 3rd party URL rewrite providers such as this one or that one. These providers do have their limitations though, which is why I recommend them only for small to mid-size websites.
   
   
10. Cut down on duplicate content by implementing a 301 redirect from non-www to www or vice versa. I also recommend going as far as hard-coding your login and register links into your skin to further minimize duplicate content created by the "returnurl" querystring parameter.
    
    

So there you have it, a high-level overview of search engine optimization techniques geared towards DotNetNuke based websites. Don't be fooled though, SEO and SEM have grown into vast fields with search engines constantly refining and tweaking their ranking algorithms. Another important point I would like you to carry close to your heart is that you are designing and building websites primarily for people and not for search engines. As long as you strive to serve your visitors well, search engines will follow.

 Permalink       21 Comments       RSS feeds       Email updates