It is quite often that when working on a new version of a site that you will have a development, test, upgrade copy of the site that might be around for a while.  It is also possible that if you are working for a third-party that you might stage client sites on your server for a period of time before go-live.  At first glance this all seems common place and not something that you would be concerned about.  However, that is not the case.  Search engines have become overly aggressive in indexing sites, including those that have no direct back links but have been e-mailed to individuals or similar processes. In this post I'll discuss some important considerations when working with these "non-production" installations to help you ensure that search engines will NOT index the content and cause confusion.

The German DotNetNuke User Group is proud to present the first language pack for DotNetNuke 6.1.3 in German.

This blogpost is about disk permissions and asp.net applications like DotNetNuke. Although there are probably many posts like this I write this because permissions, or more precisely the lack of them, are the root cause of many support requests. And a little knowledge is all that would have been needed to avoid the situation.

Background: the worker process and its app pool An asp.net application is just that: an application. It is a program running on your server calculating what HTML to spew out to...

One of my favorite features in DotNetNuke 6.1 is the new Client Resource Management capabilities.  This is a feature that I wanted to see as part of the core a few years ago.  As a commercial module developer and DotNetNuke website owner, I was constantly keeping track of overall page output with each DotNetNuke release. DotNetNuke 6.0 introduced several new components that greatly improved the user interface, but unfortunately also added more to the overall page size. We knew we needed to get better control over the number of resources needed for each page and we knew it needed to be done for DotNetNuke 6.1.