SunBlogNuke - DotNetNuke Blog Module

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

Today we are glad to announce that SunBlogNuke v7.0.5 is available to free upgrade. It looks a long time without any updates from our team, however, don’t worry about this project and we are still paying lots of attentions on developing better software/products for you and it will be never dead :)

As for any new website based DNN framework, the building DNN7 should be recommended, no doubt. So this building focus on more attentions on integrating with DNN7 framework, for example, the separate url provider based "Advanced Url" component of DNN core. More exciting things are lots of handy featured implemented in this package. Seamlessly integration with 3rd party commercial module also taken into account, for example, MyTokens now supported well. Hope win business together :)

Why not have a try? Get started now.

SunBlogNuke Version 7.0.5
Min DotNetNuke version required: v7.1.0

• ENH - supported email templates for subscription feature and now you can configure different email templates for specific blog instance.
• ENH - supported to access more properties of DNN core profile in the theme level, such as FirstName or LastName of blog author like "<%=Entry.AuthorProfile.FirstName%>".
• ENH - supported category image to show in the list of dashboard if exist.
• ENH - supported 'bulk delete' action for entries list of dashboard.
• ENH - meta title/description & header for archives view configurable for better SEO purpose.
• ENH - resolved ugly slug with friendly text/characters, for example, it will automatically transform "some $ugly ###url wit[]h spaces" into "some-ugly-url-with-spaces".
• ENH - integrated with MyTokens module(http://my-tokens.dnnsharp.com/) of DNNSharp corp, including dnn core tokens.
• ENH - totally compatible with DNN7
• ENH - integrated with lots of DNN7 core features, such as friendly url extesnion.
• ENH - supported new search API of DNN7 with implementing "ModuleSearchBase".
• ENH - replaced code editor in theme customization panel with dnn core one - CodeMirror plugin.
• ENH - disabled keywords auto retrieved from tags when empty due to irrelevant keywords - http://sixestate.com/meta-keyword-tags-still-useful/.
• ENH - updated obsolete methods & profile widget.
• ENH - support option to limit page links of pagination control.
• ------------------------------------------------
• FIX - post thumbnail removed after editing post and threw exception when uploading the same thumbnail.
• FIX - blog export url not found 404 when portal built by sub folder format like "http://www.domainname.com/subportal_xx".
• FIX - enclosure url not resolved with absolute path in the RSS feed.
• FIX - Google recaptcha not built by https with DNN secure enable.
• FIX - shortcut ctrl-enter feature of search box not work with DNN7.
• FIX - social icons not pop up properly on hover status with DNN7 style.

As usual, the complete details for all of the changes can be found in the Release Notes.

If you are still using older versions, we recommended that you should upgrade this stable package.

If you are applying upgrade process, please BACK UP YOUR CHANGES BEFORE PROCEEDING and follow up the suggested upgrade path: v2.1->v5.2->v6.0+.

You can get it here. We hope that with this generation dnn blog module you can enjoy the blog writing and it will make your life better; plus if you have any good advice about our products, please feel free to leave a comment or contact us.

The SunBlogNuke Team

As we promised ever, we always maintain the independent branch of SunBlogNuke compatible well with older version of DNN  CMS, such as the DNN4-building.

Today we would like to announce that we have built another compatible package of SunBlogNuke for DNN5.2+.

Even through you are still using the DotNetNuke 5, you don’t have to be worry about it and just feel free to let it there without any update as you like. Surely, the development status is still active; we will include updates with fixes if necessary.

You can get it here. We hope that with this generation dnn blog module  you can enjoy the blog writing and it will make your life better; plus if you have any good advice about our products, please feel free to leave a comment or contact us.

Note:

1) If your dnn website is DNN5.2 above, you should ignore this package and get more latest package.

2) We may charge $25/hour for premium support of these compatible buildings or some additional feature requests.

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

BTW,  if you would like to upgrade it with latest package in your DNN5/DNN6/DNN7+ website, the recommended upgrade path will be changed as follows:

v2.x/v3.x/v4.x –> v5.2 –> v6.2 or the latest package

And if you are troubleshooting with upgrade, please take a look at these tutorials below:

Common problems with SunBlogNuke

Known issues related with upgrade

As you know, the simple method GetTab(int tabid) was obsolete and has been replaced by GetTab(ByVal TabId As Integer, ByVal PortalId As Integer, ByVal ignoreCache As Boolean). If you want to call the new method, we have to pass the additional parameter “PortalId”.

In common,  the object PortalSettings can be easy to get with DNN context, such as special dnn module & page; however, it may be inaccessible in some sceneries, such as separate aspx page or handler. Then is there any way to get the correct tab info with this new method? Now there is a simple trick to do it with passing into Null.NullInteger as the parameter PortalId. So the coding looks like that:

var tabController = new TabController();
var blogPage = tabController.GetTab(tabID, Null.NullInteger, false);

Deeping into the source code, you will find out that it always tries to get the correct PortalId for this tab/page object:

//if we do not know the PortalId then try to find it in the Portals Dictionary using the TabId
portalId = GetPortalId(tabId, portalId);

//if we have the PortalId then try to get the TabInfo object
tab = GetTabsByPortal(portalId).WithTabId(tabId) ??
        GetTabsByPortal(GetPortalId(tabId, Null.NullInteger)).WithTabId(tabId);

Hope this trick & tip helps if someone has the same issue.

Recently we are building a totally new branch of #DNN #Blog #Module – SunBlogNuke based on DNN 7.1 core framework. As you know, DNN7 indeed introduced lots of awesome features, including advanced url rewrite solution. There are more topic about DNN7, however, we just share some interesting things about new class "ModuleSearchBase".

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);

If you are a customized DNN developer, in common you way utilize the built-in module settings with inheriting the base class "ModuleSettingsBase".  You should be careful with your use of the two types of settings that can be associated with an instance of a custom module - there are Module settings and Tab-Module settings. As Chris Cant shared in his post [DNN module and tab-module settings]:

The Module settings are associated with all instances of a module on several pages, while the Tab-Modulesettings are only associated with one instance (on a single page).

 

When you copy a module instance to a new page with Add Existing Module, only the Module settings are available on the new page. So, if you want settings to be available after a module has been copied, then use Module settings, not Tab-Module settings.

 

When a module's content is exported using Export Content, the module controller is called with the ModuleId only (i.e. without the TabModuleId). This only provides easy access to the Module settings.

So when you are developing your DNN modules, the specific requirements will decide what you want to utilize. Now I would like to share some sample coding about how to migration DNN module settings based these discussed above. Yep, at first your module controller must implement IPortable interface of DNN framework and then you must implement two methods "public string ExportModule(int moduleID)" and "public void ImportModule(int moduleID, string content, string version, int userId)":

The coding to export your module settings:

var objModuleController = new ModuleController();
var objSettings = objModuleController.GetModuleSettings(moduleID);
var settingsElem = new XElement("settings");
foreach (var key in objSettings.Keys)
{
    var item = new XElement("setting");
    var keyElem = new XElement("key", key);
    var valueElem = new XElement("value", objSettings[key].ToString());
    item.Add(keyElem);
    item.Add(valueElem);

    settingsElem.Add(item);
}

XElement root = new XElement("Root");
root.Add(settingsElem);

return root.ToString();

The coding to import external module settings:

XElement xSettings = xRoot.Element("settings");
var objModuleController = new ModuleController();
foreach (var xField in xSettings.Elements())
{
    objModuleController.UpdateModuleSetting(moduleID, xField.Element("key").Value, xField.Element("value").Value);
}

If you have better solution or any question please feel free to share with us in the comments.

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

After the acquisition of Active Modules by DNN (formerly DotNetNuke) Corp, the position of original Forum module had been replaced by the Active Forums Module and the status of development looks stopping currently. No any updates or activity – in my opinion, it will be dead in the end later. Unfortunately, some our websites are still building by DNN Forum Module and we don’t want to switch it to Active Forums Module because its features are enough for us and changing will be a potential risk with time or more works.

Actually it may be a great opportunity to get started a totally new/customized project for DNN Forum. We just want to make it live always and are able to add new features or enhance some pending issues. Well, let us get ahead. We will launch the customized forum project in GitHub(DNN Core Framework had been moved to GitHub, as share in this post DNN Nightly Builds) and it will be Open Source Project always there.

Highlights in the initially building:

• Added new theme called "FlatBlue" and made it as default theme.
• Removed multiple post view and only thread detail view without paging.
• Supported quick reply with Markdown format,
• Clean UI/coding optimization, such as removing unnecessary table/tr/td tags.
• Supported relative time to make it look friendly.
• Fixed avatar issue when current user without any specific profile avatar - never upload it.
• Fixed issue where meta description with line or whitespace.

You can take a look at how it action here – Forum Community for SunBlogNuke.

All right, if you want to have any thoughts about this topics, such as advices about this behavior, sponsor us with buying coffee for us, please feel free to let us know. Thanks a lot.

What is DNN Forum Project?

DotNetNuke® Forum is a full featured module used for managing forums and email notification of posts on your DNN site.

DotNetNuke® Forum in CodePlex

Ever Official website of DotNetNuke Forum Project

Yesterday I encountered one strange behavior on DNN 6.2.9 -   DNN Mega menu dropdown is only visible to work when I login with admin/host account but the registered users doesn't see it. In the first looks, it should be caused by some jQuery plugin not registered correctly. After investigation a while, we found that the jQuery hoverIntent is the problem and we have to manually register it in our skin in default. Some code snippets below looks helpful:

 <script runat="server">
    protected override void OnInit(EventArgs e)
    {
      DotNetNuke.Framework.jQuery.RequestRegistration();
      
      if(!Request.IsAuthenticated)
      {
         var scriptPath = ResolveUrl("~/Resources/Shared/Scripts/jquery/jquery.hoverIntent.min.js");
         //for mega menu we need to register hoverIntent plugin, but avoid duplicate registrations 
         Page.ClientScript.RegisterClientScriptInclude("hoverintent", scriptPath); 
      }
      
      base.OnInit(e);
    }
 </script>

However, there is an elegant workaround to fix this issue – the core jQuery skin object is your better choice. 

<%@ Register TagPrefix="dnn" TagName="JQUERY" Src="~/Admin/Skins/jQuery.ascx" %>
<dnn:JQUERY ID="dnnjQuery" jQueryHoverIntent="true" runat="server" />

The following properties for the skin object can be set to True/False (False by default):

• DnnjQueryPlugins - If true, the dnn plugins used for panels and tabs will be loaded in addition to jQuery and jQueryUI.
• jQueryHoverIntent - If true, the HoverIntent script used for tooltips will be loaded in addition to jQuery.
• jQueryUI - If true, jQueryUI will be loaded in addition to jQuery.

Resources links:

Reusable DotNetNuke jQuery Plugins

http://www.dnnsoftware.com/wiki/Page/jQuery