I have been working with DNN (formerly Dotnetnuke) since 2008 and version 4.x. There's a lot to like about DNN. The design is logical and easy to understand and work with. Skins are easy to build and highly adaptable and there are excellent templates and tutorials to get you started with building modules. It's very intuitive to manage content and user roles and permissions give excellent control over who can see what.
Since 2008 I have built dozens of modules, skins and scheduled tasks for DNN in both VB and C#. Many of these are still in use today.
However, during this time there have been many frustrations such as.
- Baffling decisions being made over enhancements
- Persistent upgrade failures
- Bugs in the core framework that aren't fixed
- Poor support or lack of knowledge in the forums
- Lack of clear project leadership and clarity (the roadmap is still out of date and has been for months)
- Slow response to change. Many developers have become bored or frustrated and moved to MVC, Web API or Node.
I have never used the professional version "Evoq" so I can't comment on how that compares to the community version I have always used. But of late I have started to feel that unless DNN is re-written from the ground up in .Net Core it will die a slow death. It's a huge job and due to the desire of the DNN core developers to support existing developers it may not happen. But I feel it has to happen soon before it's too late.
We can envisage a future where both WordPress and DNN evolve into web services frameworks where the client takes over much of the processing burden and multiple applications run from a single server instance.
Since I have been thinking a lot about the pros and cons of DNN and Wordpress I thought it might be useful to put some of these down in writing in case others might be asking the same sort of questions.
Firstly, the stack.
DNN is built with the ASP.NET web framework in the language C# with a SQL Server database back end. Wordpress, is written in the web orientated programming language PHP with a MySQL database. There's little point in attempting to dive into the pros and cons of these stacks in this post. There are piles of other developers out there who are far better qualified than me to make that comparison. I think that the best developers out there can code in both and my advice would be to keep your mind open. There is much brilliance in both stacks. On a personal level I prefer C# to PHP but PHP has improved dramatically in recent versions and some people think it's faster than .Net.
There was a time when the Microsoft stack was more expensive to host than the Unix one. However, that is no longer the case. These days there is no significant difference in the cost of hosting between a DNN site and a Wordpress one.
Wordpress can be installed on both Microsoft and Unix servers whereas DNN requires IIS and SQL Server. This is a useful advantage for WordPress because it means you can mix up .Net applications and Wordpress on the same windows server. If you only have a Unix host and you need to run DNN you will have to get another hosting package.
I have had Wordpress developers tell me that you should never run WordPress on IIS but I have never found evidence to back up their prejudice. So far I have been able to do everything I have needed with a WordPress site on a Windows box. It runs just fine. If you keep on top of the bloat and use a quality theme you will be fine with WordPress on Windows.
As far as the databases go for running either of these systems on a modest site I would not think that the database makes a great deal of difference. However, if your site is likely to have a great deal of traffic and/or a huge number of users I would consider the database very carefully. From my experience, SQL Server is more robust and faster than MySQL and a much more serious enterprise solution. But I cannot qualify this with hard evidence. Fingers crossed, I have never seen a corruption in a SQL Server database but just the other day my host had a corruption issue with a MySQL Server and I lost several hours of work. I had been working on a Wordpress site online and hadn't backed up for a few hours. My host was forced to roll back to the previous days backup to get the MySQL DB online again.
If you are likely to be getting a lot of traffic then you can handle it with either WordPress or DNN if you know what you are doing and can pay for the hosting. However, there may be a better solution out there. Something that is built to handle high loads. It would be wise to assess your requirements carefully in order to chose the right approach. A static site generator accompanied by a service like CloudCannon might be a better bet. Or a Ghost web site which is built with Node and designed to handle high traffic and group content management.
Secondly, the community and ecosystem
In this area WordPress wins hands down. The WP community is huge and the number of plugins and themes in the marketplace is enormous. This is hugely important as a developer because when you need answers you get them and quickly. In the world of DNN it's easy to feel isolated and alone on some quest to solve a problem where an answer is elusive. Often I have posted on the DNN forums and not had a single response. Or been met with others experiencing the same issue but having the same trouble finding a solution. The DNN API is very poorly documented or not documented at all. The language DNN was written in has changed from VB to C# which means that a lot of answers provide code in VB. There are plenty of themes and modules available but nothing like the quantity available for WordPress. You can get a lot of very good code for free for a WordPress site.
However, there are some things that are baked into DNN as part of the .Net framework which have to be got from 3rd party plugins in Wordpress. One example is number of login retries. In DNN you can just edit the web.config file to configure this but in WordPress you have to chose a plugin, install it and configure it. I feel that features such as this should be baked into the core. The one advantage of not having them in the core is that you have more flexibility. But, the down side is it makes WordPress less secure out of the box. An unwitting new owner could overlook this and find their site hacked at some point or overwhelmed by login attempts.
Part of the problem with DNN is that due to the fact it's based on Microsoft technologies it hasn't had the huge ready made audience that comes with PHP and the LAMP stack. It would have been nice to see DNN get the same developer attention and uptake that WordPress has had. What a product it would have been then!
I can't help but wonder if, with the arrival of .Net Core and Microsoft's apparent enthusiastic embrace of Open Source and Cross Platform that we may see a .Net product begin to compete with WordPress at some point? We have seen that SQL Server is now available on Linux and the awesome Visual Studio Community has been released entirely free of charge. There may come a time when a .Net Core blogging platform emerges to take us forward from the Wordpress and DNN type stacks. A .Net Core blogging engine could be much faster than both WordPress and DNN and would run cross-platform. With the the right abstraction it could run against any DB or could saves posts as markdown files or static HTML. This blog itself was written in C# with NancyFx and simply serves markdown files from a content folder.
The design as a content management system
WordPress began life as a blogging engine and nothing more. DNN on the other hand was based on the IBuySpy Portal which was designed to serve various types of web content. DNN soon evolved into a fully fledged CMS with one distinct feature that attracted me when I first came across it. With DNN you could create multiple "portals" or distinct web sites from a single instance running on a single hosting platform. I realised that I could build dozens of dynamic web sites for clients and charge them reasonable hosting fees while paying only a single web site hosting fee myself. I could also administer everything from where ever I happened to be living as long as I had the internet and could log into the DNN instance. For a while I managed my clients web sites from my boat!
Not only does DNN allow multiple sites from a single instance, each site has a unique collection of registration settings, users, roles and theme files. This functionality is available out of the box for all versions. It's an impressive feature and works very well.
There has been a multi site version of Wordpress since version 3.0 and this is a proven product powering countless blogs and millions of readers at WordPress.com. It's very clear that when set up and hosted well that Wordpress is hugely scalable. There is nothing like Wordpress.com for DNN so it's impossible to say how well it would handle such demands. What I can say is the since DNN handles multi sites out of the box it's very easy to set up. You just go to the admin area and ad a new portal for your domain. If you domain is already pointed at the site you are up and running. But for Wordpress the feature is considered something for only those who want to set up a multi site blogging platform. So the multi-site feature has to be turned on and configured manually.
Wordpress is still structured as a blogging platform but has morphed into a CMS. You can add and remove pages in WordPress much as you can in DNN. Wordpress has a left hand side dashboard which is derided by some but works well and is easy and intuitive to work with. DNN as of 9.x also has a left sided menu which is now all ajax driven. It's very sleek and much snappier to work with than older versions where full page refreshes were taking place.
Where DNN differs is in the way that pages and content can be edited. DNN theme templates divide the entire page up into logical sections. The layout of these is limited only by what you can do with CSS. Skin objects which are separate code files are used to provide theme features such as breadcrumbs and current user.
Plugins (modules in DNN speak) can be dragged and dumped into these logical sections very easily. If you don't like the layout you chose a theme page with a different layout. Most themes come with a plentitude of different layouts and containers. Each module instance can be configured on the page. For example, if you want a form to appear for only client users then you dump the module onto a content pane and set the permissions for that module to be visible only to the users in the client group.
This is one area where I think DNN excels. In WordPress when you install a plugin you generally have no idea where that plugin will appear or what it will do. Depending on the plugin you may or may not be able to control where it appears in the settings. The plugin can control where it appears and what it does or the developer must add short codes to various theme files to make the plugins appear where required. This is a lot fiddlier and more messy than the DNN approach.
I have long suffered with 3rd party modules in DNN taking over a site and rendering it beyond repair. Sometimes the 3rd party modules break when you try to upgrade DNN. Sometimes the module developers move on and their module is abandoned. Once abandoned it is only a matter of time before something breaks. Sometimes modules developers are so poor that they are unable to fix a small but critical bug in one of their products. I once had a "tearing my hair out" experience with an e-commerce module vendor for a DNN site I was working on. I ended up ditching the module and buying another. On other occasions the modules have been first rate and the support excellent. My favourite is Xmod Pro.
With regard to plugins and themes I can say that I have almost exactly the same experience with WordPress. I recently inherited a WordPress site that was built using a plugin called Visual Composer. The site is a complete dog. In all my years as a developer I've never come across such a bloated system. There are literally dozens of css files and js libraries that are not even being used. There is a horrible .PHP file that dynamically loads CSS depending on the configuration. The problem is that because it is dynamic it can't be cached. That file alone was taking on average ten seconds to load! The Visual Composer tool would not run. I had no record of the licence because the previous developer had moved on. I contacted support. "Sorry we can't help you". The original licence was supposed to give free upgrades for life. The developer told me I had to buy a new licence. At least that made the decision for me. I would build a new site rather than try and rescue the old one. What a mess.
Urls and SEO
There was a time when urls were awful in DNN but after version 7.x things have improved dramatically. You now have complete control over urls baked into DNN. You can also get modules to refine things further or you can use the IIS url rewrite module. In this area there is no reason to favour one over the other any more.
Regarding SEO, out of the box DNN is better because everything you need for SEO is already there. But with Wordpress there are many different plugins to do the job free or at a price for a premium version. I am no expert on SEO but I do feel that up to a point there is only so much you can do. Ultimately it comes down to traffic. If you have two sites with identical set up and different content the one with masses of traffic will be ranked higher. I feel that companies are trying to flog expensive SEO services that will make little difference. It's very important to build sites that are mobile friendly, lean, fast and well structured in terms of SEO. Google tells us how to do this. But how far do you go? Is every tiny tweak really that significant? Or are we being duped into buying a premium module because we are sold on the black arts of SEO?
In DNN localisation is built in and is pretty comprehensive. Here is a good summary of how it works. I have been involved in a DNN project that needed to be displayed in several languages including Chinese. The problem with the .NET system that DNN relies on is that the localised data is stored in .resx files. At the time the DNN interfaces were far too limited to enable editors to change content within DNN. Also there were dozens of custom modules that had their own .resx files which could not be edited in DNN. It was decided to build a custom resource provider as a SQL Server database and bypass the DNN method. This enabled us to build our own content editing applications which greatly improved things.
This solution worked well but was costly to build and implement. Personally I don't like the .rex files method but when you look at the other methods in use there is no ideal solution.
Wordpress again does not do much out of the box. Once you have built a WP site in your chosen language you then have to decide how you want to go about doing your translations. You have to chose a plugin such as qtranslate. I have no experience of using this but it looks straightforward to use although one look at the qtranlate site would be enough to put me off a little.
The issue is that how suitable would this be for an enterprise solution? Probably, like with DNN, less than ideal.
I would suggest that neither system would make an ideal choice for a large scale multi-language web site.
Licencing and Code Protection
The DNN Community platform is an MIT licensed application, meaning you can pretty much do anything you want with it, including selling it. You can use it for a free website, you can use it for a paid website, you can use it to build an application and then sell that on for profit.
If you build a module in DNN then once you have compiled it into DLL's your source code cannot be read by your customers. Of course it can be reverse engineered by someone with the skill and time on their hands but for most cases it's not worth anyone's while. Most module vendors these days use some kind of activation method to protect their products.
In contrast, Wordpress uses the GNU General Public Licence which at the moment is something of an issue for many people.
WordPress’s GPL Requirement
All software that you’ll find on WordPress.org in the Plugins Directory and the Themes Directory must be licensed under the GPL v. 2, or a compatible license. This ensures that all software on wordpress.org is free and open source.
From this blog post which is worth reading in full.
"Earlier this year, the WordPress Foundation contacted some WordPress community members apparently informing them that they couldn’t volunteer or speak at WordCamps because they sell themes or plugins that don’t entirely adhere to the GPL or compatible licenses. That sparked a load of drama on Twitter; if you’re interested in reading more, check out Jake Caputo’s posts: Automattically Blackballed and Un-Blackballed."
Some Wordpress plugin and theme vendors are selling their code by not sticking to the GPL whereas others are asking for subscriptions for updates and support.
If you are building for an enterprise environment or planning on building stuff to sell this licencing situation might decide it for you. From my point of view I prefer the DNN way as it's less ambiguous and less open to abuse.
DNN modules are compiled into DLLs which cannot be easily copied. If you build a Wordpress plugin in PHP you cannot hide your code. Under the GPL licence another developer can copy your code, modify it, re-brand it and sell it on ignoring the GPL.
So which one is better?
Well, if I was looking for a blogging platform for a client I'd certainly consider Wordpress because it is a great blogging platform and an amazing application. However, it would depend entirely on needs. I would certainly be looking at static blogging solutions such as Jekyll and modern systems such as Ghost and evaluating them against the client's needs and experience. There are decent modules available on DNN for blogging but why bother? Perhaps, if the client already had knowledge of the .Net stack and specifically wanted a .Net solution I would favour it. They may want to join to another external database and display CRM data on the same application. This would be easier for them with existing .Net knowledge.
DNN is very stable and secure and version 9.x is excellent. It has great caching built in and is lean and snappy. There is nothing lacking in DNN as a blog platform. You may have to pay a little for the best blog module but there are quality free options.
Since I am a C# developer I would look to DNN, Nancy or .Net MVC for any project that required a bespoke solution. If I had a client that wanted a simple site they could edit themselves I would chose DNN because I think it's faster out of the box, more intuitive for a newbie and more secure. DNN has great caching, decent SEO and good security out of the box so it makes sense for a low maintenance solution.
Ultimately WordPress is a more refined, complete and better supported platform than DNN. However, there are aspects of DNN I much prefer. With Wordpress you end up having to install loads of plugins just to reach a base level of functionality that's acceptable. You end up constantly struggling to stay on top of these plugins as they are updated. Some plugins deface the Wordpress dashboard with alerts and other stuff and others bully their way around doing stuff you never asked them to do. In DNN the base install is much more complete. Configure a few options and install a theme and you're away. There is no confusion between posts and pages and IMHO it's much more obvious where to change things. In DNN you can edit the config files and the database right there inside the CMS which is often useful. Wordpress would require plugins for those features.
If you are looking at DNN and Wordpress for a project I would recommend carefully considering your needs and keeping your mind open. Don't jump into a decision for the wrong reasons. For example, the wrong reason might simply be, "because that's what everyone else is using". The more evangelical about systems people get the less able they are to make rational decisions. In CMS and blogging platforms the technology is moving on. Legacy systems like DNN and Wordpress will always be held back by reliance on a stack. From time to time the developers needs to start from scratch but they can't because the community will have to start from scratch too. If you are free to chose something for a new project don't overlook the modern tools that are out there. They may solve your problem better and serve your needs for much longer.