Comparison by Capability

When comparing Content Management Systems, there’s a nearly endless set of criteria to evaluate: performance, SEO, ecosystem, editing, taxonomy, extensibility, etc. In this post, we’ll compare three of the capabilities most commonly asked about by our customers:

• Permissions
• Security
• Themes & Administration

DNN vs. WordPress: Permissions

DNN and WordPress ship with a set of built-in user roles. The CMS utilizes user roles to apply permissions to a group of users (i.e., all users assigned to a user role).

Both DNN and WordPress have default permissions settings that determine actions enabled or disabled by each user role. The built-in user roles are:

Permissions in DNN

In DNN, granular permissions and custom user roles are supported in the core CMS; those features are not part of the WordPress core.  Instead, they’re provided by third party plugins.

In DNN, permissions can be applied at many levels: site, folder and page, as well as individual modules on individual pages.

For DNN, the advantages of having granular permissions supported in the core:

• Ability to view the source code
• No dependency on third party vendors
• Consistent administration vs. learning to use different plugins

The DNN Documentation Center is a website with documentation on the DNN CMS. View these pages for more information on user roles and permissions management:

• How to create a custom user role
• How to assign users to a role
• How to configure page permissions: proceed to Step 4 on this guide to creating a page.

Permissions in WordPress

WordPress has a similar structure to managing permissions. However, features such as granular permissions and custom user roles are not part of the WordPress core. Instead, third party plugins must be downloaded to provide these capabilities.

The default user permissions in WordPress are generally not enough for larger organizations that require more specific use cases.  If you need to give a user permissions to only edit a certain page or section (instead of the entire site), you will need to download and install a plugin.  There are several to choose from.

As with all third party software, we recommend you evaluate the plugins’ reviews, number of active installations, and last update date. Get suggestions from colleagues, partners or peers with first-hand experience using particular plugins.  Every plugin you install on your website can come with its own security vulnerabilities and impact other plugins on your site.  So make sure to have a back-up ready to go before the installation.

DNN vs. WordPress: Permissions (Conclusion)

If you have a relatively simple site with a small number of users and user roles, both DNN and WordPress work well.

For complex sites with 20+ users actively managing content, with custom user roles and the need to manage granular permissions across folders, pages and modules/plugins, we prefer DNN, since all of the needed capabilities are built into the core CMS.

To manage permissions on a specific module on a page, you edit the module properties and set permissions accordingly. This is done the same way for any module in use. On a WordPress site, permissions are set in the plugin administration menus and can vary widely from plugin to plugin.

A comparison of security between software systems can be qualitative rather than quantitative: anecdotal experience and opinion factor into the equation to a large degree. That’s no different in comparing the security of DNN vs. WordPress.  In many cases, it is less the platform itself and more how it was set up by your web development company.

In this section, we’ll defer on recommending one CMS over the other on the basis of security; instead, we’ll point out a few things for you to take into consideration.

WordPress: Popularity Makes it a Common Target

Sometimes being the most popular CMS has its disadvantages.  Site security is one of them.

With WordPress handling over 1/3 of all websites, it is the most targeted by malicious hackers and spammers.

The most common entry point for malicious hackers is to find exploits in popular third party plugins. If an exploit can be used to gain unauthorized entry to a site, hackers can scan websites to see if they’re running WordPress.

From there, they can attempt to leverage the exploit. If the site is running a version of the plugin containing the vulnerability, it (i.e., the site) can be hacked.

A similar exposure exists for DNN, since it has an ecosystem of third party modules and themes. In the past few years, DNN websites have been hacked via vulnerabilities in third party DNN modules.

However, there are fewer modules in existence and far fewer sites running DNN. As a result, hackers spend most of their time against the number one target: WordPress.

WordPress being the largest target for hackers and malicious bots, it is more a question of when, not if, the website will be compromised. You don’t need to have a popular website to be a target. Hackers will crawl and scan the web for sites with known security flaws to exploit. Keeping your CMS version and plugins up to date in WordPress will go a long way in helping you stay protected.

Security in the Core CMS

In addition to third party plugins and modules, another entry point for hackers is the core CMS itself. Security vulnerabilities have been discovered in the core platforms for both DNN and WordPress.

While some may call this issue a security vulnerability, the official response from the WordPress team is that it’s the expected behavior. In a thread on the WP-API GitHub page, a member of the WordPress API team writes:

“Usernames are already exposed through themes, RSS feeds, etc, and we do not consider them a security issue. You can install a third-party plugin if you would like to limit access to this data.”

We don’t agree with this approach to web security; while we wouldn’t block a client’s choice to use WordPress on the basis of this API “opening,” we would advise clients to use whatever means necessary to limit access to their sites’ user data.