DotNetNuke Blogs On DNN, For DNN

Diagnosing a DotNetNuke Server Outage caused by Schedule Service Errors

iFinity.com.au - Bruce's Blog — Wed, 23 May 2012 10:46:55 GMT

Ever since I went to a full dedicated server for my websites a little over 6 months ago, I’ve had zero problems. Zero as in none. 100% uptime for months on end. This has been great, so good in fact that I almost forgot what it was like doing battle with shared hosting services. If you’re at the point where you are questioning whether to go from shared services to a dedicated server (and by this I mean shared as in VPS or shared as in ‘all on one server’) – do it now. Even though it costs a little bit more, the savings in less downtime more than offset the difference.

But all good things come to an end, and about 12 hours ago, my site started going up and down like a yo-yo. Once all the usual suspects have been sorted out (did I forget to renew the domain?) it became clear that this was a software issue on the server itself.

If you use DotNetNuke as your platform of choice, and you’re faced with this situation, the first place to always go and look is the DotNetNuke scheduler.

This is a great piece of software that allows even people on shared hosting to run scheduled services. I posted a couple of weeks back the horror of having to work with a web platform that doesn’t have something like this built in.

But with great power comes the possibility of bad things happening. And so it can with the scheduler.

The problem with all scheduled services (and by this I mean the universe of unattended software, not restricted to any one platform) is that they can go rogue. By rogue I mean consuming all of the resources of the host machine, and generally causing crashing and destruction.

And so it goes that this would appear to be the cause in this case.

This blog post is going to be about the troubleshooting process that I went through, to solve this problem. Why post this? So that others, if they find themselves in the same situation, might find the information and manage to solve the problem themselves.

Finding out what is wrong with your non-responsive DotNetNuke website

The first thing to do is get the server to the point where you can actually access it. Sometimes this might require a reboot – if so, get that done.

If you can get a remote desktop connection to the server, or even just a remote Sql Server connection, get that going.

If you can get an FTP connection going to the server, upload an ‘app_offline.html’ file to the website root. This essentially shuts down further traffic to the site. See here for more information about app_offline.htm. The first thing to do is to stop the server crashing again.

Once you’ve got the ability to look at your DNN install, try and ascertain the size of both the ScheduleHistory and EventLog tables. If these are large, you’ve probably identified your problem.

In my case the ScheduleHistory table had grown to over 4 million rows. Yikes. Now that’s a problem. It should be in the thousands, not the millions. Note there is no exactly correct number, because the number depends on traffic and how many scheduled items you have, as well as how many errors you get.

When your ScheduleHistory or EventLog tables grow to this size, they basically can’t be deleted properly, because deleting that amount of data from the tables fills up the transaction logs in your database. The DNN Scheduler has two tasks in it, one which deletes excess rows from the SiteLog table, and one which deletes excess rows from the ScheduleHistory table. And when you try and run a backup on that size of data, the backup can take forever and also consume too much CPU and memory. Result : dead server. The Scheduled task can’t delete the rows, and it kills the server stone dead while trying to. It’s in a death spiral, and the only solution is to clean out those tables.

But before you do that, you need to know what is causing the error. If you’ve got a Sql Connection, I recommend selecting the top 50 or so rows from both the ScheduleHistory and the EventLog tables.

The commands are these:

select top 50 * from dnn_EventLog order by LogCreateDate Desc
select top 50 * from dnn_ScheduleHistory order by startDate Desc

Note: dont’ do a ‘select *’ from these tables, or you’ll just cause more grief. It’s imperative to limit the size of the result set.

When doing this, I recommend copy/pasting the ‘LogProperties’ column of the EventLog table into a text file, and renaming it something like ‘errors.xml’ in your local machine (put it in a temp directory). Then open that file by double clicking on it – this will open up the xml output in a browser window. Reading raw XML with no formatting is an exercise in generating headaches, so I recommend doing it this way to save you grief. You can copy/paste the LogProperties from multiple rows into the one Xml file, and have a way of viewing a selection of the errors.

Of course, if you can still actually log onto your server and view the Admin –> Log Viewer page, then do it that way!

The Discovered Issue - PurgeModuleCache Failure

What I found from all of this was this error appearing over and over again:

5/22/2012 8:24:12 PM

Scheduler Event Failure

THREAD ID 20 TYPE DotNetNuke.Services.ModuleCache.PurgeModuleCache EXCEPTI

THREAD ID: 20

TYPE: DotNetNuke.Services.ModuleCache.PurgeModuleCache

EXCEPTION: String was not recognized as a valid DateTime.

RESCHEDULED FOR: 5/22/2012 8:24:42 PM

SOURCE: STARTED_FROM_BEGIN_REQUEST

ACTIVE THREADS: -1

FREE THREADS: 2

READER TIMEOUTS: 0

WRITER TIMEOUTS: 0

IN PROGRESS: 0

IN QUEUE: 9

Just below it, in every case, were two other exceptions, which looked like this:

DefaultDataProvider: DotNetNuke.Data.SqlDataProvider, DotNetNuke.SqlDataProvider

ExceptionGUID: 5965365b-9f4c-40ab-b3fc-1b3268ded02e

InnerException: String was not recognized as a valid DateTime.

FileName:

FileLineNumber: 0

FileColumnNumber: 0

Method: System.DateTimeParse.Parse

StackTrace:

Message: System.FormatException: String was not recognized as a valid DateTime. at System.DateTimeParse.Parse(String s, DateTimeFormatInfo dtfi, DateTimeStyles styles) at DotNetNuke.Services.ModuleCache.FileProvider.IsFileExpired(String file) at DotNetNuke.Services.ModuleCache.FileProvider.PurgeExpiredItems(Int32 portalId) at DotNetNuke.Services.ModuleCache.PurgeModuleCache.DoWork()

So, from this it was pretty obvious that the ‘Purge Module Cache’ scheduled task was failing every time it ran. Each time it failed, it added 3 exceptions to the event log, and another two entries to the ScheduleHistory table. Eventually so many errors are logged that the PurgeHistoryLog scheduled items start failing as well, which then sets off a snowball effect, the end result of which is an unresponsive server.

Now, in my particular case I just happen to have a copy of the source code of the particular DNN version I was running (6.0.1, as it happened to be). So I went into the DotNetNuke.Services.ModuleCache.FileProvider.IsFileExpired source, and took a look at what was there:

        private bool IsFileExpired(string file)
        {
            StreamReader oRead = null;
            try
            {
                oRead = File.OpenText(file);
                DateTime expires = DateTime.Parse(oRead.ReadLine(), CultureInfo.InvariantCulture);
                if (expires < DateTime.UtcNow)
                {
                    return true;
                }
                else
                {
                    return false;
                }
            }
            finally
            {
                if (oRead != null)
                {
                    oRead.Close();
                }
            }
        }

Straight away, I could see that there was a looming bug in this code - there is no handled exception if the first line of the read file doesn't contain a valid date.

So, next thing to do was to check the source code of the latest version of DotNetNuke available (6.1.5 at time of writing).

        private bool IsFileExpired(string file)
        {
            StreamReader oRead = null;
            try
            {
                oRead = File.OpenText(file);
                DateTime expires = DateTime.Parse(oRead.ReadLine(), CultureInfo.InvariantCulture);
                if (expires < DateTime.UtcNow)
                {
                    return true;
                }
                else
                {
                    return false;
                }
            }
	    catch
  	    {
	        //if check expire time failed, then force to expire the cache.
		return true;
	    }
            finally
            {
                if (oRead != null)
                {
                    oRead.Close();
                }
            }
        }

Here we can see that the bug has been fixed - there is now a catch statement to catch an exception if the file doesn't exist, can't be read or doesn't include a valid date/time.

The Easy Fix!

Once you have worked out what the problem is, then you no longer need the records in the EventLog or ScheduleHistory tables. But you can't just delete them - deleting records puts them into the transaction log file of the database, so the deletes could be reversed if necessary to rollback the database. This is what causes half the problems in the first place. Instead you need to Truncate the tables. In Sql Server, 'Truncate' is the command used to delete the rows from the table and don't bother with adding them to the transaction log. Think of it like deleting something from your computer and not putting it in the recycle bin.

The commands for this are:
truncate table ScheduleHistory
truncate table EventLog

Now you've identified the error, cleaned out the oversized database tables, but you still haven't fixed the original problem.

At this point, it's obvious that the correct solution is to upgrade DotNetNuke to the latest version. So that's what I did. Problem solved - no more logs filled up with errors, site not crashing, everyone happy. All that was needed was to delete the app_offline file, and let visitors back onto the site.

Thanks goes to Antony Slater of WEBPC for both the server and the useful help in determining the problem.

Summary

If you face a problem like this:

1. Stop it from happening by restarting your server if possible, and upload an 'app_offline.htm' to your site
2. Ascertain it if is a schedule / event log oversize table related issue
3. Assuming (2) above is the correct diagnosis, work out what is filling the log and/or schedule history
4. Fix whatever that problem is (in this case, fixed by upgrading DNN to the latest version)
5. Truncate any oversized database tables
6. Remove the app_offline.htm file again
7. Closely monitor the server to make sure it's running OK again

More ...

Announce Team ITM America for the #LSCDavis

ChrisHammond.com — Tue, 22 May 2012 05:31:59 GMT

I am proud to announce that we have officially renamed Team Ride With Chris, to Team ITM America, for our ride at the Team LIVESTRONG Challenge Davis, this June 24th, in Davis, California. You can continue to donate to the individuals on the team via the team page.

We have been looking for a new team name for a while now, and were approached by ITM Consulting out of Germany about helping to promote their new brand being launched in the United States later this summer, ITM America (www.itm-america.com)

ITM has stepped up with a large donation to the team, and has currently put us into the top 20 teams in terms of fundraising for the LIVESTRONG Challenge Davis.

I have known the folks at ITM for a couple of years now through the DotNetNuke ecosystem. They provide a wide array of IT services, including DNN integration with SAP and mobile solutions, custom module development and workflow implementations, and providing security assessments and risk abatement.

Stay tuned for more information from ITM America on their website, www.itm-america.com, while they get things together over there you’ll find a picture of Natalie and myself at a recent bike ride we did in Santa Rosa, California.

As part of the agreement we will be sporting brand new “kits” for the ride in Davis. Check out these fly threads!

Engage is heading to Charlotte for Day of DotNetNuke!

Engage — Mon, 21 May 2012 21:26:00 GMT

Join Brian, Jason, Oliver, and myself for this year's FREE Day of DotNetNuke in beautiful Charlotte, NC. Enjoy a full day of sessions packed with tips and techniques from DotNetNuke core team members, community members, and industry experts. This year's theme is "DotNetNuke Goes Social," and many of the session tracks will focus on the features of the latest release of the DotNetNuke application, version 6.2.

10 Reasons to attend Day of DotNetNuke in Charlotte June 2nd.

DotNetNukeFool — Mon, 21 May 2012 01:13:22 GMT

What was once a community event started by the honorable and great Will Strohl in Tampa Florida a few years ago…DayofDNN has grown into an ongoing series of events where the brightest minds in the DotNetNuke community gather to discuss all things DNN. Here are 10 great reasons to attend this year’s event in Charlotte NC on June 2^nd 2012.

DotNetNuke - a New Collabrative Service Framework

TressleWorks — Wed, 16 May 2012 22:49:00 GMT

While I completely agree with the recent focus of DotNetNuke on the Cloud, Mobile and Social aspects of DotNetNuke V6 as a way to increase the adoption of the product, I believe there is an alternative focus that the more technical among us can consider. This “other” focus is centered on strategic changes to the framework of DotNetNuke – the underlying bones.

For many years, DotNetNuke was referred to as the DotNetNuke Framework that supported the creation of a Content Management System. For end-users, the term framework was lost – DotNetNuke was a Content Management System. However, that framework provided a standardized way to build web pages with a defined plug-in infrastructure, security and underlying database. Over the years the framework aspect of the product(s) has been down played.

More...

XMod Pro 4 Easily Embed Data Feeds Using AJAX

DNNDev_Blog — Fri, 11 May 2012 17:24:00 GMT

One of the un-sung heroes of the 3.0 release of XMod Pro was the Feeds feature. Sure you could use it to create CSV and Excel spreadsheet downloads for your DotNetNuke site. You could create RSS or customer XML feeds. You could even use a feed to display a printer-friendly HTML page that pops-up outside the DNN skin. Beginning in version 4, we’ve made leveraging feeds easier and more powerful than ever

Custom Login for your DotNetNuke Site in XMod Pro 4

DNNDev_Blog — Wed, 09 May 2012 17:51:00 GMT

XMod Pro 4 is packed with new features. Among them is a brand new ability to leverage the customizable, highly flexible forms of XMod Pro to create a custom login form for your DNN website.

Integrate Your Data with DNN Search in XMod Pro 4

DNNDev_Blog — Tue, 08 May 2012 16:12:00 GMT

XMod Pro makes it a pretty painless process to add, edit, delete, and view your data in a DotNetNuke website. However, until XMod Pro 4, you couldn't integrate that data with the built in site-wide search DNN offers. Now you can.

WillStrohl.com Moves to Mandeeps Live Blog

The Mighty Blog — Mon, 07 May 2012 16:32:26 GMT

Since WillStrohl.com has been up and running, its primary function or purpose has been to host my personal blog about many things, but mostly DotNetNuke. During this time, it has always run on the “core” Blog Module. Say what you want about the core blog module, but it has always been a very functional way to build and maintain a blog presence on DNN. There has always been a way to accomplish anything you wanted using it, whether it was adding other modules to the page, adjusting the design, or simply recompiling the module with any adjustments I’ve needed. I’ve traditionally had time to do this, all with the intention of helping to make the blog module a better module. Though, I recently changed blog modules, and that’s what this article is about.

Disclaimer: First, I work for DotNetNuke Corporation, if you didn’t already know. So, even though I have it posted everywhere, I should mention that this blog entry contains comments and opinions that are my own, and have no endorsement whatsoever from DNN Corp. Second, I am doing a thorough write-up of my experience with a specific blog module. While I feel that I have tried to not make this come off as an advertisement, I want you to know outright that I am not advertising for them.

The “core” blog module has had a very exciting, long, fun, and rough past. At some points it was simply misunderstood. Other times it was missing features. And yet other times, it was laying dormant, waiting someone to give it some long overdue TLC (tender loving care). Such is the nature of a purely open source project. It’s always at the mercy of those that hopefully have the necessary time needed to keep it updated. I’ve always been very patient with the module myself because I love doing things with “core” modules first before going to the ecosystem. After all, how else can the project know where and how to proceed if people are not using it and offering feedback, requests, fixes, code, and more?

Well, these days I have much less time to dedicate to helping that project than I used to. I mean, I already run or contribute to more than 15 other projects on CodePlex. This entire time I was basically working on a fork of the blog module anyway, since I had some specific requirements (or ideas) about how I best wanted my blog to do things on my site. After all, this is one of the many benefits of using an open source module to begin with. Unfortunately for the module itself, I needed to take that off of my plate, so the search for other blog modules began…

The Blog Selection Process

The DotNetNuke ecosystem has several modules that are either built to support blogging, or can be configured to support a blog. Whether it comes from the Store or the Forge, you’re given many quality options. Among them are some really great choices, and even some very flexible ones that aren’t a blog out-of-the-box, but can be after some configuration (some requiring more configuration than others).

After a bit of research, I decided to use Live Blog by Mandeeps. Mandeep Singh heads up Mandeeps, has long been in the DotNetNuke community, and their solutions have always had a positive reputation during this time. All of their modules have regular releases and very responsive support. I tested this through the Store before moving forward. This was the first step to feeling better about choosing Live Blog as my solution.

Next, with very few exceptions, all of his extensions that have been reviewed continue to have 5 star reviews. Whether I looked there, on twitter, or in the DNN forums, Mandeeps overall has had great feedback from those that use their modules.

The final piece that really sealed the deal was that it seemed that no matter which blog solution I was coming from, Live Blog had the hardest part of the migration path already solved for me. It would simply import all of my blog posts and comments for me, maintaining the original integrity of by blog with nearly no effort at all. I tested this several times in a staging environment, and it always worked great! This alone is highly impressive.

The three components mentioned above were the critical first steps in my selection process. Mandeeps Live Blog had very responsive support, great reputation & reviews, and it allowed me to easily migrate my content to it.

My Feature Requirements

Not every blog is created equal. Although many blogs are created or used for the same general purpose, they all have their own agendas and goals. My main goal is SEO. I want to make sure that by blog entries can be found by people, regardless to whether those people were coming from Google, Bing, or {Gasp!} Yahoo. Yes. Yahoo is still around. ;)

Since my main goal was SEO, I needed a solution that practiced some very specific key things in order to not hurt whatever goodness my SEO had already attained. I needed H1’s and H2’s in the right places, great looking page titles and URLs, categories with friendly URLs, site maps, and so on. Live Blog has all of these features and more.

Comments are important to any blog. I have wanted to transition to use Disqus for my blog comments for a long time because their comment engine is unmatched in capabilities and stickiness. Unfortunately, I’ve either been too busy or too lazy to write the code to export my comments using their WP standard. There were two great things about Live Blog in this area… First, it already has them implemented as a forward only feature. However, a very recent release also allows you to export your existing comments to Disqus, allowing you to choose to use their comment engine at any time! Suh-weet!

I also track my own feed status through Feedburner. I have really grown to like this service and didn’t want to move away from it for my RSS links. Live Blog doesn’t get in the way here at all.

The final requirement I had was to be able to make the new blog fit into my own design. Luckily, my design isn’t terribly complicated. Regardless though, the template feature in Live Blog makes generating your own template to suit your needs incredibly easy.

Any Bells or Whistles?

If you’re not familiar with the term “bells and whistles,” it is simply a slang way of talking about really cool add-ons or features. Live Blog has plenty of them.

Beyond what I’ve already mentioned, you get some really cool things like deep Windows Live Writer integration. You can choose your own URL structure for each new blog post. It has an easy to use control panel-style settings view. It will automatically “ping” some common ping services for you such as blog search and feedburner. You can simply paste in social bookmark code from sites like AddThis or ShareThis. It will also allow you to automatically post new blog entries to twitter, but I have to admit that I haven’t tried using this feature yet.

I am sure that you will find some other things to be your own bells and whistles, but these few things are what stood out to me.

Is It Missing Anything?

Unfortunately, like with many 3rd party extensions, Live Blog has the need to fill the use case requirements of a large range of customers, including customers on many different versions of DotNetNuke. As a result, this prevents Live Blog from implementing newer DNN features and APIs, such as editing pop-ups, client dependency framework, integration with the taxonomy API, cloud folder providers, mobile-friendly displays, and more. This is not a deal-breaker (yet), but it will likely be frustrating for me moving forward since I always like to be on the latest version of DotNetNuke.

Did I Have Any Problems?

First, I would like you to know that I tested this module thoroughly in a staging environment before deploying this on my own website. And even then, I made sure to retest everything since I was on my production website. I highly recommend that you do this as well. You never know what might creep up as a problem if you don’t. I was able to do this side-by-side on my production site with the core blog module still actively in use. However, in order to test on my own site and to mitigate any need to re-sync the data, I made sure to cease any blog posts during the testing phase, and I turned off comments during this time frame as well. This made the migration path one that only needed to be followed once. I wouldn’t categorize this as a problem, but you definitely need to be aware of this as well. Otherwise, you will need to manually import and new blog posts or comments when you do the same thing.

There was one specific problem. Unfortunately, the URL structure in Live Blog did not match that of my original URLs. This is not an uncommon issue when switching module vendors or creating a new section on your website. In this case, the original URLs used EntryId to denote the blog id number used to generate the blog post page dynamically in DNN. Live Blog does this same thing, but uses PostId instead. Unfortunately, there is no way to change this in Live Blog. Along the same lines, the imported blog content did not respect the original ID numbers. So a blog post that was previously 123 could be another value like 119 after import. Finally, the URLs that are generated by Live Blog follow a different set of rules when created. Basically, this could result in a scenario where your new URLs are essentially very different from their original URLs.

Initially, I looked to IFinity’s URL Master to fix this since I use this on my site, but without a bit of development by Mandeeps, a solution wasn’t available here. However, if you do have a vendor ready and willing to do so, Ifinity has a module provider solution that allows you as a module vendor to map and generate URLs on sites that use URL Master.

At the end of the day, I couldn’t use a built-in or existing feature to re-map URLs to ensure that when search engines visited or visitors clicked on existing inbound links, the visitor would not only get the content they were looking for, but they would also get the SEO-friendly HTTP 301 redirect. So, in order to fulfill this requirement, I ended up writing a slick little module called Simple Redirect. It’s sole purpose in life was what you just read – and, to keep things simple in doing so.

What About the Future?

One of the things I am going to miss deeply is the ability to immediately support the latest and greatest features in DotNetNuke for the reasons mentioned above. However, the convenience of being able to not need to maintain a separate code base right now is too great to ignore. Mandeeps has been incredibly responsive to feature requests so far though.

Summary

So that’s it. I wanted to have a supported blogging solution that didn’t require me to have a forked and self-maintained version of the code base to achieve my blogging platform requirements. I also wanted to see active releases that incorporated more and more features without the need for me to merge my codebase. In looking for possible blog solution providers that could give my site what it needed and more, I found and moved forward with Live Blog. It was able to meet all of my needs, has great support, actively releases, and is extremely reactive to feedback. At this point, I couldn’t be any happier with my chosen path.

Are You jQuery Ready For This?

DNNDev_Blog — Mon, 07 May 2012 15:48:00 GMT

XMod Pro 4 leverages jQuery in myriad ways. Some are flashy, but this small feature is so useful, I wonder why we didn't add it earlier

Development and Test DotNetNuke Installations and Search Engines

Mitchel Sellers DotNetNuke Blog — Mon, 07 May 2012 06:35:00 GMT

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.

DotNetNuke Login and Auto Complete - How to Cope

Mitchel Sellers DotNetNuke Blog — Fri, 04 May 2012 18:31:00 GMT

Recently I have been getting a lot of questions regarding the DotNetNuke login and why when you go to login that "auto complete" is disabled on the username/password fields. The typical follow-up question to that is "how can I change that behavior". So after answering this question individually around 5-6 times I though it would be best to get this out here, at least my opinion on the issue.

Proudly Supporting the Charlotte Day of DotNetNuke

DNNDev_Blog — Fri, 04 May 2012 13:48:00 GMT

On June 2nd, DotNetNuke Corp. will be releasing DNN 6.2. I doubt the numerology is lost on anyone. This year, they've chosen to announce this new release at the Day of DotNetNuke (DoDNN) being hosted by the Charlotte DotNetNuke User Group (QCDUG).

It's not surprising the QCDUG is hosting the event this year. They're group is really gaining traction in the area and brings a lot of positive energy to the DotNetNuke community.

If you've never been to a DoDNN and you're anywhere near Charlotte, NC, you should definitely go... free sessions, free networking, and free food! It's a fabulous deal. Of course, the only way these events can be free is if they find sponsors.

I'm happy to announce the DNNDev.com is proud to support the QCDUG and DotNetNuke by sponsoring the Day of DotNetNuke. So, check it out and eat some of the food we helped pay for :)

More ...

XMod Pro 4 Adding and Removing Users from DNN Roles

DNNDev_Blog — Thu, 03 May 2012 13:01:00 GMT

Since there have been so many additions in the latest major release of this best-selling form application builder for DotNetNuke, we thought it would be best to cover them in serial fashion. In this series of blog posts we’re covering the major new features in XMod Pro 4. In this installment let’s look at the new form Actions: AddToRoles and RemoveFromRoles which allow you to and and remove users from DotNetNuke security roles.

XMod Pro 4 Let There Be Color and Designers, Syntax Highlighting and Code Completion

DNNDev_Blog — Wed, 02 May 2012 15:07:00 GMT

XModPro 4 - Our Biggest Update Ever

DNNDev_Blog — Tue, 01 May 2012 18:54:00 GMT

It's taken us a little longer than normal to release version 4.0, but we think you'll agree it was well worth the wait. We added nearly 3 times the features to version 4 than we did to version 3.0. Read on for the scoop on the latest and greatest release of XMod Pro yet.

Licensing Made Easier

DNNDev_Blog — Tue, 01 May 2012 18:49:00 GMT

With the release of XMod Pro version 4.0, we've modified our licensing to make it simpler and more straightforward.

Forge, Codeplex and Friendly Urls

iFinity.com.au - Bruce's Blog — Mon, 30 Apr 2012 02:39:46 GMT

Somehow I got a rumor mill going. As most things with unexpected consequences, this caught me a bit by surprise.

Let’s get the back story : last year, while at the DotNetNuke Conference in Orlando, Scott Wilhite and I had a little chat about the DotNetNuke Forge. As the chief of the DotNetNuke community, it’s his job to make sure the community has the best tools at it’s disposal. One of those is the DotNetNuke Forge. And it’s where any open source extension for DotNetNuke should live.

I’ve written a lot of bits and pieces for DotNetNuke in the last half-decade or so since I started doing this – some are trash-can fodder, some are ‘for my eyes only’, some are good enough to give to the community, and some are commercial products that keep my family fed and housed.

Most of the stuff in the third category was sitting on my website as downloadable zip files. It really wasn’t the right place for it. Scott asked me when I was going to start putting stuff on the DotNetNuke Forge. It was a good question, and I don’t remember what my answer was, but I mentally lodged myself a background task of ‘put stuff on Forge’. This gives back to the community and also simplifies management of these projects for me – everybody wins.

So, whenever there is a spare bit of time and I feel like doing something a bit different, I take one of my free downloadable apps, package it up properly, and create a DotNetNuke Forge project.

I’ve already done this for two other projects:

Coming up to last week, I decided it was time to do this for the iFinity Friendly Url Provider. This piece of code was what got me noticed in the DotNetNuke chattering classes (ie, the Forums) and what directly led to the launch of the Url Master product (which was a fork of this code – now drastically different, though). It still is used very widely by many different people. Though basic, it has got enough improvements over the standard DotNetNuke Url Rewriter that it is still quite popular. And from time to time people find bugs in the source code and send me fixes, which I try and incorporate in and release a new version. It’s always been open source and free to download.

So last week I finally ticked this one off my list. I took a couple of the contributions from people, merged them in, and then created a new DotNetNuke Forge project here.

I think that’s when some misunderstandings got going. I think some people got the idea that I had decided to open source the Url Master module, then head off to the hills and herd goats.

Well, as they say in the classics, reports of my demise are greatly exaggerated. I’m still working madly on the Url Master module code to add features and fix bugs. I’m coming up with some exciting new modules. I’m still feeding and housing the family.

I’ve just moved the original iFinity Friendly Url Provider code from my server to the codeplex server, so more DotNetNuke community members can find it, and where other community members can get involved in reporting issues and fixing bugs. It was always open source – half of the code was derived from DNN, which is under BSD, so it’s under a BSD licence. It’s just a got new home, that’s all.

There’s more to come, as well. I’ll keep looking through the code basement to find some interesting things to polish up and put on display.

More ...

You are going to use a CMS for that startup, aren't you?

iFinity.com.au - Bruce's Blog — Tue, 17 Apr 2012 10:55:42 GMT

My blogging has been a bit patchy in this first quarter of 2012, as has my open-source output. The reason for this is that I have been involved and working on a new startup project that should hopefully launch soon and prove to be a big success.

The investors behind the project hadn’t done a web startup before, so they obtained the advice of the first person they found. I don’t really know the history behind this choice, and it scarcely matters now anyway. By the time I arrived, technology choices were in granite and the runway end was fast approaching.

Upon arrival I was disappointed to find out that this was what I call a ‘scratch build’. The first person on the project literally went into Visual Studio and said ‘New Project…’.

The first question I asked was ‘did the original person who chose this technology consider using a CMS of any type?’. The answer was ‘Yes, but it was ruled out’.

Again, there is little value in turning over old rocks when there is a project to finish and the answers make no difference to the outcome of that project. So I have left it at that.

But I wanted to do a little analysis of this in case the topic ever comes up again with anyone else.

The true cost of scratch building

When you get to see the invoices for time that get paid to developers for building the different components of a fully functional subscription-based website, you get a good insight into how much ‘scratch building’ costs.

What I have done is go through and develop estimates of how much time has been spent developing different subsystems. Note that none of these subsystems are the actual bulk of the work. They are just the peripheral bits and pieces that go into the bulk of sites of this type.

As my personal CMS of choice is DotNetNuke, I’ll consider some of these features alongside their DotNetNuke equivalent:

Built Feature	DotNetNuke	Difference / Notes
Membership System*(login,register,forgotten email, etc) Approx Time Taken: 60 hours of development time, email templates, custom mail sending code, skinning	Built-in. Skinnable. Templated Emails. Approx Time needed: 8 hours of installing and editing emails	Additionally, DotNetNuke has option of custom login modules. 52 hours longer Probably still more bugs to find. May yet require Facebook login integration or similar.
Scheduling System Service to run scheduled tasks in the application. Approx Time Taken: 15 hours of development for a Windows scheduled service, configuration to make scheduled payments, send emails, etc	Built-in. Includes reporting and control. Approx time needed: 0 hours	The DotNetNuke scheduler doesn’t require any extra software to be installed on the webserver. 15 hours longer
Event Log Implementation of text-based server log using open-source component. Approx Time Taken: 10 hours of implementation	Built-in. Easily extended for custom applications through creating new event types. Nothing to build, all exceptions captured and logged, custom logging done in one line.	The DotNetNuke event log includes the ability to view remotely through the admin pages of the site, and can be filtered for different types of events. 10 hours longer
Design Implementation of MasterPages design. Conversion of designer-specified Html into .aspx pages. Approx Time Taken (excluding designer) 40 hours.	Install skin through menu and apply to pages as needed. Completely separate from code. Approx time needed 8 hours (to refine and apply to different pages)	DotNetNuke skins can be developed by a designer in Html and then converted by the platform itself into a DNN Specific skin. 32 hours longer.
Menu System Design and implementation of a 4-level menu system and breadcrumbs for all pages. Static and requires config changes to add/remove pages. Approx Time Taken 40 hours	Built-in. New choices in providers such as Mega-menu. Approx time needed 1 hour	There are many different menu styles to choose from. Menu designers can quickly and easily setup the styles. From then on, you just choose which pages go into the menu, and where they go. Easily adjusted by the owner of the site. 39 hours longer
Content Display Creation of a way to allow authorised end users to edit site content. Requires separate WYSIWYG Html editor and FTP program. Approx Time Taken (excluding authoring content) 35 hours	Built-in, including different content for different authentication levels. Approx time needed: 0 hours	DotNetNuke Professional versions include a content staging solution for approving content for live sites. 35 hours longer

*note: the system is using the same asp.net Authentication provider that DotNetNuke uses. This saves a significant amount of time, but there is still a lot of work in plugging all the ASP.NET components into an overall site, and refining the plainly-awful default ASP.NET designs.

There is more I could list. Search engine sitemaps. Analytics integration. Caching for performance. Administrator control panels. User administration – if you want it, it all has to be built while the CMS packages it all up for you, tested, debugged and ready to use.

To save you adding up, the calculated extra time taken is 183 hours. Even to me, this sounds very conservative, as I’m just extracting the information in a rough manner from management reports.

But let’s turn that into dollars and time, the two singularly most crucial data points for any startup. Let’s assume you can average a developer hour at $100/hr – that is an extra $18,300, and close enough to 5 weeks of extra time.

Some people in large organisations might laugh at that- $18k is probably their stationery bill – but in a scrappy small startup watching the pennies it is an enormous amount. More crucially, every week the product isn’t launched is every week revenue doesn’t come in, and gets closer to the time when the runway end appears and the investors get nervous.

Where does the platform really end?

When building a project like this, it’s amazing how cheaply a site like this can be put together. A similar startup ten years ago would have needed a 7 figure bankroll to get the same amount of functionality in the same amount of time. Open source libraries, Microsoft helper code – it all helps to put something together quickly. We’ve leveraged jQuery and jQuery UI, used Knockout.js to give great UI interactions, leveraged email and payment provider libraries to speed up things immeasurably.

The point here is that when you’re already using open-source libraries to speed up development and improve quality, then it’s bizarre to draw the line at the actual project itself. Everything on the web runs on a huge stack of layers, so, in my view, it isn’t productive to dip down and build one more layer when a suitable candidate is there. Nobody actually contemplates writing their own version of jQuery now, so why the actual Web Application?

But - It’s more than the cost

At this point, someone who was sceptical of implementing a CMS as a base for a startup might reasonably come back with ‘yes, but how much time would adapting the design to the CMS have cost’. This is a fair point and one that needs expanding. If you start with CMS-inexperienced developers, you may find that this time difference is soaked up in the developers trying to get their head around building an application on top of a CMS, instead of just creating a new codefile every time they need a new feature.

It doesn’t need to be like that, though. The pool of developers skilled in a platform like DotNetNuke is pretty vast, and pretty deep. And even if you’re a bit green, there are endless online forums, Q&A and other resources to tap into. Code is code, no matter where it is written, so adapting to a different way of display is very low cost.

My hypothetical sceptic might come back and say ‘but yes, now you’re tied into the project’. This is true. Your future and that of your donor CMS are now one and the same. But that is why you would choose and open source solution like DotNetNuke. Even if the entire project disappeared off the face of the Earth tomorrow, you’d still have all of the source code, all of the things required to build it, and you could continue to move forwards. But I’ll throw it back the other way, without a major platform, you don’t get any new features for free. You don’t get lots of people finding security problems and patching them for you. You don’t get a vibrant developer community trying to push things forwards continually.

A scratch-built solution has a talent-pool of a handful of developers deep. When one of them walks out the door and onto other pastures, a ton of knowledge leaves with them. This type of hidden reef is impossible to calculate in terms of cost, but it can be quite significant.

It’s also about the future

Already, the project is thinking about the future past launch day. If all goes well, there will be plenty of site members and plenty of activity. It’s about then that new ideas for site features will start popping up. What about a company blog? How about some social features to let users of the system compare notes, talk to each other, build a community? With a scratch-built site, it’s back to square one. With the authentication system built in, trying to tie in a stand-alone forum system would come across as clunky and poor. Creating single-sign-on between different codebases is difficult. Harmonising design is troublesome.

And that’s when a CMS like DotNetNuke really pulls out into clean air. In the next couple of months, the platform will release the long-awaited Social Features and a new Services layer. There is no way an individual team can possibly compete with a team of fulltime developers working on a single feature like this alone. The startup site could really use some of those social features like the new Journal module. But there is no way it is ever going to happen, save maybe for a buyout by Facebook like some others.

A Virtual Comparison

Perhaps the best way I can put it is this: if two teams funded by two different investors worked on this same project, and one decided to use DotNetNuke as the base, and the other decided upon a scratch build, the one based on DotNetNuke would be to market by now, with more features and less bugs. And they’d have extra cash saved over for promotion. They’d even have a ready-built community to show their new site off to for feedback and perhaps the first customers!

It’s pretty obvious to me which one would be the eventual winner. The ‘Not Invented Here’ syndrome is a costly one to acquire.

So I’ll ask the question again, in case you’re just starting out and chewing over this question : You are going to use a CMS for that startup, aren’t you!

More ...

Plan Now for Day of DotNetNuke Charlotte 2012

The Mighty Blog — Wed, 11 Apr 2012 22:34:04 GMT

Man… What a year. Really. A lot of things have happened, and it’s already 3/4 of the way over. The best part is that we have a brand spanking new release of DotNetNuke that features social features for all editions of DNN in the 6.2 release. That release is right around the corner, and DNN Corp folks have been busy blogging about 6.2 features quite regularly. But wait, there’s more! That’s right… This is my elevator pitch, or boardwalk pitch. You choose. Just don’t call me Billy Mays or Vince Shlomi. Go ahead, look them up. One was great but passed away, and the other. Well, let’s just not go there.

DNN 6.2 is Around the Corner

There are a ton of new capabilities coming in version 6.2 of DNN that include two huge areas: social, and service framework. The social topic is big enough at this point that we all understand it even if it’s only from a high level, but the service framework is the beginning of a much broader area that developers will simply love!

This release marks the long anticipated integration of the beloved Active Social suite of social capabilities. You see, a little over a year ago, DNN Corp acquired Active Modules, and their most popular app offering was a suite of features that made up a product called “Active Social.” If you desired, Active Social nearly gives you a Facebook experience within minutes on your own website. However, the features are much more powerful than that. They allow you to build, maintain, and grow communities on your website that center around your brand, cause, or products. This is the most powerful way to market to and engage with your customer base.

The service framework is just the beginning of something bigger, but if you’re the techie type and look under the hood to see what it’s about, you can’t help but geek out over it! The service framework lays the foundation of what will be centering DotNetNuke as your primary point of managing online content, and allowing content to broadcast from, or import to your website. Integrate this feature into your website, and the possibilities are endless, regardless to the device or platform we’re talking about.

Got a PHP web property? So what.
Have a cutting edge handheld device. Check.
Need to integrate with a Java app? Easy.
Want to have two way communication with the next social website? Done.

This and more is what will be possible in the future using the service framework.

All of this is great and all… But how in the world do you learn about how to use any of these new features? What can you do to ensure that you will be productive with these features from day 1? This is where the Day of DotNetNuke Charlotte comes in!

Attend the Day of DotNetNuke

The Day of DotNetNuke has always been and always will be a free event to attend. All you need to do is find a way to get there. Once you do, you will be able to enjoy DotNetNuke swag, sponsored giveaways, numerous DNN sessions, and more. You will also get to meet and chat with some of the very same engineers that built these features. There’s nothing more geeky in the DNN world right now than that! Oh, and don’t forget the always fun DNN After Dark party. If you haven’t found out yet, attend and you will soon find out that the DNN community knows how to have a great time!

Be a Speaker

There are already a variety of speakers for the event, but anyone could potentially be chosen as a speaker. Just create a compelling session abstract about DNN 6.2, or social on DNN, and submit it. This is easily one of the most rewarding ways to give back to the community, and make a name for yourself at the same time.

Be a Sponsor

Sponsors are what make this event great. I’ve said it time and time again. Without the generosity of sponsors, the event wouldn’t be free, and there wouldn’t be all of the great events and freebies that we’ve enjoyed in previous events. If you are interested in sponsoring, just fill out the sponsor form on the website. The DNN community never forgets about the great companies that help support it. This is easily one of the best ways to build and maintain your brand in the DNN ecosystem.

This is all well and good, but what can you expect? Check out this video montage from the Chicago event!

Public Speaking Videos Including DotNetNuke Demonstrations

The Mighty Blog — Mon, 09 Apr 2012 21:24:08 GMT

It’s always been a topic, but even more so recently… People are asking more and more about various things that relate to public speaking. Whether it’s for user group meetings, code camps, DotNetNuke World, meetings with colleagues, or strategic business meetings with partners and prospective customers – public speaking is a critical tool to have honed and in your professional toolbox for your career. Honestly, many of us believe that we are good at speaking in front of an audience, or at least good enough. This first part of the year, I took it upon myself to build some presentation-style videos to explore and teach some of the most important components for public speakers.

I joined DotNetNuke Corporation in June of 2010. I was already speaking at many events before accepting the position. I had countless public events as well as business-centric presentations under my belt. While I knew I wasn’t an expert at public speaking, I knew that I could hold my own and get things done. The position I took was to not only do some of the very things I was already doing, but it also entailed representing a brand and company that I was pretty much obsessing over. The last thing in the world I wanted to do was misrepresent the brand in any way through my presentations.

As a result, I quickly did some research to find out who the “experts” on public speaking were. I found a small handful of people that specialize in the topic and not only authored books, but also had businesses based on the subject. Some of my favorite include Garr Reynolds and Nancy Duarte. I literally spent many hours reading their books, attending live webinars, reading their blogs, and more learning what they had through real world experience. I had already blogged on their books in the past, and I invite you to read them as well.

What I put together over the past couple of months is the beginning of a larger amount of resources that are intended to help everyone, and especially the DotNetNuke community, become better at public speaking as well. Introducing, the public speaking series of videos on the DNN YouTube channel… The channel is also embedded below.

As of today, there are nearly 2 hours of videos that introduce ideas, experience, tips, best practices, and more that all help you to ensure that you always have the best presentation possible, regardless of your audience. The videos start from the very beginning, and continue through to DotNetNuke demonstrations.

There are of course plans to add more resources just like this. Hopefully, you enjoy this as well.

Day of DotNetNuke Charlotte Website is Live

Day of DotNetNuke — Mon, 09 Apr 2012 16:52:19 GMT

Unless your head has been buried in the sand like an Ostrich might do, there is going to be a Day of DotNetNuke this year, and it is being held in the beautiful City of Charlotte. Charlotte is also known as the Queen City, among other things – hence the name of the local user group, Queen City DotNetNuke User Group, or QCDUG. These guys have been hard at work organizing, and their work is clearly being seen – most recently with their brand spanking new website!

The Day of DotNetNuke Charlotte website has nearly all of the information you need to get your plans in order today… Hotels, venue information, and more.

Mark your calendars now… The Charlotte event is happening on June 2, 2012. Get there early to make sure you can enjoy yourself.

Register Now! It’s not too early to let the crew know you’re coming… You can already register to attend and join their mailing list to keep in the loop and help them plan for your arrival.
There’s plenty of reasons to attend. Just ask anyone that has ever attended a Day of DotNetNuke. They will let you know in no uncertain terms that you should never pass up this opportunity. From meeting community members face-to-face, meeting the vendors that are making your site great, to learning how to use and build on DNN, there’s no downside… It’s all FREE!
And let’s not forget the infamous DNN After Dark party. One thing is clear when you join the DNN community after hours… We know how to have a good time – no exceptions! :)
Speakers
If you’re a speaker or want to be, simply submit your session abstract(s) on the site. Just remember the theme of the event – it’s all about social. Your must be about of use DotNetNuke 6.2 or just social in general. DNN 6.2 has already moved into Beta, so you have plenty of time to learn about and use 6.2 before the event.
Get your write on and submit at least 2 sessions today… The more you submit, the better chance you have of being chosen to speak. And speakers are always treated special… Hint, hint!!!
Sponsors
It’s still not too late to become a sponsor for the Charlotte event. Sponsors are what make Day of DotNetNuke so fantastic for everyone, so make sure you don’t get left behind. The first sponsors always get the better perks. And the faster you sponsor, to sooner you can begin enjoying the extra advertising and community love. Your sponsorship is noticed by the community. And the community never forgets…
More ...

Meet DotNetNuke Community Member Adam Humphrey

The Mighty Blog — Mon, 09 Apr 2012 10:46:30 GMT

If you have not heard of Adam Humphrey, I wouldn’t be surprised. While he is an excellent DotNetNuke community member, much of his participation is under the radar. However, he is in my opinion one of the better designers that our community and ecosystem have. He is most importantly, the owner of Adammer.com, which is the flagship company that he does most of his work out of.

Chances are, you’ve used one of Adam’s skins for DotNetNuke. Chances are even better that you’ve even used a DNN site that has one of his skins or a derivative of it applied to the site. The skin design I am talking about is much better known as Greytness. As far as free designs for DNN go, this seemingly one of the most popular and widely used free designs for DotNetNuke. There are many reasons that I could guess as to why… It’s more complete than most free skins, has built-in WAI compliance, fully commented CSS, and more. Anyhow, I will let you put your own eyes on it.

Adam has also been a speaker at the Bay Area DotNetNuke User Group, or BayDUG (@BayDUG). A presentation he gave recently was called “Pushing Pixels in the DotNetNuke Ecosystem: Principles of DotNetNuke Skin Design.” Having been in the DNN community for as long as I have, I have seen countless presentations about skin design, many of which were given by people I would call friends and experts. However, this is by far one of the most useful presentations about skin design that I’ve ever seen.

Pushing Pixels

Adam Humphrey did an excellent job presenting his ideas and experiences with the fellow members of BayDUG. We enjoyed a similar presentation that he did last year so much, that we invited him back to do it again since DNN 6.x has changed a few things. He did not disappoint. I know most of you have no opportunity to join us at BayDUG, so we recorded this amazing presentation!

Interview with Adam Humphrey

Since I know that most of you are not familiar with Adam, I also asked him to do a quick interview so that he could be properly introduced to the DNN community overall. The resulting interview was great, and you can view both parts below.

DNN User Groups

There are many reasons to join, attend, and speak at DotNetNuke user groups. Hopefully, some of this information has inspired you to join or lead a user group yourself. But user groups are always looking for people to show up too. Participate in any way that you feel comfortable with – but PARTICIPATE!

DotNetNuke Module Development 101: 2 - What is a Module?

Charles Nurse — Wed, 04 Apr 2012 03:47:00 GMT

In the first post in this series I pointed out that DotNetNuke places few requirements on module developers, and this is often daunting to new developers – “where do I start?” being a common refrain.

So where do you start?

Before we actually start to build our first module lets look at what constitutes a module. In the default DotNetNuke skin/template that is used when installing DotNetNuke there are a number of examples of Text/HTML modules.

As an example Figure 1 shows 3 such modules on the Home Page.

Figure 1: Examples of HTML modules on the Home Page of the Default Template

Some of the content on the page is provided by the module and some of the content is provided by the framework. In figure 1, while all three modules are HTML modules they all have slightly different “headers”.

Module 1’s heading is in a larger font than Module 2 and Module 3 doesn’t have a heading at all. This module “chrome” is provided by the container which has been applied to the module. The module header text is provided by the framework (Figure 2 – red box), the styling of the chrome is provided by the container, and the text/images in the “body” of the module are provided by the module itself (Figure 2 – blue box).

Figure 2: The components of a Module

This means that as a module developer, I don’t need to worry about the external chrome – or the module header – this is done for me, I can focus on the content inside the blue box.

IModuleControl

DotNetNuke is built on top of Microsoft’s ASP.NET Web Framework, using the Web Forms model. This model is based on Web Forms (.aspx files) and Web User Controls (.ascx files), as well as Web Controls (which are compiled as part of a class library).

Every page in DotNetNuke is a Web Form – in fact every page is the same Web Form – Default.aspx.

Sections of the page are made up of dynamically injected Controls – most of which are Web User Controls, and in most cases a module is implemented as a Web User Control (.ascx). So in order to create a module we need to first create a User Control.

But not just any User Control.

DotNetNuke needs to know certain things about a module – and conversely the module might need certain things from the DotNetNuke core, so there is an additional requirement that the User Control needs to implement a DotNetNuke interface – IModuleControl

Figure 3: The IModuleControl interface which defines a Module Control

public interface IModuleControl { Control Control { get; } string ControlPath { get; } string ControlName { get; } string LocalResourceFile { get; set; } ModuleInstanceContext ModuleContext { get; } }

To make life easier for module developers, the core provides a few base classes which already implement this interface and which can be used as a base by module developers.

PortalModuleBase – this was the original base class for all modules – In DotNetNuke 5.0 the requirement was modified to implement IModuleControl, and this class was refactored to accomplish this. It exposes a lot of extra properties and methods (in addition to the 5 properties that constitute IModuleControl) – most of which can also be accessed through the ModuleContext property.

ModuleUserControlBase – this new (in DotNetNuke 5.0) base class is a simple implementation of IModuleControl, based on the UserControl base class. In addition to the 5 members of IModuleControl it adds a simple method LocalizeString which is a helper method for localization.

ModuleControlBase – this base class (introduced in DotNetNuke 5.0) is based on the WebControl base class (rather than UserControl). To use this base class the module control would be compiled as part of a class library.

Basically all we have to do then is to create a “control” which inherits from any of these 3 base classes. This is the only requirement for building a DotNetNuke Module. There is much more that DotNetNuke offers to module developers, but the minimum requirement is to create a “control” which implements the IModuleControl interface.

For most of the rest of this series we will be using the ModuleUserControlBase class as our starting point, and in part 3 of this series we will actually create our first DotNetNuke module.

DotNetNuke Module Development 101: 1 - I did it My Way

Charles Nurse — Fri, 30 Mar 2012 18:58:06 GMT

DotNetNuke has a rich eco-system of Modules, both Open Source and Commercial. In many ways this is our biggest strength as a CMS platform. No matter what you want to do with your site – there is often a module that already does it.

In my opinion this is due to the flexibility provided by the core DotNetNuke Framework. Many other platforms are very prescriptive – as an extension developer you have to follow a fixed shopping list of rules – there is invariably only one way to create an extension, which may not work for what you want to do.

But DotNetNuke places very few requirements on what must be done to build an extension. This frees developers to be creative – to think outside the box – which I feel explains the rich ecosystem of modules that already exists and continue to be developed.

I have been working as a developer on DotNetNuke for nearly 8 years now. During that time I have built many modules for personal use as well as a number of modules that are now part of the core distributions. In addition, I have designed and created many of the hooks in the core which Module Developers can take advantage of.

Recently, I have heard comments that “Module Development with DotNetNuke is difficult”.

I don’t agree with this sentiment – but, I think that our strength (flexibility) that I described above is also our weakness. There are a multitude of ways to build DotNetNuke modules - and we don’t provide a prescriptive method of development. While this provides flexibility, it can be somewhat daunting for new DotNetNuke developers – where do I start? is a common refrain.

My goal in this series of posts is to provide some guidance – from my perspective – for both the beginner module developer and for more advanced developers, who may not be aware of all the hooks/features that DotNetNuke provides.

This is not “The Definitive Way of Module Development” – its not even “A Definitive Way of Module Development”, but (with apologies to Frank Sinatra) it is “My Way”.