Today the swedish language pack for the DotNetNuke Blog Module Version 4.X was upload to my website.

Thanks for that Ann Kapborg (http://www.wrenda.se)

You can download the file with the following link:

http://www.schelian.com/Modules/Blog/Languages/Swedish/tabid/542/Default.aspx

Hope that helps some people

First a short resume for all the people don't want read the whole article.

Even with DotNetNuke 6.0 it is not possible to create fully functional multi language portals.

My hope was, never must write an article like this, but the team around DotNetNuke did not make it in the past 9 years to implement multi language support, so that it is really possible to build multi language portals.

I had the hope, that with the big change from VB to C# the DNN team will finally take care of that problem.
Unfortunately, my hopes were not fulfilled.

Not now, not with DNN 6.0 and not with that concept of multilanguage implementation.

Let me explain in a very short manner the multi language concept of DotNetNuke .

• Concept Start
  • All pages with all included modules and content will duplicated for all installed and activated languages.
• Concept End

OK, this is really the very short version, but as I said, I will only describe the simple principle, and that's the base idea.

A major advantage of this basic concept has at least:

Existing modules (most of them) could be used without changes for portals with multi language support.

The implementation and operation are so confusing as I have not seen any other code in DotNetNuke. Starting with the activation of content localization, which is a one way.

If you have clicked one time the link button "Enable Content Localization" there is no way back, without a backup or with a lot of difficult changes and corrections in the database. I guess only a few people (me included) are able to make these changes. (A little advertising is allowed)

In addition, the handling of these features is not intuitive so that the training effort would be longer as the training effort for all other feature including the portal administration.

To make matters worse, the following points are still unresolved with this concept:

• Host Lists
• Permission Settings (Roles)
• Taxonomy
• Search
• ….

As you can hear Shaun Walker and Co. are convinced of their concept. Even when people who know a lot more about the needs of a multi language implementation like him and his team, exposed the weaknesses and told Shaun Walker and his team what is wrong.

But it's not really a surprise, I know that already since  2003/2004 again and again different people talk to Shaun and his team about the urgent need of multi language feature. In some cases those people were also involved in the core development, but as far as we can see, those people did not have the necessary influence.

I remember that already 2003/2004 a first (German) multi language version was available. Some International people have done a lot of work to adopt the work of Shaun Walker and his team to give some additional feature to DotNetNuke. But as far as I remember, this work and the people who have done this work did not find the grace of Shaun and his team.
And ... that was the first chapter and the first chance to get more international with DNN in an very early stadium.

It has been around for years, developers who works on multi language support for DotNetNuke.
But why, these people and their concepts, are not highly involved with the necessary multilingualism in DotNetNuke.

If the localization of static elements in ASP.NET application are not so simple and not already defined by the .NET framework, then we would, I believe, at least, today still waiting for using DotNetNuke for a not English website.

At least, not without creating a unique piece of code that no longer would be upgradable.

Of course there are third party solutions for multilingual portals with DNN, but I find none of these solutions work 100%.
And a theme like multi language support should be a theme of the core product and not of third party products.

If I must build today a multilanguage portal for a customer, then I do not use DNN, or if DNN is a must be (due to use existing modules), then I take a child portal solution (for each language a separate child portal), which is incidentally very close to the "new" concept of version 6.0.

But with this solution, at least the taxonomy and search problems are solved

On a DNN Portal which is running DotNetNuke Version 5.6.2, from one moment to the other, the filemanager no longer work properly.

The problem looks like this:

The treeview of the folder control seems to be in a endless loop and the treeview does not open the folder structure.

In some cases, an error message like 

"Runtime error in Microsoft JScript: Sys.ArgumentException: Cannot deserialize empty string. Parameter name: data"

Will be displayed in other cases there is no error message.

But the problem seems to be in any case the same reason.

If you have this problem check the Compression Setting which you can find in the "Performance Seetings" section in the the host setting.

If the GZip Compression is selected, you must change the setting to "no compression"

Save the change, and try the file manager, I'm pretty sure, it works 

Hope that helps.

As far as I know,  the problem is already for a long time in the various different versions of DNN included.

So if you have this problem in an older version, check the setting and look what happens.

A few days ago I have tried to install and compile DotNetNuke Source Version 5.6.2 on a computer with the following requirements.

Windows 7 Computer

Visual Studio 2010 SP1

IIS Express (7.5)

DotNetNuke Version 5.6.2 Source Version (this version)

After installing and setup this version on the computer I tried to compile the solution.

The compile process ends in showing the following error.

Error BC30456: “Framework” is not a Member of “DotNetNuke.UI.Skins.Controls.DotNetNuke”

After a quick search with google, I couldn't find a solution.

So, I have searched a solution by myself.

And here is the solution I have found

You must change the Page.Init Event of the file Query.ascx.vb which is located in the sub folder admin\skins.

The original code looks like this:

Protected Sub Page_Init(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Init
	DotNetNuke.Framework.jQuery.RequestRegistration()
End Sub

And following is the changed code

Protected Sub Page_Init(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Init
	Global.DotNetNuke.Framework.jQuery.RequestRegistration()
End Sub

A while after I have had found this solution, I found another post which provide exactly the same solution.

I will not miss to reference to that post, which contain the same solution.

Compilation error in dnn 5.6.2

In the preliminary final part of my little series "Clean Code of my DotNetNuke modules", we are talking about a whole class, which is marked as obsolete under DNN 6.0.

The class FolderController is marked as obsolete and should be replaced by the class FolderManager.

However, the new class FolderManager does not have replacements for all methods from the old class FolderController.

In one of my modules, I use the following code, to determine the absolute path from a virtual path on a server.

FolderController folderController = new FolderController();
string mappedTargetModuleFolder = folderController.GetMappedDirectory(portalFolder);

In the new class FolderManager the search for an replacement is without success.

But there is a solution.

In the namespace DotNetNuke.Common.Utilities is a class named PathUtils. And this class contains a method called MapPath, and that's it. These method is exactly what we need.

Following is the code how it works with the new method

string mappedTargetModuleFolder = PathUtils.Instance.MapPath(portalFolder);
;

Hope that helps

The topic of the today article is:

How can I replace the obsolete method GetModuleDefinitionByName() from the Namespace DotNetNuke.Entities.Modules.Definitions.ModuleDefinitionController

This is the next article in the series: "clean and robust source code of my DotNetnuke modules"

The usage of this method was never ever easy, because you could not directly use the friendly name, to identify the ModuleDefD of a module.

To determine the ModuleDef ID of a module you must always do that in two steps, with two different controller classes.

• ModuleDefinitionController
• DesktopModuleController

But both methods are already marked as obsolete since DNN version 5.0.

The usage until version 5.0 looks like the following code example.

ModuleDefinitionController moduleDefinitionController = new ModuleDefinitionController();

int newModulDefId = moduleDefinitionController.GetModuleDefinitionByName(
desktopModuleController.GetDesktopModuleByName(
"DNNPortal-Download").DesktopModuleID,
"DNNPortal-Download").ModuleDefID;

The code example following, demonstrates the new usage under DNN Version 5.0 and higher

int newModulDefId = ModuleDefinitionController.GetModuleDefinitionByFriendlyName(
"DNNPortal-Download").ModuleDefID;

Today we talking about the replacement for the obsolete method HasEditPermissions().

Since DotNetNuke version 5.0 the method HasEditPermissions() from the  namespace DotNetNuke.Security.PortalSecurity is marked as obsolete.

The method is used to determine whether a user has edit access to a module or not.

Up to DNN version 5.0 the method HasEditPermissions() has been used as follows:

if (PortalSecurity.HasEditPermissions(ModuleId, TabId))

Now the methode is marked as obsolete the method should be replaced with the follwing code:

if(ModulePermissionController.HasModuleAccess(
   SecurityAccessLevel.Edit, 
   "EDIT", 
   this.ModuleConfiguration))

More coming soon..

On my current way to clean and robust source code of my own DotNetnuke modules, l will report in the next days more in detail about the single steps of migration.

Lets start with the replacement of the obsolete method GetHostSettings() from the Namespace DotNetNuke.Entities.Portals.PortalSettings.

Here is a code excerpt from a DNN module, which was used in  DotNetNuke version 5.0.

The code is used to identify the allowed extensions in a portal.

string fileExtensions = 
DotNetNuke.Entities.Portals.PortalSettings.GetHostSettings()
["FileExtensions"].ToString().ToLower();

For the obsolete method, are now these two following options are possible:

string fileExtensions = 
HostController.Instance.GetSettingsDictionary()
["FileExtensions"].ToString().ToLower();

or this one

string fileExtensions = 
HostController.Instance.GetString(
"FileExtensions").ToLower();.

I prefer the second one.

To bee continued....

Now that the third CTP version of DotNetNuke 6.0 is available, it is time to have a closer look at the source code

But first: Congratulation to DotNetNuke

For the decision to migrate the project from VB to C#.

This is definitely a contemporary and forward looking decision.

And also congratulations for the good implementation of the C # migration.

After download and decompress the source version, it succeeds on the first attempt to load and build the solution in Visual Studio.

That was not always so in the past!!

However, I am more than a little bit disappointed, that with the migration to C#, the use of a design guideline like StyleCop, is not yet implemented.

In any case, are those rules not clearly to recognize

Too bad also the missing or very sparse commented source code .

Now, DNN is a C# project (my favorite programming language), again I will have an watchful eye on it.

My own DotNetNuke modules will be revised in the near future so that they will be work under the new version.

You can find more information about the next version while following the link below:

DotNetNuke Beta Information on www.dotNetNuke.com

Click here for a german version of this article

6 Years ago I have written the last article on my old english weblog,

In the last years I have only written in my native language (German) weblog  (http://blog.schelian.de).

A long time of absence, but now it is the time to come back with an weblog for my English friends and follower

I will publish most of my article, from now on both in German and English.

What do you can expect:

• News about Me and the IT World
• News about .NET Development in general
• News about DotNetNuke
• News about my DotNetNuke Module Development
• News about my Open Source DNN Modules
• and much more...

So far so good, let's restart