Overview

Almost every DNN user installs a third-party module onto their environment at some point to implement a feature that would otherwise be an out-of-the-box implementation. This implementation extends the capabilities of a standard Evoq installation. Identifying whether the issue is originating from a third-party module from the start can massively reduce the investigation time.

Prerequisites

• Basic knowledge of DNN modules

Solution

What are the clear indicators that reveal that a module is a third-party module?

• One of the easiest ways to find out if the issue is due to a third-party module is to read the ticket. Usually, in the initial response, the customer will explicitly either let you know that they are currently having issues with a third-party module, or they will name the specific third-party module.

  E.g.,

  We have installed the EasyDNNNews module on our website, but currently, we are not able to set up the module on a new page. Every time we finish the setup and save the changes, all the modules disappear from the page, and none of the changes are saved.

  • The above example indicates that the customer is referencing the EasyDNNNews module, which is a third-party module.

• Unfortunately, not all tickets are this simple. If a customer is having issues with a particular module, there should be an error message in the logs.
  An excellent first step is to browse through the DNN log files and look for the specific stack trace that is generated when the customer reproduces the issue.

• You can see that in the below stack trace, the application fails on Bring2mind. When you search for Bring2mind on the internet, you will find out that they are a third-party DNN module vendor.
  
  

  2019-03-06 08:50:28,430 [MO-PRTWEB01P][Thread:289][ERROR] DotNetNuke.Services.Exceptions.Exceptions -DotNetNuke.Services.FileSystem.FolderProviderException: The underlying system threw an exception. ---> System.NullReferenceException: Object reference not set to an instance of an object. at Bring2mind.DNN.Modules.DMX.Integration.FolderProvider.DMXFolderProvider.GetEntry (IFileInfo file) at Bring2mind.DNN.Modules.DMX.Integration.FolderProvider.DMXFolderProvider.GetFileUrl (IFileInfo file) at DotNetNuke.Services.FleSystem.FileManager.GetUrl(IFileInfo file) --- End of inner exception stack trace --- at DotNetNuke.Services.FleSystem.FileManager.GetUrl(IFileInfo file) at DotNetNuke.Professional.SearchCrawler.Results.FileResultController.GetDocUrl(SearchResult searchResult)

   

• The class could also be named after the company name, which would be their own in-house module.

• If the errors only have DotNetNuke classes, it is a clear indication that this is a default core DNN module.

Back to top

What do we do if an issue is related to a third-party module?

Once we have identified that the issue is third-party related, you will need to reach out to the vendor or the developer who has developed the module. This is because the vendor that originally developed this module would have a thorough knowledge of why a particular error would be generated.

DNN Support is only trained on the core modules that we packaged in the default installations. We will however at least attempt to help to the best of our abilities but supporting third-party modules fully on our end would be assumptions and guesswork at best. 

Back to top