Today the latest version of DMX was released: 6.1. This release brings a couple of new features, a slew of enhancements of existing features and a number of bug fixes. As usual a lot of the work that was done remains invisible to the end user as code is cleaned, streamlined and new efficiency improvements are made. As well as fixes to remain compatible with the latest platform architectures (specifically DNN 7). The dependency has been moved up to DotNetNuke 6 which allowed a lot of code cleaning.
DNN 6 Dependency
As stated the product now requires minimally DotNetNuke 6.0.0 to run. As the DNN platform evolves we want to leverage some of its new features. But in doing so we risk creating a product that relies on a version of DNN that few users have installed. This problem is very common in the software industry. In fact, with DNN 7, DNN Corp has moved the dependency of DNN up to SQL 2008 for example. This is so they can leverage some new features in those. As you can see there is a significant lag between the release of a new SQL Server version and the use of its new features by a platform like DNN. The same goes for DMX. We need to wait for a specific version to have a large enough install base before we can make a move. As data is hard to come by (we’ve asked DNN Corp repeatedly to be more open about this, but we have yet to receive data about DNN version adoption) we need to make an educated guess. And sticking to a rule of thumb of “not something that was released within the last 12 Months” appears to work reasonably well (i.e. we don’t get too many disgruntled customers who need to upgrade DNN before upgrading DMX). DNN 6 was released in July 2011, so it seems a safe bet.
Search remains one of the core functions of document management and it remains central in DMX. The default search engine (Lucene) received some attention with the inclusion of new IFilter code to help it load IFilters to read documents. The hope, here is that under more circumstances the IFilter loading will work out-of-the-box, without the necessity of server tweaking. Also the stemming (the way it analyses texts before storage) has been improved to help it find the documents you’re looking for.
More significantly to end users, probably, is the improvement of the search screen. As you may know, DMX can start with a UI of your choice. The default UI is the familiar “Windows Explorer” look. But there is also a templated UI and a Search screen UI.
The latter was originally designed to be used on the search results screen. You can still do that. It will show search results from DMX when you do a search in DNN. But now you can specify some options for the search screen:
Opting to show the Advanced Search will bring up the screen in advanced search mode:
This way you can stick this on a dedicated page for users to do their document searches on. You can opt to have the search results displayed on the same page or to immediately redirect to a page with DMX and load the search results there. Also you can specify what happens when a user clicks a link: whether they go to the default DMX page or to a DMX page of your choice. In all you have plenty of options to improve your users’ search experience.
Integration into DotNetNuke’s File Manager
This is not an idea born yesterday. In fact, the wish to have DMX content show up in the HTML editor and in the File Manager are most certainly FAQs. It is a recurring theme. Why can’t I see the content. Well, for a long time there were no integration points in DNN. The only way to do this was to use a component developed for a CodePlex project called the RadEditor Provider. This was designed for DNN 5. DNN Corp realized that there was a need to open up the framework at this point and since DNN 6 we have the so-called Folder Provider. They also incorporated the aforementioned Codeplex project into DNN. For a while the solutions existed side-by-side as the DMX integration was still supported in DNN 6.0 and 6.1. But recently this path has been cut off. Since 6.2.1 the DMX integration that was originally made for the editor provider has been removed.
So this was one of the many reasons to move up the dependency to DNN 6 and begin to leverage the Folder Provider. I’ve not been a big fan of it, but this is what we have. The main drawback is that DNN designed this folder provider with the Amazon S3 storage in mind. It doesn’t pass along any security details to the provider, but instead wishes to handle that itself. Plus: it copies the file’s meta data in its own tables. This is naturally quite handy when you think of the S3 use case as you wouldn’t want the framework to contact your S3 account every time someone requested a folder’s content list. But DMX’s content is very dynamic and it implements its own security based on the DNN platform. So this poses somewhat of a problem. Basically: if some document is visible to a certain group of users only, there is no way DMX can inform DNN of that fact. DNN will assume it is for anyone. And the caching can lead to a situation where a document is shown in the DNN front-end when it shouldn’t be any longer.
As much as this is a nuisance, the drawbacks do not outweigh the benefits of having the folder provider. Especially now that the CodePlex project’s dead. So DMX 6.1 includes this. The way the folder provider works is through “mappings”. Mappings are translations from a path in the DNN file manager to some remote location (in our case: a path in DMX). We can set up any number of mappings we wish. There is just one caveat: it only works for content that is visible for “All Users”. This way we conform to DNN’s assumption that everything can be shown elsewhere regardless of the user. The mapping maps a folder in DNN to a folder in DMX. We control this through DMX. Under the admin menu you’ll now find “Add to DNN” (also on the control panel) and a help file for this was well on the help menu.
You’ll be able to add the folder on the screen that comes up:
As it is possible to create multiple mappings, you can add subfolders of folders you’ve already mapped. It won’t lead to critical errors, but it could become confusing. The screen lists existing mappings to help you keep them apart. Finally you’ll be able to see your content in the File Manager:
Naturally this means the content will also show up in the HTML editor’s Insert Image/Document panels. You can even upload through DNN’s file manager and have the file appear in DMX now.
New help text component
There are more changes to this version that you may like. One complaint that’s been forward a number of times has been about the default DNN help icons. You find them throughout the framework:
They’re used extensively in DMX as well but in some cases this led to a suboptimal user experience as they have a tendency to show their text when you hover over them and this can obscure other elements. In short: they’re great for what they were designed but not always great in how they turn out in other components. So we offer you the choice to use PageGuide. It’s a small jQuery library that takes a different approach to help texts. Instead of “hover to see help” it shows a button at the top right with the text “Page Guide”:
Clicking this shows the help for all elements clearly marked and a details panel at the bottom explaining each element in turn.
A jQuery blurb emitted with DMX scans the page and turns all DNN help text bits to this mechanism. If this is a success it’ll stay in DMX and maybe other jQuery help text alternatives will be wrapped into the product in the future as well.
New API class
Over the years other products have integrated with DMX. In helping others integrate, the experience is that often used methods are sometimes buried deep in the DMX framework. To help alleviate the searching and the draw attention to some of these methods, there is now a new class right at the root of the DMX namespace. It’s aptly named “API”
The idea is that you’ll find the most common features of DMX in this class. For now there are not a whole lot of functions as we don’t want to bloat this right away. Instead the idea is to grow this as time progresses. Naturally we’ll do all we can to keep these methods stable.
What remains are enhancements and fixes. Here is the list of the most visible/noticeable parts:
Enhancement: Storage provider supports the notion of direct link. This allows a storage provider to provide direct access to a file.
Enhancement: S3 storage provider now supports direct access to files, bypassing the web server. Security is maintained using S3's ability to ask for a temporary key.
Enhancement: New default template based on Bootstrap css framework
Enhancement: New IFilter logic in the Lucene search provider to help with content indexing issues
Enhancement: Added setting to specify sender email address for notifications (DMX-468)
Enhancement: You can now choose how DMX handles permissions upon move: keep old or assume from destination folder
Enhancement: WebDAV cookie timeout now configurable
Enhancement: Revision of how module settings are rendered to improve usability. Settings specific to a UI are now grouped and loaded dynamically.
Enhancement: You can now specify which admin menu you'd like to use just like the main menu (Ajax UI only) (DMX-473)
Enhancement: Ensures Word loads document in front of browser when opening through WebDAV
Enhancement: Root Pattern now supports "group" object for DNN 6.2+ allowing group based folders (see Module Settings help file for details)
Fix: DNN Social groups now also show up in the permission grid.
Fix: Renaming of css sprite classes to prevent clashes with other css frameworks
Fix: Synchronization logic now adapted to cater for long file names
Fix: More defensive coding around logging to prevent module writing to C:\DMX when not in http context (DMX-465)
Fix: Fix in data layer to account for unauthenticated users role (DMX-471)
Fix: Several enhancements in SQL to improve performance and uniformity
Fix: Exception made for permissions maintenance (pruning of deleted users). It now only works on data of portals that are not part of a site group (DNN EE feature)
Fix: Various enhancements to search logic
Fix: New method for storing content in Lucene to fix issue where the stemmers were not storing content correctly. It is now stored both using tokenized analysis and using the Snowball stemmer. (DMX-476)
Fix: Admin VIEW/EDIT/ADD permissions checkboxes now disabled (DMX-464)
Fix: Ensure download method is type default when downloading
Fix: Fix to WebDAV wildcard handler
As usual we urge you to backup your DNN installation before you attempt to upgrade and to roll back if something goes wrong during installation. DNN has no roll-back mechanism for module installs and a failed install/upgrade can leave your DNN in an unworkable state. So please back up. If you do see something wrong, don’t hesitate to email us. If there is an install error, make sure to copy the install log (this is good practice to do during every installation you do, by the way). If you have the option: test the upgrade on a test installation before you do the live one.
The reason I urge all these precautions is that this is a major release, meaning there are some changes to the data model. It is important that these data changes go smoothly. If there are any errors there’s a risk of a mismatch between the dll and the data model. I.e. between the way the dll expects the data model to be and the way it actually is. That usually leads to errors that are very hard to debug if you ignored the install log.
The css sprites have been changed. If you don’t see icons somewhere where you expect them to be, try emptying your browser’s file cache. Also: if it is just the menu: try resetting the menu (button below the main Ajax UI when logged in as admin).
Where to get it
Download the new module through this site or through the DNN Store. Note you need an active license for your upgrade to work. I.e. check the “Service period until” value of your license before installing!