Find a post...

In my earlier post I delved into how I got into DNN late 2002/early 2003. In this post I continue where I left off at the end of 2005.

It’s been over 10 years that I’ve been “on DNN” and 7 years that I’m on the so-called Core Team of the platform. I’ve been awarded MVP (Most Valuable Person) by DNN Corp. Time to look back at our history together. Warning: I set out to write a paragraph or two about becoming DNN MVP, but it has grown into somewhat of a complete retrospective of the last decade. It was roughly 10 years ago I discovered DotNetNuke. In this first part I look at how I discovered DNN and my introduction into the community.

Unless you’ve been hiding under a rock somewhere the past few years chances are you will have heard of Git and Github. And how they are taking over the (developer) world. And if you’ve been in tune with recent developments around DNN, you will have heard that DNN, too, has a repository on Github and is currently managed using Git. So what’s the big deal?

The roots of DNN are in Webforms. In the early days of asp.net this was Microsoft’s evolution of the Active Server Pages technology. Since then the world has moved on quite a bit. Various alternatives to Webforms have been introduced on the Winstack and by and large PHP has grown more explosively than any .net based technology. In part, because the php-based cms solutions have been kinder to web designers. How else to explain the vast amount of skins (themes) available to them and the general disdain of any web design firm for .net? OK. Maybe this is not entirely accurate, but the feeling I get is that we could make progress by making DNN more design-centric. And in my opinion that translates to: ensuring a designer has a better grip of where the HTML and CSS is coming from and where to change this.

To our second installment on this two part series on handlers and modules in ASP.NET web applications, their significance and how to begin debugging situations where things have gone haywire. Like I mentioned in the previous post on handlers: modules and handlers go together like peas and carrots. The main difference is the following: whereas a handler runs only when ASP.NET has decided it should handle the incoming request and ASP.NET stops after it has found the handler, the module always runs on every request and ASP.NET continues. So the way that looks is that upon a web request ASP.NET first passes the request to each and every module in the list of modules and then tries to find a handler for it and passes the request on. Most crucially a module can alter a request as it passes through it or set the stage for other components before they run. For the remainder of this post I assume you will have seen/read through the previous post and you are familiar with Fiddler, web requests a ...

This post is the first of a two part series about handlers and modules and is an attempt to offload what I know about handlers to you. Knowing what handlers are and how they work is what separates the savvy from the not-so-savvy when it comes to IIS administration. Although very few modules in the DotNetNuke ecosystem use/rely on handlers, those that do experience a steady stream of support calls along the lines of “hey, XYZ doesn’t work” and it is down to a handler issue. Examples of modules that use handlers are Ultra Video Gallery and Document Exchange. DotNetNuke uses handlers itself as well. So what is a handler? In a nutshell a handler is piece of code that handles a web request. To understand why it’s good to know more about this you need to look closer at http traffic (i.e. the bits and bytes that go back and forth between your browser and the server).

This article is about the use of templates in DotNetNuke modules, specifically the new Blog module. The aim is to provide some background to those interested as to why I chose the templating mechanism that I did. And how it works.

I can think of two reasons why you’d be a DNN Platform addict. Either you think it’s an awesome tool to make some money or you think you can make some money using this. I’m kidding. There is a second group. Those that itch to work on something bigger than they would otherwise be able to work on, together with some of the sharpest programming minds on the planet. Obviously I’m not excluding you’re here for both reasons. But the focus of this post is on the second group. Those that have been bitten by the Open Source bug.

I’m happy to announce a new release of the one and only “official” DNN Blog module. And it’s not just some new tweaks here, some bugfixes there. It’s a complete rewrite of this module. I know. That sounds crazy. And it is. But there were some good reasons to do this. In this blog post I’ll elaborate on those reasons and some of the highlights of the new module.

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.