Learn MS .NET

Keeping with their promise to release often, we have a new beta version that was released today.  The new beta can be downloaded from CodePlex.

The following bugs have been fixed in this new release

(5.1.0.364) Beta 3

DNN-9853
Admin / Host Functions
Bug
Checked-In
Complete

Summary:   Binary Compatability issue for repository

DNN-9871
Admin / Host Functions
Bug
Checked-In
Complete

Summary:   Audit info when creating new pages

DNN-9661
Admin / Host Functions
Bug
Checked-In
Complete

Summary:   Errors in user registration form (profile properties)

DNN-9892
Admin / Host Functions
Bug
Checked-In
Complete

Summary:   Enable disable host menu

DNN-9898
Installation / Upgrade
Bug
Checked-In
Complete

Summary:   upgrade from 493 to 5.1.0.266

DNN-9899
File Manager
Bug
Checked-In
Complete

Summary:   Admin cannot add/delete folders or files, etc. in Admin-->File Manager

DNN-9904
Core Modules
Bug
Checked-In
Complete

Summary:   Repository is broken after after upgrading TestBed_493_3 with 5.1.0.266

DNN-9908
Skinning
Bug
Checked-In
Complete

Summary:   Skin ControlPanel breaking change

DNN-9905
Admin / Host Functions
Bug
Checked-In
Complete

Summary:   Some Admin/ Host Controls are missing after upgrading TestBed_493_3 with 5.1.0.266

DNN-9903
Installation / Upgrade
Bug
Checked-In
Complete

Summary:   Languages broken after upgrading TestBed_493_3 with 5.1.0.266

DNN-9895
Admin / Host Functions
Bug
Checked-In
Complete

Summary:   Adding Module to Another Page

DNN-9897
UI / Usability
Bug
Checked-In
Complete

Summary:   No longer shows page hierarchy when adding existing module

DNN-9856
Admin / Host Functions
Bug
Checked-In
Complete

Summary:   Upgrade from 5.0.1 - Console

DNN-9918
Admin / Host Functions
Bug
Checked-In
Complete

Summary:   Exception when emptying recycle bin

DNN-9916
Admin / Host Functions
Bug
Checked-In
Complete

Summary:   Menu doesn't refresh after restoring a page

DNN-9930
Admin / Host Functions
Bug
Checked-In
Complete

Summary:   Error on Language rename

DNN-9890
Admin / Host Functions
Bug
Checked-In
Complete

Summary:   changes to tabs need to audit tab and tabpermission changes

DNN-9952
General
Bug
Checked-In
Complete

Summary:   Module Settings: Move module to page results in a copy instead.

DNN-9964
File Manager
Bug
Checked-In
Complete

Summary:   Permissions Grid Does Not Correctly Display Permissions

DNN-9965
UI / Usability
New Feature
Checked-In
Complete

Summary:   Display version info for "Beta" builds

DNN-9967
Admin / Host Functions
Bug
Checked-In
Complete

Summary:   user view shows all users

DNN-9936
Admin / Host Functions
Bug
Checked-In
Complete

Summary:   Sitemap priority defaults to 0

DNN-9925
Admin / Host Functions
Bug
Checked-In
Complete

Summary:   Fallback Skin Doctype changes not reflected in UI on load / postbacks

DNN-9912
Security
Bug
Checked-In
Complete

Summary:   5.1.0 - Possible Breaking Change FileSystemUtils.SetFolderPermissions

DNN-9946
Admin / Host Functions
Bug
Checked-In
Complete

Summary:   Behaviour Change for Inline Editing

DNN-9254
Performance
Bug
Checked-In
Complete

Summary:   "PageState Persistence" set to "Memory" kills AJAX modules

DNN-9568
Security
Bug
Checked-In
Complete

Summary:   Permission issues

DNN-9654
Search
Bug
Checked-In
Complete

Summary:   Search Input module: no search text

DNN-9950
Localization / ML
Bug
Checked-In
Complete

Summary:   Incorrect icon for button

DNN-9928
Control Panel
Bug
Checked-In
Complete

Summary:   User with page edit permission can see admin & host console links

DNN-9953
Admin / Host Functions
Bug
Checked-In
Complete

Summary:   Missing Default Language options => Broken Site Settings

DNN-9948
Admin / Host Functions
Bug
Checked-In
Complete

Summary:   Control Panel Visibility Selection not Saved properly

DNN-9971
Admin / Host Functions
New Feature
Checked-In
Complete

Summary:   Add Skin Event Handling

There is a new release expected at any time to cure the issue that developed today that involves not allowing the install to complete if .NET 3.5 is not installed on the system.

After installing the latest 5.1.0 beta of DotNetNuke that was released this week, I noticed a new icon and a couple of links in the Control Panel when I logged in as the host of the new install.

As always in my endeavors with this platform my curiosity got the best of me and I had to see where these two links took me. I assumed that it would be to something that only an admin or host would need access to.  I was pleasantly surprised to see the result on clicking on the admin link.

It brought me to a page in my new DNN install that had a link to each of the pages under my admin menu. As well as when I placed my mouse over any of the items in the Admin Console, a tooltip is displayed telling me about the link and what I can find by following it. 

Also on the console there are two drop down boxes one is to select the size of the icons for use on the page. As well as another one to choose whether to display the contents of the page in simple view or detailed view.  Detailed view basically takes the tooltip contents and places it on the page instead of the popup window.

I also noticed that this console module was placed on the Admin page of the menu and the host console was placed on the Host page of the menu.  In previous versions of DNN these two menu choices were not enabled so we couldn’t navigate to them in the menu structure.  I think this will be a great tool for new administrators and people unfamiliar with how DNN works.

But there are more goodies in this module.  I also checked to see if this module had any settings that could be adjusted. I found that there are a number of different settings in the module settings.

The settings of the module are as follows:

• Show children of: allows us to set this module on any page and then show the children of a different page then the one we are currently on.  If no page is selected then it shows the children pages of the current page the module resides on.
• Default icon size: this can be set to 16px or 32px for displaying the icons in the module.
• Allow icon resize: if this checkbox is checked then the user can select the size of the icons they want to use in the module themselves in the drop down box.
• Default view: this can be set to simple or detailed view for displaying the items in the console module.
• Allow view change: if this checkbox is checked then the user can select the type of view that they want to see in the module themselves.
• Show tooltip: checking this checkbox determines whether or not we will see the jQuery tooltip when we hover over a choice in the module.

If a user makes changes to the console module as to how they want to view that page such as large icons or detailed view, these changes get saved and the next time the user comes back they will be presented with the same view that they previously had.  This is a nice feature and allows each user to customize how they want to interact with the module.  Also the module checks permissions to determine what pages a user has access to.

After looking at the module and the code that it generates, it is nice to see that they code outputs xhtml and doesn’t make use of tables anywhere in the output. So it provides a good example of how modules should be written to take care of the over exuberant use of html tables in module development.

I have some uses that I can picture for the use of this module going forward in the future in some of my development.  Most of which would be a similar use as to how the core framework uses it, but would be incorporated into my modules.

Guess I’ll go back to exploring this new release see if I can find some more new features to let everyone in on.

One of the big complaints that I have seen over the years with DotNetNuke has been the horrible URL’s that get produced by the framework.  This is a problem that is part of most dynamically created content on the web, not only DotNetNuke.

For the successful Content Management Systems, they have come up with ways to make these ugly URL’s more human friendly.  DNN did this back in about version 3.0 with the introduction of Friendly URL’s.  This allowed us to get rid of the dreaded querystring for SEO purposes.  So we went from URL’s that looked like http://domain.com/Default.aspx?tabid=39 to http://domain.com/Home/tabid/36/Default.aspx.

This was great for getting better rankings with the pages in the search engines but doesn’t give us that URL that is easy to remember in human terms.  This is the default setup that has made it’s way into the DotNetNuke eco-system, and has given us this common complaint about DotNetNuke sites in general.

There is a solution to this that anyone who is looking to make their site distinctive and remove that stigma about it being a DNN site can use.  It is available within the core framework itself we just need to make some changes to the configuration of the web application.

So lets look at the default configuration in the web.config file for the Friendly URL provider:

   1: <friendlyUrl defaultProvider="DNNFriendlyUrl">

   2:   <providers>

   3:     <clear />

   4:     <add name="DNNFriendlyUrl" 

   5:         type="DotNetNuke.Services.Url.FriendlyUrl.DNNFriendlyUrlProvider, DotNetNuke.HttpModules" 

   6:         includePageName="true" 

   7:         regexMatch="[^a-zA-Z0-9 _-]" />

   8:   </providers>

   9: </friendlyUrl>

As you can see it only has a couple of options defined by default in the config file when you first install DNN which are the following:

1. includePageName: this is set to true by default and determines if we have the name of the page included in our URL when we are in searchfriendly mode of the provider.
2. regexMatch: I'm not a regex expert by any means.  But the default match allows the inclusion of all upper and lower characters as well as ll numbers, spaces, underscores and dashes.  If I’m wrong someone let me know in the comments would you.

This is what gives us those ugly URL’s everyone complains about. 

Now when we venture into the Core Framework code for the FriendlyUrl Provider, we have a few more options that aren’t shown in the web.config and can really give us some nicer URL’s to work with on our DNN site.

FriendlyURL Provider Options

1. includePageName: this was explained above.
2. regexMatch: this was explained above
3. fileExtension: by default the file extension on DNN is .aspx. I played around with this option and also looked at the code and although it is defined and being pulled into the provider in the code. I don’t see where this is actually doing anything in provider.
4. urlFormat: this is the real treasure in the provider we have two URL formats that we can use here the default of searchfriendly or humanfriendly. If we do not include it in the web.config then by default it is searchfriendly but if we add this and change it to humanfriendly then we have much nicer URL’s to work within the framework.

So lets change it in our web.config file to be humanfriendly:

   1: <friendlyUrl defaultProvider="DNNFriendlyUrl">

   2:   <providers>

   3:     <clear />

   4:     <add name="DNNFriendlyUrl" 

   5:         type="DotNetNuke.Services.Url.FriendlyUrl.DNNFriendlyUrlProvider, DotNetNuke.HttpModules" 

   6:         includePageName="false" 

   7:         regexMatch="[^a-zA-Z0-9 _-]" 

   8:         fileExtension=".aspx" 

   9:         urlFormat="humanfriendly" />

  10:   </providers>

  11: </friendlyUrl>

Once we do this and save our web.config file. We can go refresh our site, and now should have URLs that look like the following: http://domain.com/home.aspx or http://domain.com/admin.aspx.  It also makes it easier for allowing direct logins without placing a link on the page for logging in because in this format our login page becomes http://domain.com/login.aspx.

I hope that people find this information useful although what we have in DNN is just a basic URL provider there are other providers out there in the DNN community.  When I have time I will try to add some of them to this post or provider another post with a list of them out there.

I received an interesting comment today about my blog.  It was really appreciative of a feature that is included within the blogging engine. Which is the “You Searched For” user control.  This takes the search query that is sent along from the search engine and matches it to a search within the local site when the referrer comes from a search engine.

What especially made me take notice is that the comment came from a member of the DotNetNuke Blog Module team. With a request to understand how this was achieved within my site.  Well I figured I could have just sent back a quick and dumb answer of it is just part of the blogging engine I use.  Which in my case is BlogEngine.NET.  Or I could do what I am doing now and go into to detail about how the blogging engine accomplishes this, which is what was really being looked for.

With that in mind I will walk through how it is accomplished as I think this would be a great control to be a part of the DotNetNuke core Blog Module as well as a module that could be used to allow people to get more search results when they land on a DNN site.  May have to build that.

There are two parts to this to make it work successfully.  The first part is the addition of the user control to skin theme for my blog site.

  1: <blog:SearchOnSearch ID="SearchOnSearch1" 
  2:     runat="server" MaxResults="5" 
  3:     Headline="You searched for"
  4:     Text="Here are some results for the 
  5:     search term on this website" />

The second part is the code that is behind this user control.  First of we have a few properties that can be configured on the control

Properties:

1. MaxResults: This is the maximum number of results to return to the page if there are any found.
2. Headline: This is the headline to display for the control when it returns search items found.
3. Text: This is the text to be displayed below the headline and above the search results.

Class Implementation:

  1: 
  2:  public class SearchOnSearch : Control
  3:  {
  4:      private static Regex _rxSearchTerm = null;
  5:  
  6:      static SearchOnSearch()
  7:      {
  8:  	// Matches the query string parameter "q" and 
  9:         // its value.  Does not match if "q" is blank.
 10:  	_rxSearchTerm = new Regex("[?&]q=([^&#]+)", 
 11:              RegexOptions.Compiled | 
 12:              RegexOptions.IgnoreCase | 
 13:              RegexOptions.CultureInvariant);
 14:      }
 15:  
 16:      public override void RenderControl(
 17:           HtmlTextWriter writer)
 18:      {
 19:   	string html = Html();
 20:   	if (html != null)
 21:   	    writer.Write(html);
 22:      }
 23: 
 24:     /// <summary>
 25:     /// Checks the referrer to see if it qualifies as a search.
 26:     /// </summary>
 27:     private string Html()
 28:     {
 29:         if (Context.Request.UrlReferrer != null 
 30:             && !Context.Request.UrlReferrer.ToString().Contains(
 31:             Utils.AbsoluteWebRoot.ToString()) && IsSearch)
 32:         {
 33: 	    string referrer = HttpContext.Current.Request.UrlReferrer.ToString().ToLowerInvariant();
 34: 	    string searchTerm = GetSearchTerm(referrer);
 35: 	    List<IPublishable> items = Search.Hits(searchTerm, false);
 36:             if (items.Count == 0)
 37:                 return null;
 38:             return WriteHtml(items, searchTerm);
 39: 	}
 40: 
 41: 	return null;
 42:     }
 43: 
 44:     /// <summary>
 45:     /// Writes the search results as HTML.
 46:     /// </summary>
 47:     private string WriteHtml(List<IPublishable> items, 
 48:         string searchTerm)
 49:     {
 50: 	int results = MaxResults < items.Count ? MaxResults : items.Count;
 51: 	StringBuilder sb = new StringBuilder();
 52: 	sb.Append("<div id=\"searchonsearch\">");
 53: 	sb.AppendFormat("<h3>{0} '{1}'</h3>", Headline, HttpUtility.HtmlEncode(HttpUtility.UrlDecode(searchTerm)));
 54: 	sb.AppendFormat("<p>{0}</p>", Text);
 55: 	sb.Append("<ol>");
 56: 
 57: 	for (int i = 0; i < results; i++)
 58: 	{
 59: 		sb.AppendFormat("<li><a href=\"{0}\">{1}</a></li>", items[i].RelativeLink, items[i].Title);
 60: 	}
 61: 
 62: 	sb.Append("</ol>");
 63: 	sb.Append("</div>");
 64: 
 65: 	return sb.ToString();
 66:     }
 67: 
 68:     /// <summary>
 69:     /// Retrieves the search term from the specified referrer string.
 70:     /// </summary>
 71:     private string GetSearchTerm(string referrer)
 72:     {
 73: 	string term = string.Empty;
 74: 	Match match = _rxSearchTerm.Match(referrer);
 75: 	if (match.Success)
 76: 	{
 77: 		term = match.Groups[1].Value;
 78: 	}
 79: 
 80: 	return term.Replace("+", " ");
 81:     }
 82: 
 83:     /// <summary>
 84:     /// Checks the referrer to see if it is from a search engine.
 85:     /// </summary>
 86:     private bool IsSearch
 87:     {
 88: 	get
 89: 	{
 90: 		string referrer = HttpContext.Current.Request.UrlReferrer.ToString().ToLowerInvariant();
 91: 		return _rxSearchTerm.IsMatch(referrer);

 93:     }
 94:  }

As we can see from the class it checks to see if there is a query “q” attached to the referring url to see if this comes from a search engine. If it does then we want to search the site and see if we have any posts that we can display to the user.

This is really neat and helpful for users.

For anyone that is not located in the Florida Area or who like me live in the vast wasteland and can’t get to these type of events, Will Strohl has provided online viewing today through his the Orlando DotNetNuke User Group site.

This link below provides a list to the sessions for the day.

The Mighty Blog - The personal web site for Will Strohl - 2009 Florida Code Camps Coming - Back to Back

This link provides access to viewing of the tracks as they are presented.

http://orlando.dotnetnukeug.net/ODUGLive.aspx

Well it appears as if the anticipated update to fix issues with 4.9.1 is slowing making it’s way down the line to us.  It was apparently upgraded at the main DotNetNuke site and is now being tested probably at it’s heaviest for now.  Lets hope no major issues are found and hopefully we will also see that long awaited update for 5.0.0 to 5.0.1 as well.

More information can be found by following the link below from Scott Willhite:

Dogfooding DNN 4.09.02 - DotNetNuke Site Updates & Changes - DotNetNuke

For anyone having trouble trying to find an SDK that they know Microsoft ships have a look at the following it may provide and answer for you in your search.

Microsoft SDKs

BlogEngine.NET has released a theme pack that is compatible with the version 1.4 and 1.4.5. 

The theme pack contains themes designed and created by the community, and they have been brought together as a downloadable theme pack.  Janko has compiled them together for the community to use.

Download the BlogEngine.NET theme pack here.

Clint Edmonson has released a some free C# and VB.NET Coding standards guides to the community to use.  For anyone who wants to download them they can be downloaded below

C# & VB.NET Coding Standards Guides

Having worked with DotNetNuke since Version 1.0 and before I have seen many changes within the framework.  One of the changes that I liked but found it to be repetitive was when working with the registration tools, we had this field called Display Name that was always asking for input in the form.

This image shows the display name as a required field.  I understand the need for this as we want to display a user’s preferred name to them when they login, but it is also nice being able to set this to our own predetermined fields as well. Well this can be done within the framework, with the added bonus that the display name will now not be part of the registration process. 

To accomplish this, lets walk through the process.

Remove the display Name

1. Login to the portal as an administrator
2. Go to Admin –> User Accounts
3. Click on User Settings either at the bottom of the module or in the drop down menu for the module.
4. Locate the Display Name Format field near the bottom of the user settings
   
5. Place the following within the textbox [FIRSTNAME] [LASTNAME]. This will set the display name to the first and last name of the user that is registering.
6. Click the update button at the bottom of the module.
7. Log out of the portal as administrator and then click on the registration link. The Display Name field should now not be visible in your registration form.
   

This makes for a consistent naming scheme for wherever the Display Name field is used within your portal as well as allowing the field not to be required during registration when having new users register.

If you have any comments or other suggestions about tips you would like to see about DotNetNuke please leave them in the comments below.