For the past several weeks I’ve been involved in the design and testing of the next version of the PackFlash Mega Menu module. This has caused me to, once again, visit the various permutations of DotNetNuke (DNN) installations to insure that the new DNN module will not run into trouble “in the wild.” This is not a fun task, but it’s also not fun to get reports of bugs. I often hear from offshore companies that claim that they can take this burden off our shoulders, but all of our DNN development happens right here in Chicago, and we’ve found that the testing needs to take place here too if we want to have any kind of effective feedback loop.
If you are thinking of building and releasing a custom DNN module, either for profit or as a community donation, here is a brief list of installation scenarios that you should consider testing. These are the scenarios we try to account for in the testing of our DNN modules.
The First Hurdle: Supporting Multiple Versions of DNN
Early on, you should determine the range of DNN versions that you wish to support and commit to testing your DNN module across this range. Obviously, supporting a broader range of DNN versions will increase your potential install base, but it also increases your effort considerably, and it may cause you to write “branching” code to accommodate version changes.
While DNN generally does a great job of supporting backwards compatibility, there are going to be hurdles whenever you try to support across major versions. This is intuitive – you would expect that there would be major changes between DNN versions 4 and 5, or between 5 and 6. However, these aren’t the only points of major change. For instance, DNN v5.2 introduced the “localized content” feature, which bought changes in the way that locale information is saved and detected. The same version also included the Telerik UI control collection for the first time, so if you are using a Telerik control in your module, you’ll have difficulty supporting DNN versions prior to 5.2.
Here is a short (and by no means complete) list of functional areas to be careful of if you are trying to support a wide range of DNN versions:
- Localization – the DNN methods for managing locales changed in DNN v5.2, when content localization was introduced.
- Use of jQuery – support of jQuery was in flux from DNN v4 to the early versions of 5
- Automatic DNN page creation (via code) – the methods to create pages changed in the late v5 series … from v5.5 to v5.6, I believe.
- Administrative UI – the paradigm for the administrative UI changed dramatically (and for the better) in v6. If your module’s admin screens are relatively simple and rely on the standard DNN admin label the transition will be relatively seamless between v5 and v6. However, if your module has more complex administrative UI screens you may find that the formatting is thrown off.
Test for Multiple Portals, both Parent and Child
One of DotNetNuke’s most important features is its ability to support multiple websites, or portals, from a single installation. As a module developer you need to be aware of this feature and properly architect your DotNetNuke module to insure that portals are insulated from each other, and then test your module in multi-portal installations. Here are a couple of things to watch out for:
- Make sure that all data storage and retrieval operations include the DNN portal ID so that users of one portal don’t see data from another.
- Make sure that any file operations take place under the directory of the current portal (each portal has a dedicated sub-folder of the site).
- Put thought into whether some operations of your DNN module should be restricted to host-level users.
- Don't necessarily assume that because your module works well with multiple parent portals, that it will work for child portals. There are some situations where this slight difference can cause a problem, particularly if you are doing URL operations.
- With regard to portals, be aware that a DNN portal can have multiple aliases, or domain names, associated with it.
Test Your Module with Localized Content Enabled
In DNN version 5.2, content localization was introduced. With this feature, DNN provides the infrastructure to manage pages and modules across multiple languages. An explanation of the methodology of this feature is beyond the scope of this blog. Suffice to say that this feature does NOT mean that your module automatically supports localized content. There may be extra work that you need to do if you wish to say that your module is “multilingual.” Even if you don’t care about supporting localized content, you may wish to test this scenario so that you can be aware of how your module behaves if users are switching between languages.
DNN Installation in a Virtual/Sub Directory
While the most typical installation of DotNetNuke involves setting the application up at the root of a web site, it is also common for people to install DNN in a sub-folder. If your module interacts with the file system, you’ll want to take the different installation location scenarios into account and test for them.
Use of a Database Object Qualifier
During the DNN installation process, there is an opportunity to specify a database “object qualifier.” What this means is that all database tables, stored procedures, and functions will be created with whatever prefix is specified. For instance, it’s common for people to specify “dnn_” as the object qualifier. In this instance, it is expected that ALL DB objects from 3rd party modules will be created in the same manner, using the object qualifier. Thus your installation scripts and DB provider objects should use the standard methods for including an object qualifier if one exists. And, you should test your module in an installation of DNN that uses an object qualifier.
Supporting Multiple Versions of SQL Server with DNN
The vast majority of DNN installations use MS SQL Server for the database, although it is possible to use other DB providers. Likewise, the vast majority of module extensions only supply DB providers for SQL Server. I’m going to assume that you fall into this camp. Beyond the DB vendor, you’ll want to be aware of the different versions of SQL Server that are out there. Luckily, most DNN installations are using SQL 2005 or 2008 at this point, and these two versions are very compatible for most of the things people tend to do in DNN. We have come across folks using SQL 2000, however, and for a while we did support that platform. I won’t get into the ramifications of that, aside from saying that the available field types changes between versions (text data type vs. varchar(max)). If you are developing a new module for DNN in 2012, it is likely that you are NOT using SQL 2000 in your development or test environment. And it would also not surprise me if you had designed your database in a way that is not compatible with SQL 2000. Whereas, if you are using SQL 2008 or even SQL 2012, there is a pretty good chance that you can install into SQL 2005 without a hitch. The point of all this is:
- Be aware that there are people out there who are using DNN with SQL 2000. If you want to support this DB, then you should test for it and be aware that there is a good chance that you may need to change your DB design slightly. If not don’t plan to support SQL 2000, then you should say so.
- There is an excellent chance that your application can live happily on SQL 2005, 2008, and 2012 without any changes to your DB design. Still, you should take nothing for granted and test for these different versions … or you should come out and say which DB versions you plan to support.
Testing Module Upgrade vs. Fresh Installation
DotNetNuke has a decent process to manage module upgrades (that is, to manage multiple versions of your 3rd party module extension … I’m not talking about upgrading versions of DNN). If you’ve gotten to the point where you are releasing a new version of your module, you’ll want to test cases where the module is being installed “fresh,” and where you are installing “on top of” a previous version of your module.
Testing the Deletion of Your Module
It may be hard to believe, but not everyone who installs your module will want to keep it. You should be a good sport and make sure that your module cleans up after itself and properly deletes all database objects and files (if requested) when it is deleted. Making sure that the deletion process works properly also has the benefit of helping you test the “fresh installation” case, above.
Handling Skin Variations
If you do all of your module development and testing using a single DNN skin, you are at risk of making incorrect assumptions about how your module screens will render to end-users or administrators. You obviously can’t test or support every possible skin, but there is an art to designing your screens to be flexible enough to work well in a wide variety of skins, and depending on your module goals you will want to see what happens when the module is used with different skins and/or containers. In some cases, such as for complicated administrative screens, you may wish create a UI that remains consistent across skins. This is easier said than done and you should definitely test multiple skins if this is what you are trying to achieve.
Tell Me Your Thoughts About Testing DotNetNuke Modules
I couldn’t hope to cover all the possible permutations of DNN installations. Hopefully I’ve done a good job of covering some of the major options that are out there and likely to affect your how your module will behave. I’d be interested to hear if I’ve missed anything major. Let me know via the comments.
See you in Evanston This Week!
I’m looking forward to seeing lots of other DNN developers in Chicago (well, Evanston) this coming week at the 2012 CMS Expo.