SunBlogNuke - DotNetNuke Blog Module

Well, let us get started to fight DNN Bugs again. This is the forth post we discussed about DNN bugs and share workarounds with you. The last posts as follows below:

1. Fighting DNN Bugs: All Handlers Not Work
2. Fighting DNN Bugs Ⅱ: Why Can't Remove Google Analytics
3. Fighting DNN Bugs Ⅲ: Why Non-Administration Users Logged Out

which you also are interested in reading.

Today we would like to share the bug is about spammer, mainly about spammer registrations/login attempts. When looking/monitoring Admin -> Event Viewer, there are a ton of event log recorded off type "Login failure" or "New user", then your website should have been hit by an old robot-script written specifically to target DNN website.

Recently we would like to make some big things based on #DNN8 - a better platform for DNN. Still our website only hosted by DNN7.1 upgraded in the last year. Now we chosen more security upgrade dnn7.1 -> dnn7.4 -> dnn8+. Now we firstly upgrade our official website sunblognuke.com with #DNN7.4.

Some new areas introduced in 7.4.0.

• Workflow & Versioning API
• Multi-language settings
• Improved HTML5 support

Issues & Workaround

Fighting DNN Bugs Ⅱ: Why Can't Remove Google Analytics

Some resources related with DNN7.4:

Introducing DNN Platform 7.4

DNN-7-4-DEVELOPER-QUICK-START

Today I just got a very annoying error with one DNN7 fresh installation in Windows 7 x64 machine. Which is;

Compiler Error Message: CS0016: Could not write to output file 'c:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\DNN7\62d43c41\27d749ca\xx_xxx.dll' – 'Access denied.'

Here is solution which I have found. What you have to do is just assign the following folders with IIS_IUSRS and NETWORK SERVICE users with the full control permission:

1) C:\Windows\temp

2) c:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files

Once you applied those setting, restart your IIS and try to run your application again. The error should be gone by now.

Hope that this post will help you to fix the problem as I did and if you have found any other fix's please leave feedback and I will post them up.

----------------------------------------------------------

Resources links:

Local IIS 7.0 - CS0016: Could not write to output file / Microsoft.Net > Framework > v4.0.30319 > Temporary ASP.NET Files

“CS0016: Could not write to output file” error when starting an app in IIS 7

Currently we are fixing a really weird issue that only happens with non-administration users.

When the user logs in and accesses one page, they are logged out of the system. The page finishes loading as if they were logged in, but once they try any other actions, such as clicking any module section menu (including refreshing the browser page) they are considered not logged in and presented with a login prompt.

After looking it into for a while, we found that this always seems to happen when this module requests my custom ashx web call, which was killing dnn authentication cookies and logging out non-administrator users. Later we made some search about reasonable solution – fortunately we found the helpful post exactly with the same issue -  Why is DNN killing my authentication cookies when I access an ashx from a child portal?

As the answer mentioned below:

This occurs because the user is only defined in the child portal, but the request to the ASHX occurs (from DNN's perspective) in the parent portal. When DNN receives the request, it sees that you've "switched portals," no longer have a valid identity, and removes your authentication information. This doesn't occur for super users because they do have a valid identity across both portals.

To fix this issue, you need to add a querystring parameter to your request with the portal ID. This let's DNN disambiguate the request and keep your authentication intact.

For example, the coding of our case will be modified as follow:

var path = PortalSettings.HomeDirectory + objFile.Folder + objFile.FileName;
var resizedUrl = string.Format("~/desktopmodules/my_module_name/imagehandler.ashx?portalid={0}&path={1}", 
                                PortalSettings.PortalId, path);

return ResolveUrl(resizedUrl);

Well, let us get started to fight DNN Bugs again. This is the second post we discussed about DNN bugs and share workarounds with you. The first post is Fighting DNN Bugs: All Handlers Not Work, which you also are interested in reading.

It is so tired and uninteresting process but we we have to deal with them for our websites or clients if they requested. DotNetNuke is indeed the most excellent/great CMS at the first look but when going ahead, there are lots of issues/bugs to challenge your ability and patience. One of our client ever complained that there were lots of error filled in the event logs of their websites, and mainly indicated that "Object reference not set to an instance of an object". You look, so little information is not enough to investigate those issues and identify the problem that we can do nothing excerpt clearing the event logs to make us feel happy for a while. Yes, the community version is free however that is the big price when issues occurred. Some times we can look for helps in the silent forum but most times we have to fix them ourselves.

More frustrating things are that some bugs exists cross two major versions,  such as DNN6-DNN7 and still not fixed now even though they are created into issue tracker.  Well, if they are ignored with the official guys, let us check them out and address some workaround to fix them forever or temporarily.

Today we would like to share the bug is about Google Analytics Tracking. From DNN v6.0, the core package included the built-in module for Google Analytics Tracking. It looks indeed an awesome thing for us because we don’t have to trick these coding in the skin from the scratch. However, sarcastically one day we would like to disable the Google Analytics with some reasons, DNN only said NO WAY :(

How to reproduce this bug:

1. Go to Admin/Google Analytics page.
2. Fill in any value into the tracking ID field
3. Click to update and make it active. Everything looks nice :)
4. Again when I filled the empty value for tracking ID and hope that it should be inactive, the simple form just said that the field is required and can’t be empty. 
5. Try to update, failure, update, failure… Nothing can’t be done any more and Google Analytics tracking coding always showed in every page.

How to fix it

Currently there seem to be some workarounds as follows:

1) Go to your site's root folder and find the siteanalytics.config file, COMMENT OUT or DELETE everything inside the CDATA tag.

2) Analytics settings are stored in file GoogleAnalytics.config, residing in portal root directory, such as portals/x/subdir(x is the portal id). Deleting the file will erase your settings.

3) Go to the folder $ROOT/DesktopModules/Admin/Analytics and find the GoogleAnalyticsSettings.ascx file. COMMENT OUT or DELETE the RequiredFieldValidator.

The 3) way is the one what I recommend and will fix all the issues – you don’t have to check out all the portals but the disadvantage is to be overwritten in the next upgrade. As the point of DNN module developer, it is meaningless to make this tracking id mandatory.

If you have any question or thoughts about this topic, please feel free share it in the comment. Thanks.

Resources links discussed the same issue above:

Can't Remove Google Analytics Tracking

Removing Google Analytics from your DNN site

Other issues addressed about DNN7 you may interested in:

After upgrading to DNN 7.1.2 Site Settings doesn't work

After upgrading to DNN 7.1 OpenSearch and DNN Preview Search doesn't work

Change the Space character in Advanced URLs with DNN 7.1

As you know, currently DNN is growing bigger than what you expected and the latest version is 7.2 building with lots of awesome features. However, in my opinion, we encountered more and more problems in the same time – tons of versions with tons of existing bugs to be fixed. More frustrating things are that some bugs exists cross DNN4-DNN7 and still not fixed now even though they are created into issue tracker.  Well, if they are ignored with the official guys, let us check them out and address some workaround to fix them forever or temporarily. Today we get started to build a series of posts and share how we fighting DNN bugs these years :(