Empty the DNN Site Log

An excessively large SiteLog table is likely to have an impact on the performance of your website. Do you know how many entries there are and whether the older ones are being cleaned out?

I have found that the DNN Site log table can be prone to growing, unrestricted.

This can be brought about by the failure to set a day limit and not enabling the scheduled clean up task.

In the past I have found values in the site log which precede the given cut-off date. Often as a result of the number of days being reduced, but the SiteLog purge not running properly.

Maybe looking through the scheduled task notifications you are seeing messages which show the purge of the site log is failing.

Failure of the scheduled task to run is often a sign of a table which has grown too large and is timing out on the deletion.

Information about the site log table SiteLog can be gained via the admin SQL Console.

Empty the DNN site log: count number of rows

SQL is entered within the main text area and run by clicking on Run Script.

Take care! It is easy for an entered command to wipe table contents, beyond the intended results.

The size of the table, ie. the numbers of rows in the table, can be determined by running the command:

SELECT count(*) FROM SiteLog

It’s also possible to see if there are entries earlier than your set limits.

This can be done by running the command

SELECT TOP 10 * FROM SiteLog ORDER BY DateTime DESC

Shown below a typical set of results, based upon a newly enabled sitelog, with the number of columns abbreviated for clarity.

DateTimeReferrerUrlUserAgent
21/03/2018 12:32:00http://localhost/Admin/Site-Settingshttp://localhost/Default.aspx?TabId=67&language=en-GBMozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
21/03/2018 12:32:00http://localhost/http://localhost/Default.aspx?TabId=56&language=en-GBMozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36
21/03/2018 12:33:00http://localhost/Admin/Site-Settingshttp://localhost/Default.aspx?TabId=67&language=en-GBMozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
21/03/2018 12:33:00http://localhost/Admin/Log-Viewerhttp://localhost/Default.aspx?TabId=21&portalid=0&language=en-GBMozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
21/03/2018 12:33:00http://localhost/http://localhost/Default.aspx?TabId=56&language=en-GBMozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36

If there are entries preceding the cut-off date these may be deleted using

DELETE FROM SiteLog WHERE DateTime < given date

Dates are awkward to deal with. By default entries are stored in American date format. It is also anticipated that dates used will also be in this format too. Rather than adding formatting information when running these commands you may wish to simply accept the default format.

To ensure that you are going to delete the correct items try a selection first, based upon your date range

SELECT * FROM SiteLog WHERE DateTime < CONVERT(DATETIME, ’03/21/2018′)

From my example above I am expecting this to return no results, which is the case.

Whilst setting the date as 22/03/2018 gives:

DateTimeReferrerUrlUserAgent
21/03/2018 12:32:00http://localhost/Admin/Site-Settingshttp://localhost/Default.aspx?TabId=67&language=en-GBMozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
21/03/2018 12:32:00http://localhost/http://localhost/Default.aspx?TabId=56&language=en-GBMozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36
21/03/2018 12:33:00http://localhost/Admin/Site-Settingshttp://localhost/Default.aspx?TabId=67&language=en-GBMozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
21/03/2018 12:33:00http://localhost/Admin/Log-Viewerhttp://localhost/Default.aspx?TabId=21&portalid=0&language=en-GBMozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
21/03/2018 12:33:00http://localhost/http://localhost/Default.aspx?TabId=56&language=en-GBMozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36

You may also wish to sort by the datetime field descending, just to get the newer entries

SELECT TOP 20 * FROM SiteLog WHERE DateTime < CONVERT(DATETIME, ’03/21/2018′) ORDER BY DateTime DESC

It’s possible with too many entries in the SiteLog that the deletion of a range of rows will timeout.

You may wish to purge the SiteLog table. I have found that doing this via the DNN SQL control console can lead to time outs and failure to action.

If the truncation of the table times out or fails then you may find that it’s Better to perform the action via the SQL Server Management Studio, if this is available to you .

I navigate to the required database table view and click on the New Query button.

Enter the following

TRUNCATE TABLE SiteLog

Refresh your table view to see the change in the number of records.

DotNetNuke can require a restart of the application to reflect changes made to the database.

With DNN 9 the site log has been removed. Although it can be added back in if you wish.

Reviewing an older site I observed that the site log still existed.

Without the original admin configuration, it’s not possible to empty the log table by following the older practices to restrict the number of days or to turn off the site log.

I chose to use the SQL truncation detailed above to empty the site log table.

References

A Site Log module: https://github.com/DNNCommunity/Dnn.SiteLog

DNN Browser Compatibility

Older versions of DotNetNuke supported the configuration of the browser compatibility of a website through the file

/js/ClientAPICaps.config

The operation of the default DotNetNuke SolPart menu with regard to different browsers is governed by this file.

The file is divided into a number of sections, for example:

<functionality nm="DHTML" desc="Dynamic HTML">
  <supports>
    <browser nm="IE" minversion="4" />
    <browser nm="FireFox" minversion="1" />
    <browser nm="Netscape" minversion="5" />
    <browser nm="Gecko" minversion="1" />
    <browser nm="Opera" minversion="7" />
    <browser contains="Iceweasel" />
    <browser contains="Konqueror" />
    <browser contains="Safari" />
    <browser contains="Camino" />
  </supports>
  <excludes>
  </excludes>
</functionality>

In the example given above I have added support for the Konqueror and Iceweasel browsers.

I created an HTML file with the following content to get the details of the browser.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
  <title>Untitled Page</title>
</head>
<body>
  <script>alert(navigator.userAgent.toLowerCase());</script>
</body>
</html>

I experimented with the browser compatibility options. As mentioned above, adding references for support of lesser used browsers. But found that realistically it added an additional complication to preparing a website. And with websites continually evolving it was going to be an overhead to maintaining websites. After my experimentation I no longer edited the browser configuration, leaving the file as is.

Whilst writing and updating the content of this article I was curious to see whether the file was still included, and if so what it contained. Looking at the latest version on GitHub I found that its content was similar:

<?xml version="1.0" encoding="utf-8" ?>
<capabilities xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <functionality nm="DHTML" desc="Dynamic HTML">
    <supports>
      <browser nm="IE" minversion="4" />
      <browser nm="FireFox" minversion="1" />
      <browser nm="Netscape" minversion="5" />
      <browser nm="Gecko" minversion="1" />
      <browser nm="Opera" minversion="7" />
      <browser nm="Mozilla" minversion="1" />
      <browser contains="Konqueror" />
      <browser contains="Safari" />
      <browser contains="Camino" />
      <browser contains="Mozilla" />
    </supports>
    <excludes>
    </excludes>
  </functionality>

Not much has changed with the start of this file over the years.

DNN 9 Where’s the Allowable File Extensions?

Is the Allowable File Extensions in DNN 9 missing or simply hidden?

The good news is that it’s still available.

The Allowable File Extensions is a list of those file types configured by their file extension which are permitted to be uploaded to the website.

It’s given as a comma separated list within the site’s admin configuration.

Previously it was to be found under the Host > Site Settings page.

DNN 9 Wheres the allowable file extensions? old config option

Looking under the site configuration in DNN 9 I was unable to see the Allowable File Extensions configuration textbox.

It’s still there, but now moved under the Security option.

Begin by selecting the Security menu from the options on the left black panel

DNN 9 Wheres the allowable file extensions? Select security menu

On the security menu select the more tab at the right hand end. Opening this section.

DNN 9 Wheres the allowable file extensions? Security menu

On this tab we have the options for SSL Settings and still More Security Settings. This is the one which we are interested in. Click on it.

DNN 9 Wheres the allowable file extensions? More security settings

Finally we have the page which we are interested in, More Security Settings.

DNN 9 Wheres the allowable file extensions? Security menu more tab

Scroll down the page to the last textbox which shows a list of the different file types which are supported. Add or remove to suit your website requirements.

The Allowable File Extensions isn’t lost/missing. It has been moved under the Security menu section.

The Remote Certificate is Invalid

Configuring the SMTP settings on a DotNetNuke website gave the error, remote certificate is invalid, from the mail server:

There has been an error trying to send the test email. The error is:
The remote certificate is invalid according to the validation procedure

I often find that errors on a DotNetNuke website are logged with further information in the Event Log. To view this navigate to Admin/Event Viewer, from the top navigation bar.

Dependant upon how many messages are created on your website, for example users logging in, the error message which you are looking for may be on the second or third page. If necessary take a note of the time and force the error again, to get it on the first page.

In the Event Viewer log the gist of the error message was:

There has been an error trying to send the test email. The error is:
The message was not delivered to the following address(es) –

I found error relay not permitted.

Where the SMTP host settings for the DotNetNuke installation is configured to use a defined mailbox if choosing to use a secure connection the domain name of the certificate and mail account needs to be the same domain as that configured in the settings.

The error may be resolved by either using a mailbox with the correct domain certificate. or by using an unsecured mailbox and unticking the SSL option.

Increase the DotNetNuke Maximum File Upload Size

I find the default limit on file upload size in DotNetNuke can be too restrictive.

The default DNN upload file size is 8Mb.

The setting is within the web.config file in the root of the DNN website file installation.

Look for the section <system.web>.

    <!-- allow large file uploads -->
    <httpRuntime useFullyQualifiedRedirectUrl="true" maxRequestLength="8192" requestLengthDiskThreshold="8192" />

Increase the value of the maxRequestLength parameter to clear the file size which is an issue. Doubling to 16M may be sufficient.

    <!-- allow large file uploads -->
    <httpRuntime shutdownTimeout="120" executionTimeout="900" useFullyQualifiedRedirectUrl="true" maxRequestLength="16284" requestLengthDiskThreshold="16384" requestValidationMode="2.0" requestPathInvalidCharacters="&lt;,&gt;,*,%,:,\,?" fcnMode="Single" />
    <httpCookies httpOnlyCookies="true" requireSSL="false" domain="" />

To edit the file download a copy from the server via FTP using Filezilla. The file can then be edited with a text editor such as notepad.

For simplicity of editing with colour discrimination of tags and parameters you may find one of the HTML editors useful. Must admit if it’s a one off then whatever editor is to hand is the best option.

At the time you are downloading this one configuration file why not take a backup of the whole website?

With an increased file size capability it will take longer to upload the files to your website. You may also wish to increase this time out.

If you are experiencing file upload restrictions on images then maybe you should reconsider the size or quality of the image which you are uploading. Larger, slow to load images, can have a detrimental effect on your website, visitors maybe become impatient leaving slow to load pages and it is considered a black mark on your SEO score.

References

http://www.dnnsoftware.com/wiki/working-with-large-files