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.

The Need for a Rewrite

The old blog module dates back to the days of DNN 2. That is: to 2004 or thereabouts. The DNN framework now bears almost no resemblance to that version. So many things have changed since then. (Static) localization, caching, url rewriting, etc, etc. In fact, besides security, the installer and data providers, you wouldn’t find many parallels between that version and the current version. In all those years the blog module has tried to catch up to changes in the framework. And from the looks of the codebase, without a rewrite. I.e. code was added, bit by bit, to accommodate new features and framework changes.

The codebase of the old module was messy, to understate affairs. I became involved in the project back in 2009. I was working on a site for a customer of mine, where I wanted to use the ease of publishing of Windows Live Writer that came with the Blog module. What was lacking was categorization which would allow me to better organize content throughout the site. So I set about adding this to the module and as a result propelled release v 4.0. As I first delved into the code I was struck by how archaic some things were done and I began refactoring the bits around where I was coding. But it was hard to refrain from refactoring elsewhere, too. The only thing that held me back was the fact that it became quickly apparent that the whole module needed reworking to bring it in line with current coding practices.

Since the 4.0 release the module led a mostly dormant existence until Chris Pattera from DNN Corp stepped in in 2012. His mission was to integrate some of the social API into the module that had become part of DNN 6. As the module is also used by DNN Corp on their main website, there was a real benefit in implementing this API in the blog module. In those days I’d often be in touch with Chris as he battled his way through the codebase. And one thing we both agreed on: the messy codebase had to be addressed. But neither of us dared go so far as to say “OK, I’ll rewrite the module”. Both of us have busy lives and a rewrite of such a module is easily underestimated. Late august he released version 5.0 with the social API integration.

But with version 5 also came some dependencies on the new services layer API of DNN 6.2. And unfortunately for the rest of us, DNN changed course with this services layer for DNN 7. Changing it from MVC to WebAPI. This meant that all old services would essentially be broken. As a result the blog module version 5 will not work on DNN 7. Ouch. And Chris, by now, had bigger fish to fry. The old blog module team had long since evaporated, so I did feel some pressure on myself to step in and repair this. But the old codebase now contained new code that was added by Chris in a manner that was also clearly more geared towards getting the job done, rather than being overly pretty and clear. So the whole issue of what to do with the old codebase became more and more pressing.

More and more calls were made as I tried to get more opinions on the matter and if just maybe I could get some funding for a rewrite ... I spoke with the powers that be at DNN Corp a couple of times at conferences to see if they would be willing to sponsor some of this. My argument: the Blog module is too important to fail. If we ever want to be taken seriously (i.e. get some download numbers of the platform) we need a serious open source blog module to go with the community edition as it was called at the time. Later in 2012 I found out that their “Nebula” project (which evolved into DNN Social, or Evoq|Social as it’s now known) might include a new blog module written from the ground up. And that kind of brought it home to me. If they were devoting resources to a commercial blog module, they’d never sponsor a free version. So I more or less gave up on the idea of sponsoring. It was clear that what had been said over and over again was true: if the community wanted a better blog module, the community should make one.

I called Joe Brinkman (a fervent user of the module and one of the most respected DNN programmers). We weighed the pros and cons of a rewrite. In the end it was he that convinced me that a rewrite was the only way. In fact something that maybe I’d known all along but just was afraid to admit. There is no other way. Refactoring that much code is just more work and the risk of old contaminations higher, than starting from scratch again. And don’t forget there is one huge advantage: it means I can really design from what I want to achieve. Not from what is already there.

The New Blog Module

Beginning with a new slate I had these bullet points in my head:

• Fully templateable – see if it’s possible to get rid of the multi module definition
• Cater for multilingual scenarios
• See blogs as “folders”, i.e. containers of posts with specific permissions – get rid of child blogs

This would not conflict too much with the old data model (so migrating data should be possible). The one big change with regard to the data model would be to deprecate the link of blogs to portals in favor of blogs to modules as DNN prefers data to be contained per module.

Templating

The new Blog module uses a templating mechanism based on token replace that should allow you to completely redesign the HTML that is emitted. As this includes the ability to deliver javascript and CSS files along with it, the possibilities should be virtually endless. The new templating mechanism addresses two important sought after features that token replace does not have: conditional rendering and repetition. Over the past years I've refined this mechanism and used it in various modules. My hope is that you’ll embrace its power and begin to craft new templates that make the blog module look exactly like you want. The default template borrows from various examples left and right to give the module a modern look. I’m aware it will not fit everyone’s bill, but that is impossible in any case.

Multilingual Features

In my research for this I spoke with various experts in not only DNN localization, but also bloggers in multilingual situations (specifically academics that would write in either their mother tongue or in English). The new module is what I call a “hybrid localizable” module. That is: it can be used in different ways in a multilingual site. On the one hand it can be used “classically” as a monolingual module where you’d have different module instances each for a different portal language. Alternatively you can use it as a fully multilingual module where each blog post has its own translation and you display the same module for each language, its contents adapting to the selected language. I hope this will not only address the needs of all international settings, but it will set this module (with DNN) apart from the competition and give it its own niche in blogging products out there. As far as I know there is nothing comparable out there.

Blogs as Containers

The old module forced blogging through one’s own blog in the module. If you wanted to write under a different “heading” you could create a child blog. In version 4 I tried to coerce users to categories, but I know this didn’t cover all scenarios. Frankly, we needed to look at the blogging scenarios again. For instance, on the DNN site we had mostly personal blogs. Everything was published as though you had your own blog there. Fair enough. Cathal Connelly, our security expert, had leveraged the child blog feature by creating a child blog for security. Oddly, it would sit as a subheading to his own personal blog. And it wasn’t shared with, for instance, Brandon Haynes, the other security guru on the list. It was clear that some were trying to fit a square peg in a round hole. But I didn’t want to sacrifice the “multiple blogs per module” either as this would really break many existing scenarios.

Instead blogs are now really just that, blogs. They are themes under which you add posts. Each blog has settings specific to that blog including a whole bunch of security settings. Who can add/edit posts, etc. This opens up the possibility to many more blogging scenarios. There’s a new module permission “Create Blog” meaning “those that can create blogs” in the module. Posting to the blog is set at blog level, not module level.

Other Features

Here is a bullet list of other features of the module:

• Windows Live Writer integration
• BlogML import and export
• Add image for each post and each blog
• Threaded commenting
• Leverages friendly url provider
• Simplified UI through several key buttons
• Implementation of new WebAPI services means many functions can be reached with JS

Where Do I start?

The module is available on Codeplex

https://dnnblog.codeplex.com/releases/view/111284

If you’re upgrading an existing blog module, then please follow the guidelines and backup your installation. Test and only when finally satisfied continue. Otherwise try to find out what went wrong and roll back. A help file is also integrated into the module and available as PDF on Codeplex. You’ll find it under the documentation icon at the top of the module when logged in as module editor or blogger.

The Road Ahead

So is this it? The definitive blog module? Hardly. I think it is a great start on a completely new path for this module. What should happen now is that several people start making awesome templates. Currently there is no way to upload these yet through the module’s UI. That will come. For now you’ll need to create a new folder under DesktopModules/Blog/Templates and begin editing there. Ultimately I’m thinking along the lines of a “template exchange”: a centralized place where you can upload templates to and download them from. An exchange that is accessible from within the module. That would allow us to create a database of templates.