Crafty Code

Forge, Codeplex and Friendly Urls

http://www.ifinity.com.au/Contact_Us — 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?

http://www.ifinity.com.au/Contact_Us — 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 ...

What’s new in DotNetNuke 6.2–Presentation to SEQDUG

http://www.ifinity.com.au/Contact_Us — Fri, 30 Mar 2012 10:23:21 GMT

Just last week I did a presentation to the South East Queensland DotNetNuke User Group, on the topic of ‘What’s new in DotNetNuke 6.2’.

The slides from this presentation are shown below:

What’s new in DotNetNuke 6.2

View more presentations from brchapman.

About the User Group Meeting

This was a very fun event – generously sponsored by Power DNN Australia and held in South Brisbane. Unfortunately we were in the grip of one of the worst rain events in recent history – while I was presenting, over 370mm of rain fell on my house – that’s 14 inches of rain - in the space of a few hours, which caused widespread flooding. It wasn’t as bad in Brisbane where I was giving the presentation, but the weather was foul enough to keep a few people away.

The next SEQDUG meeting is already in planning – make sure you join the Linked In Group to be a part of the DotNetNuke scene in my part of the world!

About the Presentation

The two main areas that my presentation covered were the changes in DotNetNuke 6.2 that people are most interested in – these being the Social Networking features and the Services Layer that powers them (and will be available to all developers to utilise).

Earlier this week, Scott Schlesier posted a timely blog entry entitled DotNetNuke Services Framework - a little context. This expands further on the brief introduction to the services layer that is in the linked presentation above. I highly suggest any DotNetNuke developer reads it to get more information on what will be one of the biggest revolutions in DotNetNuke history.

I’ll be having a lot more to say about 6.2 in the coming months, so stay tuned for updates!

More ...

Different robots files for different DotNetNuke Portals

http://www.ifinity.com.au/Contact_Us — Wed, 21 Mar 2012 02:27:33 GMT

One of the greatest strengths of the DotNetNuke framework is the ability to create many different websites with the one installation. This means you only set up one IIS website, and then serve up as many individual sites from that as you like. Personally I’ve seen DNN installs with thousands of sites, which is a bit of an eye opener if you’re used to running 2 or 3.

However, this power has a few small drawbacks, and one of the ones I’ve been mulling over for years has been the ability to serve up separate robots.txt files for separate sites in a DotNetNuke installation.

The robots.txt file is a pretty old protocol, and dates back as far as I can remember. The basic idea behind the robots.txt file is that it tells ‘robots’ – such as search engine crawling bots – which parts of the site they can index, and which they should ignore. While it’s a bit of a relic in that it’s a voluntary standard (those writing malicious bots for stealing content don’t exactly pay attention), all of the major search engines still read the robots.txt files, and some people still swear by their use.

What’s more, with the introduction of search engine sitemaps a few years back the use of the robots.txt file has jumped into the frame again, principally because you can list any of your search engine sitemaps within the robots.txt file. By listing a search engine sitemap, search engines pick up the reference and will read and follow the urls laid out in the sitemap. For more information on this, see the sitemaps.org site here : Informing search engine crawlers of search engine sitemaps.

In that linked reference, you’ll find that you should list the sitemap in the robots.txt file, like this:

Sitemap: http://www.example.com/sitemap.xml

(note: the sitemap entry is independent of the user-agent, so you can’t tell some user-agents to read it, and others not to)

So far, so good. For DotNetNuke we drop a robots.txt file into the site root, and enter the default sitemap location, like this:

Sitemap: http://www.example.com/sitemap.aspx

But wait! Those who have been nodding along will realise we have much more than just one domain in our site if we are running multiple sites (DNN Term: Portals) in our DotNetNuke installation.

That’s where it starts to go wrong. We can’t have a site (portal) specific sitemap, because there is only one site root.

Of course, it is technically allowed to do cross submits through the sitemaps protocol (see http://www.sitemaps.org/protocol.html#sitemaps_cross_submits) because you implicitly own all of the various domains. But it’s messy and rather shatters the illusion that a DotNetNuke portal is a separate site, rather than just a data partition in an overall DotNetNuke installation. In my experience, website owners don’t like seeing references to other sites within their own. But this still doesn’t solve the problem of wanting to ‘lock off’ parts of a site through the robots.txt file, because that’s a site-specific action which doesn’t fit with a one-size-fits-all robots.txt file.

And that’s the problem I’ve been mulling over ever since the sitemaps protocol was updated to include the robots.txt reference. My original thinking was to incorporate it into the Google Sitemap Provider code that I’ve had for years. But while it was possible to do so, it required people to modify their IIS configuration to associate the .txt file extension with ASP.NET. From my experience with helping people redirect .html, .asp and .php Urls to DotNetNuke sites with the Url Master module, I knew this would result in a lot of people asking for a lot of help in navigating the waters of modifying their IIS configuration. When you add in multiple IIS versions, multiple .NET versions, 32 bit and 64 bit, it becomes quite complicated.

So that’s the official reason why it was always on the ‘TODO:’ shelf for me (this is quite a crowded shelf, I might add).

Recently, Tom Kraak of R2i was asking me again why I hadn’t done this, and I gave him the standard response (which is a version of the paragraph above) and he wasn’t buying it anymore. So I decided to re-think it, and then I realised that IIS7 had delivered all the tools needed with the IIS 7 Url Rewrite tool. This is a rewriting/redirecting tool that now comes bundled with IIS as standard, and is available as an install for any IIS7 version that doesn’t have it. You can get it at the IIS 7 Url Rewrite page.

How to serve individual robots.txt files for individual DotNetNuke portals using IIS7 Rewrite

The basic idea I had was that the IIS7 Rewrite tool could be used to rewrite any example.com/robots.txt Url into a domain-specific robots.txt file.

So, instead of placing a single robots.txt file into the root of your multi-portal DotNetNuke installation, instead, what you do is create a specific robots.txt file for each portal.

As an example, say we have a DotNetNuke installation with 3 portal on it, which are example1.com, example2.com and example3.com

In this case, we would create 3 robots.txt files:

example1.com.robots.txt
example2.com.robots.txt
example3.com.robots.txt

Each of these files is a robots.txt file specific for the specific domain. This means you can list any paths you don’t want indexed, as well as a specific sitemap location for the relevant domain.

So far, so good. But a search engine looks for domainname/robots.txt, not domainname/domainname.robots.txt. How can we serve up the correct robots.txt file to the search engine robots that come visiting?

The answer is in an IIS7 Rewrite Rule. Here’s the steps how to do it:

1. Ensure that you have IIS7 Url Rewrite installed on your server. You may have to confirm this with whomever administers your hosting server

2. Open up the web.config file, and in the section, add the following rule:

Note: if you already have existing rewrite rules in the section, just add the block between the opening and closing from above.

That's it. What this rule does is match an incoming request for the robots.txt file. It then rewrites that request so that it appends the domain name to the front of the robots.txt path, and changes it so that it looks for the domainname.robots.txt file, instead of the robots.txt file. Because you create separate domainname.robots.txt files in your site root, then each separate file gets served for each separate request. Problem solved!

Now, I’ve given this a test on my local development environment and it was working a-OK. If you find a shortcoming in the approach, or it’s not working, please let me know via the comments.

More ...

Updating your Vendor Google Analytics for the new DotNetNuke Store

http://www.ifinity.com.au/Contact_Us — Mon, 20 Feb 2012 12:00:03 GMT

The new DotNetNuke store arrived last week – and what a momentous day for vendors like myself who use the platform extensively. The old Snowcovered store had remained quite stagnant for a long time, and while it had many strengths, there were a lot of weaknesses that needed to be fixed. This has been done, and everything is good!

Well, almost everything. One feature that vendors use extensively is the ability to track visitors to both their product page and their vendor page. While a vendor like myself has no idea overall what sort of traffic the site gets, we have the ability to create a Google Analytics account and see traffic to ‘our’ specific pages in the site.

One of the big changes with Snowcovered to DotNetNuke store was, of course, the domain name. And anyone who knows anything about Google Analytics should know that it works on a combination of your tracking ID and the domain name.

So it should be no surprised that many people will see analytics graphs that look something like this:

Oh dear- all my customers disappeared about the 13th of February!

To fix this, it’s quite simple, you just need to change the tracked domain name so that it looks at the new store Url.

To do so, just follow this guide:

1) Click on the little ‘cog’ icon on the top right of the page

2) You will get to the profile page. Click on the ‘Profile Settings’ tab:

Where you see ‘www.snowcovered.com’, change it to ‘store.dotnetnuke.com’.

Click the ‘Apply’ button at the bottom of the page.

That’s fixed that. But the profile is still named ‘snowcovered’. We’re all going to be using the term ‘DotNetNuke Store’ from here on in, so better get that fixed.

3) Click on the ‘Property Settings’ tab:

Where it says ‘snowcovered.com’ change it to ‘store.dotnetnuke.com’. Of course, you can put anything in the ‘Property Name’ field – you don’t need to stick to the domain name.

Click on ‘Apply’, then refresh the page, and you’ve fixed it all up!

The changes will take up to 24 hours before traffic starts appearing again.

Bonus : Better Tracking

In the old Snowcovered store, the plethora of Urls each page could be found under meant that tracking a canonical page was a bit of a dark art when it came to Google Analytics. However, this could easily be done by viewing pages by title – no matter what the Url, the title was always the same.

Alas, when the new Google Analytics came out, the old ‘content by title’ report disappeared (or was buried further than I was inclined to look). This was most frustrating.

However, salvation is at hand – the new and improved store uses the Url Master module with a custom Url Provider to deliver the store Urls. No more messy, duplicate Urls, now each product listing has a canonical Url that all traffic will use.

You can see the difference in this pageview excerpt. The duplicate Urls are highlighted in yellow, and the canonical, friendly Urls are shown in Green. The old Urls were driven by the Product ID, while the new Urls are driven by the product name. This makes it easier to track what they are for, are nicer to look at, and rank better in search engines to boot. Chalk up another great use of custom module providers and Url Master.

By next months reporting period, the old snowcovered Urls will gradually dissappear into history. But, because we can re-use our same Analytics account, we can still look at multi-year trends in pageviews, referrals, and all the other deeply interesting data you can slice and dice with Google Analytics.

So if you’re a store vendor, and you haven’t yet fixed your Analytics, get clicking!

More ...

Happy 10th Birthday .NET Framework–the little platform that could

http://www.ifinity.com.au/Contact_Us — Sun, 12 Feb 2012 22:35:00 GMT

The 13th February, 2012, marks 10 years since the .NET Framework 1.0 was released, well, according to Wikipedia, anyway. I don’t recall the specific date, but I remember the general period vividly.

This little point of achievement will probably pass most people by as they spend another day creating new software based on this platform, or use one of millions of websites that the platform provides, or any number ways of interacting what has become an incredibly successful framework by any standard to measure. But I thought it might be fun to just pause for a minute and reflect back on the last decade.

Is ten years such a long time? Realistically, in computer industry years, it’s an absolute eternity. The internet has really only been around for most people since the late ‘90s. The Windows 95 platform only lasted for 5 or so years before being dropped. Visual Basic (the original version) went from 1.0 to 6.0 in 7 years, before being shelved to make way for .NET. Many programming languages have come and gone in less time than a decade.

The way we were

It’s all too easy to take for granted the powerful tools we software developers have at our disposal. It’s very easy to forget the kind of world Microsoft-technology developers had 10 years ago. But let’s just cast our minds back to the late 1990’s and early 2000’s. If you wanted to build a website using Microsoft kit, you’d probably have been using:

- Either C++ or VB6 to build back end components.

- SQL Server 6.5, or, if you were lucky, SQL Server 2000.

- Windows NT 4.0 server, or, if you were lucky, Windows 2000 Server

- Microsoft IIS 4.0 or IIS 5.0 running ASP pages.

In reality, in any fair comparison with alternative web development tools at the time, it wasn’t ideal. In fact, many frustrating times, frankly, it was painful to get things done. You’d spend half you day producing something, peppered with thoughts like ‘there has to be a better way’.

The Genesis of .NET

I was working on a large development project for a financial services company at the time. It was a sophisticated setup, where VB6 components plugged into a business layer which was all based on DCOM, written in C++ and somehow connected it all up and made sure it scaled. I say somehow, because it really was an obscure black box of dark arts, and there was only one guy on the floor who really knew what was going on. He was brilliant in the way an older developer with a bushy beard can be. But he wasn’t good at explaining what was going on in that layer. You just had to take it on faith that it all worked, which it did, most of the time.

The problem was in deploying to production. In those days, IIS had a tendency to eat up a pile of memory and then freeze up. The notion of automatically dropping an application pool on a periodic basis hadn’t happened yet. And all those COM/DCOM components had to be installed on the server. I don’t mean sent via FTP to the \bin directory, I mean, create an installer package, log onto the server, and run the installer. And hope over all hopes that someone didn’t include a bad reference and send the entire team to “DLL Hell”, as it was known.

And that’s just the deployment part. I was employed as a VB6 programmer, which I knew well, having come up through the VB ranks from 16bit Visual Basic 3. While you’d never find me defending VB in an online forum, it wasn’t a bad way to quickly build software. But the not-quite-OO patterns in VB6 really made a developer do some unsavoury things. And if you had a friend who was programming on the hot-new-language ‘Java’ they’d always guffaw, and talk about the language purity of Java. Yes, never sit around with a bunch of developers discussing programming languages.

As the company I was working at was quite a large one with a substantial IT budget and a pure Microsoft technology platform, it got very good treatment from the Redmond HQ. And one of those things was an early look at what was called ‘Next Generation Windows Services’.

This sounded like the answer to the frustrated VB/IIS developers requests. This was going to be an entirely new programming platform, one that you could get enthusiastic about. Gone would be COM/DCOM – although you could still use it if you wanted to (I didn’t ever want to, again). Gone would be the VB6 platform, gone would be the VB IDE. In would be an entirely new programming language called C# as well as a total rewrite of VB to make it a proper language. This was going to be a proper object oriented language in either the less-verbose C style, or in the more verbose VB style. Funnily enough, on first inspection C# looked exactly like Java. Hardly a coincidence, one would suspect. All new was a event-driven web page programming style, which smelled a lot like VB forms. There was to be ‘xcopy deployment’ so you could just copy the program up to the server. DLL Hell was to be banished forever by keeping the component metadata in the component itself, rather than in the operating system registry.

Funny thing – in true Microsoft style – they had a melange of names for it. When I first heard of it, the new version of ASP was going to be called ASP+. And that’s why it has the .aspx extension – you couldn’t have a + in a Url, so they rotated it 45 degrees, and you had an ‘x’ on the end of the old .asp extension. And C# itself, was basically C++,+ – with another ‘+’ thrown in for good measure. Arrange 4 + in a square and you get #. And thus C# was named.

I don’t remember when I officially heard the name .NET – it was probably closer to the launch – by that time I no longer worked at that company, and so lost access to the stream of new announcements from Microsoft. It’s hard to believe today, but back then Microsoft didn’t do a lot of public BETA testing. But at some point it was announced, then released. And the .NET world was born.

.NET Leads the Microsoft Developers out of the Wilderness

It’s hard to understate the difference this change made in my life and career. At the time, a lot of developers (and companies) I knew were jumping ship, and moving across to Java. This generally meant a change in web server, programming tools and probably database platform for good measure. And none of those were provided by Microsoft. I’m sure the board reports at Redmond had some metric for measuring this. One of the biggest secrets of success for Microsoft has always been the support of developers. Having an operating system without third-party developer buy-in means failure. The original success of Visual Basic was the ease in which people could build ‘GUI’ apps quickly, in an era when DOS based programs and mainframe terminals were still the norm in companies. Users would have fits of delight when they could use drop-down boxes and update buttons instead of command line driven programs.

But the sea change from Windows GUI to Web was fast, and the tide was running away from Microsoft. The challenge was on – how to take all those experienced and Microsoft-trained VB developers and turn them into web developers?

The answer was ASP.NET Webforms. Now, to some web purists, the way in which this was solved still makes them go cross-eyed with indignation, but the simple matter was that it not only worked, but it did so in which it didn’t take a massive retraining for an efficient VB developer (or even a C++ developer, for that matter) to start being productive.

Of course, some of the bloated buggy and run-at-a-crawl sites that resulted are probably not excusable, as too many desktop developers didn’t really take the time to learn that programming for the web really did require a new mindset. But, for Microsoft, it worked. Within a short time, websites with the now-familiar .aspx extension were popping up all over the web. The flow of companies and developers to Java was stemmed. People like myself stayed on board. It wasn’t necessarily that someone like myself couldn’t see the faults in Microsoft – clearly I could – but it’s crazy to pretend that no platform or environment is free of shortcomings. As always, it’s about getting something that works, to market, in the quickest possible time. By 2005/6, it was very common to find jobs looking for ‘3 years C# experience’ – which meant you had to be on board from the get-go. Having conducted interviews around this time myself, I found that many people were being quite liberal with the truth on their experience, but .NET was here to stay, and anyone looking for a future in Microsoft platforms had to start collecting experience, fast.

.NET grows and grows

Despite the busting of the ‘internet bubble’, in reality, web developers were about to enter a golden age. The truth of it was that the cost of building websites and launching them was falling quickly. Part of that was cheaper hardware, and part of that was the growing stack of frameworks that added layer upon layer, each abstracting away a previously difficult and troublesome task, and making it a simple job. Open source was, and remains, a huge part of this. Of course, the leading web server, Apache, has always been an open source product. But little by little, Open Source made it’s way into Microsoft as well. But even without Open Source, there were plenty of free things that were getting added to the .NET family.

Of course here is the appropriate point to mention DotNetNuke. This is not to belittle other open source .NET projects, but it’s the one I work on and know most about. Given that ‘.NET’ is part of the name, it should be obvious to all how intertwined these two things are. DotNetNuke was (and remains) an open source framework which allowed you to quickly create websites, without having to build all the associated messy bits like authentication, logging, not to mention the killer app of DotNetNuke which was the ability to easily install third-party modules to infinitely expand the site with new functionality.

It sounds so simple and expected now, but this was such a massive jump in productivity it is hard to believe the old way of working. In the heady days of the ‘internet bubble’, if you did find someone building an ASP based site, they would have had a team of developers working for 6 months to produce an approximation of what you could get from a DNN install in 6 minutes. And it probably would crash too frequently, especially at dreaded upgrade time when it was time to release new code and find out if a trip to DLL Hell had been unwittingly scheduled.

I worked on one project that was building a social network site. This was just before Facebook exploded out of it’s college niche and out to the greater public. This was a sophisticated site that had blogs, forums, chat, video and photo uploads, and all the social features you’d expect including friends, groups and all the rest. I’ve never know the exact figure, but my guess is that a 7 figure sum was spent in an 18 month period with developers to create this site, myself being one of them. And without a shadow of doubt, I could build that same site today in DotNetNuke with a few third-party modules for more like $7000 and 18 days, and most of the money would probably go to a talented designer.

It’s easy to nod your head and say ‘yeah, that’s true’, but in few industries does this type of productivity leap occur. Of course, this is nothing special with regards to a Microsoft platform – indeed many open source advocates would argue that anything built on a Microsoft platform is not truly open source. But for a person who is tasked with producing a website that matters little. But what shouldn’t be skipped over is that DotNetNuke wouldn’t exist without the .NET platform. And I don’t mean that obviously because of the inclusion of the name, but more that the old VB6/IIS 5/ASP era was just not a good enough design to produce a modular masterpiece like DotNetNuke. It just wouldn’t have been possible.

.NET Did it Right

The reason that great solutions like DotNetNuke can be built is because of the inherent correctness of the .NET platform. It’s a true object-oriented platform. The way the programming languages were designed dumped out all the nasty workarounds and hangabouts caused by trying to maintain backwards compatibility. This was a true masterstroke of Microsoft, and one which they copped a lot of criticism for. To build a good .NET application, you had to build it from scratch, you couldn’t upgrade your old code (well, you could, but the results were usually awful). But by forcing people to start from scratch, everyone could start with a clean sheet of paper. And, as anyone who has accidentally deleted a first draft will know, the second draft is not only better, it’s written faster as well.

From the in-built memory management to the well-executed ability of .NET code to ‘reflect’ upon itself, .NET was a really good platform to build with. It’s like the difference between a toolbox full of half-broken, unsuitable tools, and a toolbox full of shiny tools designed exactly for purpose. Having the ability to select the right tool for each little job, no matter how trivial, means that the finished product always comes out better, with fewer rough edges, and always with a more elegant feel.

And we can tell .NET has been a success. Not because Microsoft tells us so, but because they’ve never changed the name (well, not since it was released, project names and working titles notwithstanding). The easiest way to detect a floundering Microsoft product is to look for frequent name changes. We all can rattle off several products that go through a series of names before quietly being shelved (the various old versions of Microsoft phone operating systems being a prime example). But .NET is still there, still being used, not being tinkered with. Visual Studio is still Visual Studio, C# is still C#, with most people being blissfully unaware of how the name came about. The true measure of developer stickiness, however, is a quick peruse of a jobs site. And there are still plenty of jobs to be had working in .NET. Sure, there are newer, ‘hotter’ platforms out there, I’m not a one-eyed Microsoft supporter in the least. But can I still deliver a cost effective solution to someone who has chosen to use Microsoft based operating systems? I sure can. Are there still plenty of people choosing Microsoft Operating systems? There sure is. IIS is still the second-highest Web serving platform on the internet, and the best way to deliver websites through IIS is by building an ASP.NET website.

The next 10 years

10 years ago a lot of people I knew were either moving, or seriously considering moving from Microsoft products into Java as a platform. I haven’t heard someone say that in years. In fact a couple of the Java people I know are starting to dabble in other platforms and languages, and they tell me that they feel Java has lost its way. I couldn’t say myself – I’ve been deep into the .NET stack for a decade and haven’t spent much time exploring outside of that. There has never been a shortage of opportunities for me, there has never been a point where I’ve felt that the platform was going nowhere. In fact, every time I look up, I find lots of new and interesting stuff coming down the road.

There’s an entirely new Windows version coming along which is destined to bust out of the traditional desktop and onto other devices, there’s lots of new ways of building traditional ASP.NET websites, there’s Azure cloud services to build, as well as plenty of traditional desktop applications. The next 10 years is going to see the explosion of web-enabled mobile platforms, either through on-device apps or mobile-optimised website apps. There’s still a long ways to go in terms of building websites on platforms like DotNetNuke. Yes, it’s fair to say I still feel the same level of optimism about the future as I did 10 years ago. I guess I’ll see you in a decade!

What do you think? Did .NET get it right 10 years ago? Will it still be around in 10 years time? What’s your experiences in the last 10 years – please feel free to share in the comments.

More ...

New Skin Objects for including jQuery, Javascript and CSS Stylesheets in DotNetNuke Skins

http://www.ifinity.com.au/Contact_Us — Thu, 05 Jan 2012 02:33:23 GMT

This blog post brings together two threads of thought that I have been thinking about. The first is related to my recent blog post Implementing jQuery and Javascript Libraries across DotNetNuke versions, and the second was a conversation with Scott Willhite at DotNetNuke World, who asked me why I hadn’t actually ever published anything in the DotNetNuke Forge despite writing lots of stuff. I didn’t really have a satisfactory answer that didn’t involve using an excuse of inertia or procrastination.

My prior post on jQuery and Javascript implementation has been pretty widely read, and one of the comments on twitter was thus:

So as two things lead to one, I decided to create a set of skin objects that would incorporate the work on jQuery and Javascript libraries into re-usable skin objects and create that as a DotNetNuke forge project.

I already had an older freebie project called iFinity SkinObjects but most of the innovations in that have now been adopted in the DotNetNuke core (nofollow on privacy/terms links, correct home page Url on the Logo, etc). The SkinObjects project was also written in VB which was now out-of-step with the DotNetNuke core.

So what I did was create an entirely new project, which I called DotNetNuke.SkinObjectsEx, or ‘Extra Skin Objects’ if you want the friendly name.

This has been created as a DotNetNuke Forge project, which has it’s associated Codeplex Project page. You can download the install package, example skin and Source code from these locations.

What’s in the box?

The SkinObjectsEx project contains 4 separate skin objects to use within your DotNetNuke skins. It comes in an installable DotNetNuke Extension Zip package which is installed as normal.

Script

The script object allows you to link a javascript file into your skin in a way that is safe for all DotNetNuke versions, and in a way that will leverage the increasing client-site functionality that has been gradually appearing since DotNetNuke 5.0 came out.

The Script object is also a simple way to ensure that both jQuery and jQuery UI are registered on the page in a DotNetNuke-safe way. I have seen many, many errors created on sites due to hard-coded jQuery or jQuery UI references into a skin, which then cause problems when new modules or DotNetNuke upgrades are introduced. This saves the skin author having to devolve into code-behind code, when they can just include a simple reference and be certain the correct version of jQuery is going to be registered on the site.

Stylesheet

The Stylesheet object is modelled on the standard DNN Styles object, but again brings in the compatibility with the DotNetNuke Client Resource Management framework in order to combine stylesheets for faster performance – in a way that works with all DotNetNuke versions. In addition, the Stylesheet skin object introduces the ability to link CSS files only for specific DNN versions. This is done in a from/to pattern, so that you can have one CSS File included up until, say, version 5.6, and another CSS File included from, say, 6.0. This power allows a skin author to tailor different approaches to different DNN versions, which is very important with the introduction of jQuery UI in DNN 6, which brought a lot of standard CSS definitions with it.

PageLink

The PageLink skin object provides a simple way to create a link to a specific page in your DotNetNuke site. While this sounds very simple, in reality skins are often developed away from the intended site, and hard-coding a Url into the skin creates a brittle implementation that is easy to break, and is usually done in a way that doesn’t leverage the proper DotNetNuke Friendly Url API accessed through the NavigateUrl() call.

Portal Date

This is an old one from the original Skin Objects project, and provides a simple way to add the current date or time to every page in the site. The most important part of this is that it loads up the localised portal date/time, rather than the date/time of the server which it is running on. For people who have their site hosted in a different timezone to their intended hosting locality, it’s a neat little way to make things look right.

In addition to the above objects, the CodePlex downloads include a variation of the DotNetNuke 6 ‘DarkKnight’ skin, which includes implementation of all of the above skin objects in an example.

This blog post will focus on the Script and Stylesheet skin objects from this point on.

Using the Script Object

Adding the Skin Object to a DNN Skin is done like this:

First, you register the skin object in the skin:

<%@ Register TagPrefix="dnn" TagName="SCRIPT" Src="~/DesktopModules/SkinObjectsEx/Script.ascx" %>

Then, for each Script library you want referenced on the generated page, you add a new Skin object:

The above example shows 4 different Scripts to be included on the output page. The first is a request for the jQuery library. The second is a request for the jQuery UI library. The last two are references to the ‘jquery.cycle.min.js’ and ‘jquery.hoverintent.min.js’ libraries which are referenced in the ‘DarkKnight’ skin.

The final two references replace this in the standard DNN 6 DarkKnight skin:

There are 6 different properties in the Script object, all of which combine to control the behaviour of the way the final script is linked on the output page.

The properties are:

ScriptType

ScriptType controls the type of script the skin object uses. There are three choices: ‘jQuery’, ‘jQueryUI’,’other’. The first two should be obvious – they just include a reference to the jQuery and jQueryUI libraries accordingly. The ‘other’ is anything else, apart from jQuery. You don’t need to include this value for ‘other’ types, as ‘other’ is the default.

Looking back at the prior example, you can see how the ScriptType is used in the 4 different examples.

Path

Path is also a value with set values. These are ‘Skin’, ‘Absolute’ and ‘Relative’. When using a path type of ‘Skin’, the library is referenced from the installed skin path. When using a path type of ‘Absolute’, the library is reference from the absolute location specified. When using ‘Relative’, the location is specified with a tilde (~) and is passed into the ‘ResolveUrl’ function to create a fully qualified path. In the above examples, you can see how the ‘hoverintent.js’ skin object replaces the included ‘code behind’ in the skin files.

Location

Location is the component that combines with the ‘Path’ value to create the fully reference Url. For Path=”Skin” location is just the relative path in the Skin directory (ie, where the skin is installed). For Path=”Absolute”, Location is the fully qualified Url to the file. For ‘Relative’, location is the relative Url that ASP.NET will resolve at runtime.

Name

Name is just a unique identifier that ensures that the script is not added twice in the one page.

Order

Order is used for DNN 6.1+ installations, and determines where in the list of resources the item is inserted. These values come from the earlier work done in the jQuery and Javascript Libraries in DotNetNuke post already referenced.

The values for Order are:

a_BeforejQuery, b_BeforeDnnXml, c_BeforeDomPositioning, d_BeforeDnnControls, e_Default

The alphabetic prefix just helps with understanding the overall order of things. This allows you to control where in the hierarchy of scripts your linked script will appear.

InHeader

This is a boolean value which controls whether or not to include the header within the section of the Html, or whether to include it in the section. In some cases, this will be overridden by the logic contained within the code, to prevent quirks for individual DNN Versions from breaking your javascript. These are always moving from to , and only apply to the jQuery and jQuery UI usage.

StyleSheet

The StyleSheet skin object uses a similar approach to the Script object in that it uses the same logic to seamlessly integrate regardless of the installed DotNetNuke version.

Here’s a reference as shown in the example DarkKnight skin:

<%@ Register TagPrefix="dnn" TagName="STYLESHEET" Src="~/DesktopModules/SkinObjectsEx/StyleSheet.ascx" %>

and the skin object usage:

Note that this replaces the DNN STYLES reference in the DNN 6 DarkKnight skin:

On first glance these would appear to be the same, and they largely are (the STYLESHEET object is a fork of the STYLES code). However, the StyleSheet skin object has some big advantages:
- it will utilise the DotNetNuke Client Resource Management (aka imbibe) framework to combine all stylesheets into a single downloadable file, if it is available

- it allows you to specify FromVersion and ToVersion properties which controls whether or not to include the stylesheet with a particular version or range of DNN versions. This allows the skin author to have a single installable skin that has a different stylesheet for, say, DNN 6 and DNN 5.

Here are the properties for the StyleSheet object:
Condition

Carried over from the Styles object, the condition allows you to add a CSS Condition which helps to determine usage for particular browsers

Media

This property is carried over from the Styles object, and allows you to specify the media attribute for the stylesheet.

Name

The Name property uniquely identifies a stylesheet so that a single version is implemented per page

Path

The Path location works the same as the Script object, in that it has a choice of Absolute/Relative and Skin. This controls the references of the Location property.

Location

As with the Script object, the Location is used to combine with the Path value, and determine the actual Url of the stylesheet. See the Script definition for ‘Location’ above for more information.

Order

As with the Script object, the Order path allows you to specify a particular insertion order for a stylesheet. Note this value only works for DNN 6.1+ versions, and is ignored in prior DNN versions (in these cases, order is determined by the execution order, ie, the location on the skin file). The values for order are:

a_BeforeDefault, b_BeforeModule, c_BeforeSkin, d_BeforeContainer, e_BeforePortal, f_Last

These are entered as a string property value, which then converts them to a numeric value.

FromVersion / ToVersion

These two properties allow you to specify from and to DNN Versions. If the currently executing DNN version falls greater than or equal to the FromVersion value, and less than or equal to the ToVersion value, the file will be included. You do not need both, but can specify both. So you can have a ‘FromVersion=”6.0"’ to always include the CSS File from Version 6, or you can have ‘FromVersion=”5.5” ToVersion=”5.7” to only use the file in versions 5.5, 5.6 and 5.7 (although 5.7 doesn’t exist). And you can have a single version like ‘ToVersion=”5.4”’ to include the file up to the 5.4 version.

The format allows you to specify any level of detail, so you can say ‘FromVersion=”6”’ which is just the major build version, or you can qualify to the minor version (“6.1”) or down to the revision value (“6.1.1”). The system will automatically take the value down to the lowest value for any part of the version that isn’t supplied. So “6” is represented as “6.0.0” and “6.1” is represented as “6.1.0”.

That’s all there is to it! As the entire component is built without the usual iFinity branding I include, and is distributed under the same free licence as DotNetNuke, any skin developers can integrate these features into not only custom skins for particular clients, or into distributable skins they sell on Snowcovered or elsewhere.

Frequently Asked Questions

I’m guessing at some questions here as I haven’t really spoken to anyone about this, but here goes:

Why wouldn’t I just use the DnnJsInclude and DnnCssInclude skin objects in DNN 6.1?

These are the future path for everyone targeting 6.1+ DNN releases, and work well and are fully integrated into the Imbibe framework. However, in the messy real world of DNN installs, not everyone is up to date on the latest release, and building a skin to suit both current installs and future DNN 6 upgrades is tricky. The approach in this project gives the best of both worlds : simple JS and CSS inclusion now, and a seamless future upgrade path for when the client finally brings their install up to date in DNN 6.

It also suits those who want to sell/distribute a DNN 6.1 compatible skin now, but not close themselves off to those who are still running DNN 5.

Why would you include a Script object of ScriptType=”jQuery” – even in DNN 5, this was included?

It’s true that DNN5 shipped with jQuery, however, it’s possible that a specific page doesn’t have the jQuery library referenced. This is because the DNN code – somewhere in the page execution – has to call the jQuery registration code. The Script skin object with ‘ScriptType=”jQuery”’ will guarantee to the skin developer that jQuery is reference on the output page, no matter what the installed DNN version is. That way no skin developer should ever have to include the jQuery library themselves.

The same goes for the jQuery UI library – which is included in DNN 6 but not DNN 5. By including a ‘ScriptType=”jQueryUI”’ Script skin object, you can be sure of a reference to jQuery UI being included on your output page, no matter if it is DNN5 or DNN6, and you can be guaranteed not to have a duplicate jQuery UI reference in DNN 6.

What about DNN 4? Is this compatible?

The project is compiled against DNN 5.1.2 so can’t be used on earlier versions. You shouldn’t be doing DNN 4 stuff, really, it’s way out of date. However, if the powers-that-be control your DNN life and DNN 4 is it, you can probably change the reference and recompile to a DNN 4 version. It should still work OK.

Why would I want different CSS references for different DNN Versions

The inclusion of jQuery UI and the extensive use (and redefinition) of jQuery UI components (like the jQuery UI Tabs CSS classes) means that, for example, a CSS Class built for a DNN 5 skin might not layout properly when installed on a DNN 6 install. A skin designer wishing to make a cross-version compatible skin can use this component to run slightly different CSS files for 5 and 6, and their clients won’t know the difference – and perhaps most importantly – won’t ring them in the middle of the night after upgrading their DNN install and finding their layout all broken (or is it just me that doesn’t share a timezone with anyone else in the world)

What’s with this ‘Imbibe’ stuff?

This is my little personal crusade towards better project naming. I mean ‘DotNetNuke Client Resource Management Framework’ – that’s a mouthful of syllables, and distinctly Acronym-challenged (DCRMF?). So I called it Imbibe and hope it catches on. It won’t, of course, but if anyone ever comes up to me one day and goes ‘I’ve got a question about Imbibe for you’ I will give them a little high-five!

Of course, with all those FAQ’s answered, please feel free to hit me up with more questions in the comments below, or in the CodePlex project. This is my first Forge project released into the wild, so please give valuable feedback to get it up and running and living an independent life in the DNN ecosystem.

More ...

Improve Urls for the Ventrian News Article Module with the News Articles Friendly Url Provider

http://www.ifinity.com.au/Contact_Us — Thu, 15 Dec 2011 00:11:55 GMT

The big change for Url Master 2.5 was the inclusion of the ability to build custom module providers for generating module-specific Friendly Urls. Part of this strategy was to develop a set of module providers for popular third-party modules. This kicked off with the DotNetNuke Blog module provider.

The next module provider to be developed is the News Articles Friendly Url Provider, which transforms the Urls generated and used by the Ventrian News Articles module.

The new provider is a plug-in for the Url Master module, and provides seamless and easy-to-use features that completely change the way News Articles Urls look.

Improvements to Article Urls

Consider this Url which is generated by installing the News Articles module on a fresh DotNetNuke 6 installation:

http://example.com/newsarticles/tabid/135/articleType/ArticleView/23/The-Title-of-the-Article.aspx

By implementing the Url Master module, plus the News Articles Friendly Url Provider, and setting a few options*, the above Url can be changed to this:

http://example.com/the-title-of-the-article

Yes, you read that right, that’s how short you can get the Url.

But maybe you use the News Articles module as a blog, and you want some Urls that make it clearly identifiable as a blog. Change the options **, and you can have your Url look like this:

http://example.com/2011/12/15/the-title-of-the-article

(incidentally, this matches the style of Url this blog now uses)

*options used in first Url : Url Master – spaces replaced with hyphens, converted to lower case, no page extensions. News Articles Friendly Url Provider – ‘Article Style’ Urls, Don’t show DNN Page path in Url.

** options used in second Url : as per first Url, but using ‘Blog Style’ Urls instead of ‘Article Style’

How does it work?

Well, it’s simple really. Assuming you’ve already got the Url Master module installed and configured, you just install the News Aricles Friendly Url Provider via the DotNetNuke extensions. Activate the provider using the Admin->Portal Urls page, and then choose your options using the built-in provider Settings page:

Using this page, you just choose the different Url options for each page in your portal that has a News Articles module on it, apply the changes, and the Urls are instantly transformed.

What about my existing Articles?

The News Articles module has been around for a while, and there are many thousands of articles out there on the web already written. Some have been around for a long time.

The last thing you want to do is break the Urls for these old articles, some of which have good search engine rankings.

Of course, implementing this provider doesn’t stop those old articles from working. They’ll still work as intended. But you’ve got some options.

Firstly : you can activate the ‘Redirect ‘old’ style Urls to newer Urls. So if you implement the provider, all your ‘old’ Urls will be redirected across.

Secondly : you can choose which article the new Urls will start from. By default, this is id 0 – as in, all articles will use the new Ids. But you can enter your last article created (say, 145) and then any article from 146 onwards will use the new format, and earlier articles will keep using the standard format. This prevents having changes to existing articles and large-scale 301 redirects implemented and leaves articles ranking well in search engines as they are. Naturally, the redirect functionality works with the starting Article ID.

Where to get the News Articles Friendly Url Provider

The News Articles Friendly Url provider is available from the News Articles Friendly Url Provider product page. This is a licensed module, prices start from $30, but you can get a free Trial Licence by going to the licensing page. That will give you the ability to install the provider, try it out and decide whether you like the new Urls.

Online help for the module is provided through the News Articles Friendly Url Provider Knowledge Base.

The News Articles Friendly Url Provider is shown at the Url Master demonstration site.

Comments, Questions

This is a brand-new module hot off the coding bench, so if you have any comments or questions, please feel free to leave a comment below.

More ...

Implementing jQuery, jQuery UI and Javascript libraries across DotNetNuke Versions

http://www.ifinity.com.au/Contact_Us — Mon, 05 Dec 2011 23:46:46 GMT

DotNetNuke 6.0 brought jQuery UI directly into the framework as a ‘1st class’ DotNetNuke member. It also allowed developers to request the DotNetNuke jQuery registration code instead of each developer independently including the library, which prevents multiple versions and the subsequent page errors this will create. I have previously blogged about this in my post Using jQuery UI with DotNetNuke 5 and 6 in the same module.

With the release of DotNetNuke 6.1, the new Client Resource Management (aka imbibe) framework has been included. This framework not only includes jQuery and jQuery UI in DotNetNuke, but it uses a client registration framework so that other libraries and Javascript files can be included in the correct order. The best resource for this is Ian Robinson’s blog post : jQuery & jQuery UI in DotNetNuke 6.1 and 6.1.1. Because all of the various scripts are then registered in a single place, the framework can then combine them into one large js file, which drastically improves client side performance. You can read more about this in the DotNetNuke Wiki entry on the Client Resource Management API.

The 6.1 changes are an exciting inclusion into the world of javascript management for DotNetNuke development, but many (if not most!) people are not yet building solutions that target the 6.1 environment exclusively. If you’re currently building for an earlier environment which will (one day) be upgraded, or you’re building a module that may be applied against a range of DNN versions, then this blog post is for you.

While my previous blog entry was about how to leverage the jQuery UI registration, I’m going to build upon this and provide a one-stop solution to all DNN / jQuery / Javascript / CSS needs. This is simple a code file which you can include in your own project which will save you the hassle of going through and trying to write code to get jQuery to work for a specific version. This code has the smarts to work around all of the DotNetNuke versions and register the libraries for you.

Download the ScriptController Code

What the code does

The code hides away the different ways you must handle both jQuery and Javascript/Css File registration in your page. It automatically chooses the best way to handle the request based on the current DNN version. The code is backwards compatible to DotNetNuke 4.x versions, so you don’t need to reference the latest 6.1.1 DotNetNuke libraries in order to use the code (this is handled by reflection). All this means you can compile in one version of the code and be confident it will run optimised for the DotNetNuke version it gets installed in.

	DotNetNuke 4	DotNetNuke 5	DotNetNuke 6	DotNetNuke 6.1	DotNetNuke 6.1.1+
jQuery	Adds Google CDN reference	Uses Dnn jQuery Registration	Uses Dnn jQuery Registration	Uses Dnn jQuery Registration	Uses Dnn jQuery Registration
jQuery UI	Adds Google CDN reference	Adds Google CDN reference	Uses Dnn jQuery UI Registration	Uses Dnn jQuery UI Registration	Uses Dnn jQuery UI Registration
Javascript Libraries	Adds Head or Body Script registration	Adds Head or Body Script registration	Adds Head or Body Script registration	Registers script for body inclusion	Registers Script for Head or Body inclusion
Css Files	Adds Head registration	Adds Head registration	Adds Head registration	Registers file for head or body inclusion	Registers file for head or body inclusion

Above : Table of actions for code library. To understand, look at the column as per the DNN version, then at the Row for the function you would use in your code. Where they meet, this is the action that the code library does for you. However, the function call (left hand side column) is the same for all versions, the complexity is hidden away for you.

An Example:

The following code snippet shows how, in the Page_Load of a module control, the above code library is called in order to setup the required client-side scripts and Css files. The code library is called ScriptController.

//now get the javascript in
ScriptController.InjectjQueryLibary(this.Page, true, true);
//module-specific jquery code
ScriptController.InjectJsLibrary(this.Page, "moduleEdit_js", this.ControlPath + "/js/moduleEdit.js", true, ScriptController.ScriptInjectOrder.e_Default);
//and get the css file in
ScriptController.InjectCssReference(this.Page, "moduleEdit_css", this.ControlPath + "/moduleEdit.css", true, ScriptController.CssInjectOrder.f_Last);
//and put in a pre-dnn 6 ui script plus the jquery tabs library
string preDnn6CssFile = this.ControlPath + "/ui-tabs.css";
ScriptController.InjectjQueryTabsCss(this.Page, preDnn6CssFile, null);

The above code shows the ScriptController library being used. The steps are:

Inject the jQuery library reference. This call gives you the option to include the jQuery UI library as well
Inject the moduleEdit.js Javascript library. This call gives you the choice of whether to include the script in either the page or . The ScriptController.ScriptInjectOrder is an enumerated type which gives you the choice of where in the overall page output the script should be located. Note, however, that this only works for DNN 6.1+ versions – in earlier DNN versions this value will be ignored, and it’s pot luck which order your script comes out.
Inject the moduleEdit.css file. This call, like the Js registration, gives you the ability to include the file in the or , and uses an enumerated type to give you the choice where in the page order the Css file gets registered, but again, only for DNN 6.1+.
Conditionally inject a Css File for the jQuery Tabs Css theme. This call gives you the option of providing a pre-DNN 6 Css file which defines a custom jQuery UI Tabs style, and also a post-DNN 6 (ie, 6 and above) Css file for defining jQuery UI Tabs styles. The reason for this is that DNN 6 has a built-in Tabs style for the various admin pages that use the jQuery UI Tabs, and this snippet is for a module edit page. So, for pre-DNN 6 versions, it defines it’s own style (because DNN 5 doesn’t have a ‘tabs’ style), but for post-DNN 6 versions, it uses null, which means just use the standard DNN 6 tabs style.

The built-in Enumerated types for ScriptInjectOrder and CssInjectOrder give the ability to conveniently broad-brush locate where in the script order you want the script to go. This only works with DNN 6.1 because it requires the Client Resource Management API to do the work of locating the script. The enumerated types are prefixed with a_, b_, c_ so you get an idea of the order of the libraries as they are output onto the page.

Wrapping Up

This code library is free for all to use and is licensed under the same licence as the DNN core. So please take it and use it in your modules, projects and more.

If you find any bugs or problems, please let me know so I can correct them. If you come up with a better way of doing things, also let me know. If there is sufficient interest it could be located on a public source solution.

Using this approach will massively simplify the ability for developers to create multi-version code instead of having to try and step through all the minefields again.

Questions/Comments/Brickbats and Bouquets through the comments below!

Download the ScriptController Code

More ...

Google Secure Search Impacts Keyword Analysis for SEO and gives you (not provided) in Analytics - What you can do about it

http://www.ifinity.com.au/Contact_Us — Thu, 01 Dec 2011 03:01:20 GMT

Something that quietly slipped past a lot of people at the start of November was the announcement from Google that was rolling out SSL Search for all logged-in Google users.

This can be broken down like this:

- SSL Search means that the search session is conducted over https

- logged-in Google users covers the universe of people who are logged into a google service, such as iGoogle, Google+, Gmail – plus a whole pile of others.

- SSL Searches do not provide the Keyword data in the referer value for a click-through from Google

This fact that SSL searches do not pass the search query data (ie, the keywords used) onto the site that is clicked on has a very large impact on Analytics packages, which collect that data and summarize it for analysis.

This means that data using any Analytics package (not just Google Analytics) will no longer provide keyword data for some Google searches.

The justification given was that:

As search becomes an increasingly customized experience, particularly for signed in users, we believe that protecting these personalized search results is important.

Sounds good, right? They just want to protect user privacy.

Unfortunately for them, there is this little caveat:

You will continue to see aggregate query data with no change, including visits from users who aren’t signed in and visits from Google “cpc”. (italics mine)

I would find it much easier to swallow their line on protecting user privacy, except for the fact that they don’t want to protect the privacy when it comes to websites buying ads. Privacy for the user is only a concern for free traffic, not for paid traffic – and most google users wouldn’t really be able to tell the difference.

But it’s OK, Google tells us, because:

Keep in mind that the change will affect only a minority of your traffic

Well, that’s very heartening for them. As I noted previously, the change affects Google Analytics, which will no longer provide keyword data for anyone who is signed in. Instead, you will get a value that says “(not provided)”.

But if we take a look at the referral data for this site, we see that in the month of November, 2011:

‘not provided’ included 10% of all keyword searches used on the site
‘not provided’ is the keyword used for 71% of all new visits
‘not provided’ has a bounce rate of 69%

So, for all these new visits to this site, I’m unable to :

Know what they were looking for
Work out why they didn’t find what they wanted
Improve the site content to make the site more valuable to these visitors.

However, if I paid Google to run some keywords, they will happily give me all this detail. It kind of flies in the face of the mantra given to people who want to work within Google guidelines of making sure you have relevant, quality content.

For example, if I find this blog post becomes popular, it will become very difficult to know whether this is because it contains information about Google Analytics, or because it contains information about the Google SSL Search. So I won’t know if I should write more articles about one or the other. Unless, of course, I go out and buy a heap of keywords to see which one works best – then I’ll know. Imagine trying to run a retail store where you’re not allowed to ask the customer what they are looking for? The whole idea is crazy. A website still gets lots of detailed information about each visitor – right down to their location, device, whether they’ve visited before, what pages they read, what language they speak, but somehow it’s a violation of privacy to know what keyword they used? Give me a break.

Now, some readers will realise this has turned into a bit of a rant, which is a bit uncharacteristic of this blog. Let me establish up front that I respect that Google is a private company with a profit motive and, as such, are free to do whatever they want with their service. But let me also state that this marks, to me, the official point where Google jumped the shark and is no longer the benign, helpful, benevolent ‘don’t be evil’ web property we’ve all regarded them as for the last decade or so. The sheer front of them saying it’s for privacy – unless you pay up, then we don’t care how much user data you get – reeks of the sort of thing you’d expect from a PR obsessed corporation or Government department. I can take a lot of things on the chin, but treating people as non-thinking idiots with spin is one thing that doesn’t fly well for me. Those of us from Down Under are fond of straight-talking and telling it like it is.

It’s personally frustrating for me, because I have spent a lot of time over the years making DotNetNuke tools for free Google services (Analytics, Sitemaps, etc) only to find out that the key information I use for SEO on this – and any other site – is now to be gradually denied to me as an increasing amount of search comes from Google properties and signed in users. But then I think if I’m honest I always knew that would be the case – a public company has a fiduciary duty to do it’s best to reward shareholders, and it would take a very strong-willed manager indeed to ignore the amount of cash Google has left lying on the table in the past.

However, the key takeaway message here is that the ‘Don’t be evil’ motto is dead and buried, and we’re dealing with a monopolist every bit as powerful and intent on maximising it’s position as Microsoft did with it’s operating system lockout. So everyone needs to start operating and making key decisions with that background.

OK, so now what?

Well, moving past the rant onto the action. The simple fact is that a lot of us gain a large percentage of our traffic from Google web properties (and devices, too, viz Android) and so we’ve got to take what is given to us. I’m itching to use more colorful language, but I’ll restrain myself.

The rest of the post is dedicated to being pro-active about it and working out ways to ascertain the impact and think about new strategies. After all, change implies opportunity, does it no?

Quantify the size of the problem

This means tracking the growth of ‘(not provided)’ searches over time. If it’s at about 5% or so, and remains that way, it’s unlikely to cause too much bother over time. The amount of signed-in searches will be highly correlated with your sources of traffic. Basically, the more ‘tech savvy’ your audience, the more likely they’ll have a Google sign-in and be using it. If it’s static, well, then you’ll just have to work with it.

If the (not provided) keyword starts to grow, however, then you’ll need to start working out ways to try and ascertain the data. This might mean doing your own analysis on the main keywords of a page, and then manually linking that to the page and assuming that the traffic the page is getting is from those keywords.

How to measure your (not provided) traffic.

It’s easy to make the mistake of comparing apples with oranges. First, only Google organic traffic is affected. So you need to drill down in your reports, going into:

>Traffic Sources >Sources >Search >Organic and then click on the (not provided) keyword.

Above: ifinity.com.au (not provided) keyword impact, Oct/Nov 2011.

If you have an even spread between different search providers (Google, Bing, Yahoo, etc) then you’ll need to filter out the other search traffic to get an accurate picture. However, if, like my site, you get a massive majority of search traffic from Google (ie, 97%) then it really isn’t that important to filter out the other search traffic because it really isn’t material.

Either way – the only thing that is important is that you are consistent over time – it’s about tracking trends, and the key feature in doing that is to have a consistent methodology of collecting the data.

Quantify the impact of the (not provided) traffic

Now that the number of ‘private’ searches is known – you can check it against performance of other groups of traffic. This means looking at the ‘not provided’ traffic as an advanced segment, and checking it against other sources.

To create an advanced segment, click on the ‘Advanced Segments’ section, click ‘add’ then just select ‘Keyword’ ‘Exactly Matching’ (not provided) and click ‘save segment’. Give it a name like ‘(not provided) keywords’.

Above: Create a (not provided) keyword segment.

Once this segment is created, you can look at any report in Analytics then use the ‘Compare’ function to match between this segment and the ‘All Visits’ segment (or, better still, the ‘Non-paid Search Traffic’ segment.

Then you can apply these two segments to important metrics in your site, and see if the (not provided) traffic has a different profile:

Above : Goal Conversion Rate Non-paid Search Traffic vs (not provided) keywords

What this information tells me is that the (not provided) keywords follow a reasonably similar profile to all organic search traffic. Which means I can reasonably deduce that the distribution of keywords I no longer get to see is somewhat similar to the distribution of keywords I do get to see.

Taking this further, after reading this excellent blog post by Avinash Kaushik, who goes further into determining what is long tail and ‘head’, I decided to create two new custom segments in my analytics, one called ‘top 7 keywords’ and one called ‘long tail keywords’.

These segments are created by looking at a trailing 12 month history of keywords, and creating one segment that only includes traffic using those keywords (the ‘head’) and one segment that excludes all traffic using those keywords (the ‘tail’). The ‘head’ keywords are those that the site ranks very well for, and that are a clear intention of finding something on the site. These might also be called ‘brand’ keywords – because they are invariably a combination of ifinity + product name.

By applying this to the same Goal report, we can see that the (not provided) keywords perform much closer to the ‘long tail’ set than they do to ‘head’ set. Which leads me to my conclusion that, at present, the (not provided) keyword set is mostly long tail keywords and not brand keywords.

This is re-inforced further by checking the bounce rate for all content:

This shows that the bounce rate almost exactly matches the long tail keyword set.

Conclusion from this : it would appear that most of the redacted keyword traffic is of the same nature as the overall site profile, and performs closely to the ‘long tail’ of keyword data.

Action from this : monitor this over time (say, monthly) and see if any clear trends develop where this is no longer the case. If, for instance, the ‘(not provided)’ set started to outperform or underperform, you might rightly conclude that there is something significant in the set that is different in makeup to the rest of the keyword data.

Looking for other data sources

Of course, all the information in the previous post is just a ‘calm down’ action to work out what is inside the box of keywords we are no longer allowed to open. It doesn’t give us important data for tracking new keywords or developing themes presented in individual pages that perform well from search traffic (ie, hit the sweet spot of a high ranking in a well searched term). This would be vitally important if your site had relatively ‘fresh’ content (say, a news site). So what can you use?

This is where Google has thrown us a scrap of information by integrating Webmaster Tools into Google Analytics. This is a feature in the ‘new’ Analytics which has recently been rolled out. If you use Google Analytics and haven’t been on in a while, you should check out the new ‘Search Engine Optimisation’ feature. (> Traffic Sources > Search Engine Optimisation)

In order to use this function, you have to integrate your webmaster profile into your analytics profile. The webmaster profile can only be linked with a single Analytics profile.

So what does this new data give us?

Above : Search query data for ifinity.com.au.

Well, the cynic in me says a fat lot of pretty pictures with zero applicability to SEO. But you have to move on with the times – this is the new way things are going to be done so you have to get smart and move forwards.

There is a lot of junk data in here – I had no idea I was ranking for www.xxx.com (I’m guessing an adult site, I daren’t look) but throughout the forums on this site it’s a pattern people commonly use to redact the domain information when seeking help on Urls. Of course it gets me no click-through traffic, which is why I’ve never noticed. But it is noise that needs to get filtered out of the data in order to start working with the useful information.

It’s important to realise that this data has been in Webmaster console for a while, but is now presented in an easy-to-access way alongside your Analytics data. What we are looking at here is the google.com side of things - how many impressions search terms had, how many clicks, and your sites average position for those impressions. Finally it gives you a click-through-rate (CTR).

While it’s not obvious at first glance, this is the reverse side of your keyword data on your site. So when you have a suspicion that a particular keyword is performing well for you, you can go to this report and search on that keyword (or combinations thereof). If, in the hypothetical case I’ve already outlined, you have a page doing well and for some reason the majority of keywords working for that page are unknown to you, then you can come to this page and search on both sets of keywords and see which is performing better from the google.com side of things.

You can also do a search through the CTR rates and impressions to find which keywords you could improve and optimise for. Combined with the Google Keyword tool, you should be able to ascertain the broad trends well enough, despite the fact that it takes a little more work.

Conclusions

There is an old saying that goes like ‘when the rules change, the future changes’. The rules for keyword data have just changed, and so the future has now changed. You should probably be like me, get your toddler tantrum rant out of the way and then get on with figuring out how the future is going to work. This is all very new, so it’s definitely important to monitor this space for changes, and additions. It’s possible that Google might recant and start providing the data again, particularly if it affects their ad-buying business. Or it’s possible that Google+ takes off and challenge Facebook and a majority of users will be logged on by default. It’s possible that Android devices will stop referring search data or some other type scenario.

The important takeaway is to start thinking about these scenarios now and work out your strategy to find the good keywords for your site, and how to optimise for them. That part is unlikely to change at all.

What do you think about it? What percent of your traffic is now (not provided)? Please let me know via the comments below.

More ...

Crafty Code

Forge, Codeplex and Friendly Urls

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

The true cost of scratch building

Where does the platform really end?

But - It’s more than the cost

It’s also about the future

A Virtual Comparison

What’s new in DotNetNuke 6.2–Presentation to SEQDUG

About the User Group Meeting

About the Presentation

Different robots files for different DotNetNuke Portals

Updating your Vendor Google Analytics for the new DotNetNuke Store

Happy 10th Birthday .NET Framework–the little platform that could

The way we were

The Genesis of .NET

.NET Leads the Microsoft Developers out of the Wilderness

.NET grows and grows

.NET Did it Right

The next 10 years

New Skin Objects for including jQuery, Javascript and CSS Stylesheets in DotNetNuke Skins

What’s in the box?

Script

Stylesheet

PageLink

Portal Date

Using the Script Object

ScriptType

Location

Name

Order

InHeader

StyleSheet

Media

Name

Location

Order

FromVersion / ToVersion

Frequently Asked Questions

Improve Urls for the Ventrian News Article Module with the News Articles Friendly Url Provider

Improvements to Article Urls

Other News Articles Urls

Page Urls

Author Urls

Archive Urls

How does it work?

What about my existing Articles?

Where to get the News Articles Friendly Url Provider

Comments, Questions

Implementing jQuery, jQuery UI and Javascript libraries across DotNetNuke Versions

What the code does

Wrapping Up

Google Secure Search Impacts Keyword Analysis for SEO and gives you (not provided) in Analytics - What you can do about it

Quantify the size of the problem

Quantify the impact of the (not provided) traffic

Looking for other data sources

Conclusions