DotNetNuke them!

Displaying User Profile photos in other places (with a little help)

noreply@blogger.com (Gyromyristis) — Mon, 30 Sep 2013 12:56:00 +0000

Today I ran into a problem I didn't imagine still existed (in DNN v.7.2). I was using Ventrian Property Agent and I needed to display the profile photo of the user who made the submission inside the module's View Item template. I was surprised that neither Property Agent supported that, nor was there another way to get the user's profile image at a decent size inside the module's templates.

I'm sure that even if you aren't using this specific module, you've also ran into this issue one way or another. There is no decent built-in way to display a user's profile image outside of the user profile page itself.

In my case, there is a token Ventrian Property Agent users named [USERID] that provides the id of the user who has created the current entry. With only this in hand, I had to find a way to use it to get a decent profile picture.

First option would be to use the standard DNN /profilepic.ashx image handler, but this one returns distorted, grainy images of max 64x64 pixels. Using it like this: <img src="/profilepic.ashx?userid=[USERID]"> would give me a crappy image, but at least an image.

Two minutes before I was ready to give up, I ran into this gem: http://bbimagehandler.codeplex.com/ - this is a generic image handler that does a lot of things - resizing, watermarks, etc. but one interesting feature is that it can render DNN user profile images - in any dimension given, and with awesome quality compared to DNN's own profilepic.ashx.

Give it a try if you're facing the same problem. Have in mind that in order for DNN Profile Pictures to work, you'll HAVE to specify the "db" parameter as mentioned in the documentation. By specifying this parameter, it is implied that you have already updated your web.config file with this key:

<add key ="BBDatabase" value="Connectionstring=SiteSqlServer;table=MyImages;ImageField=ImageData;idField=ImageID" />

The trick is that you only need the first part if you only need BBImageHandler to handle profile images, since it already knows what tables and fields to use. So you can use this version:

<add key ="BBDatabase" value ="Connectionstring=SiteSqlServer;" />

Where "SiteSqlServer" is your connection string's name (in case you have renamed it from the default name DNN gives it).

This way, it is only enough to know the user id whose profile image you need to show - In my case, as I said above, I had the [USERID] token, so my code was as follows:

<img src="/bbimagehandler.ashx?db=BBDatabase&userid=[USERID]&portalid=0&width=300">

And voila! A profile image with a 300px width inside a Property Agent Template! (I'm thinking of even using it inside the user profile page itself).

Until next time!

Customizing DNN 7 Search and Search Results

noreply@blogger.com (Gyromyristis) — Wed, 04 Sep 2013 14:45:00 +0000

DNN 7 has introduced a new, Lucene-powered indexing and search results retrieval mechanism. This means that all techniques you knew are not in effect any more. No more SQL queries and/or tables, data get returned in JSON format and rendered via Javascript. For more details, please read this post on DNNSofware.com

This adds a whole lot of new functionality but also a lot of limitations in the way Search Results are presented. Actually, there never was a straightforward way to customize Search Results, but until now you could just edit SearchResults.ascx and its corresponding code-behind file and have your desired result.

Things are still ugly regarding customization. The default Search Results layout includes a link guiding you to advanced search concepts, an "Advanced" form that asks you to provide various information such as where you want to search (categorized by module type) and so forth.

This doesn't always make sense to end users, and some elements have to be removed in specific scenarios. Users don't always want advanced search options, nor do they need to know what type of modules your site contains. In some cases they don't give a damn about the author, or the last modified date too. But there's no immediate way to configure what will be displayed and what will be not.

Moreover, until now you could face the problem of default module titles (which users usually leave as is because they are using containers that didn't include the module title) by tweaking the way module titles were inserted in the SearchItem table (see this older post for more). Since no SQL tables are used any more, you're left with ugly "Text/HTML" and other default titles in Search Results. The JSON returned for each search result item just contains a title that is often made of a concatenation of the tab's name and the module's title (or, in the case of grouped results, just the module's title).

Moreover, having a module with a BLANK title is no longer an option since modules with blank titles are not indexed(!). For more info, see my question here: http://www.dnnsoftware.com/answers/cid/420779

So le't see how we can address all of the above with some modifications on specific files. Be warned that what I'm saying here applies to version 7.1 and may or may not be in effect for future DNN versions, as well as that those changes are not upgrade-proof, meaning that if you upgrade your site to a higher DNN version you may lose them. But, it's better than nothing. :)

Be sure to get a backup of all the files you are going to modify in case something goes wrong!

Let's start.

Hiding the "advanced" link

File: dnn.SearchResult.js

Location: DesktopModules\Admin\SearchResults

Go to line 343, you will see a call to the DnnSearchBox like the following

      dnn.searchResult.searchInput = $('#dnnSearchResult_dnnSearchBox').dnnSearchBox({
           id: 'dnnSearchResult_dnnSearchBox',
           filterText: dnn.searchResult.defaultSettings.advancedText,
           showAdvanced: true,
           advancedId: 'dnnSearchResultAdvancedForm',
...

Locate this line:

showAdvanced: true,

And change it to

showAdvanced: false,

This is an option that you can't access via the module settings and it hides the "advanced" link. Unfortunately, the form that would pop up will still be visible at the bottom of the page so you have to take an extra step:

File: SearchResults.ascx

Location: DesktopModules\Admin\SearchResults

Go to around line 55 and you'll see a DIV element surrounding the elements of the Advanced form, like the following:

<div id="dnnSearchResultAdvancedForm" class="dnnForm">
    <div class="dnnFormItem">
        <dnn:Label ID="lblAdvancedTags" runat="server" ResourceKey="lblAdvancedTags" />
        <input type="text" id="advancedTagsCtrl" />
    </div>
    <div class="dnnFormItem">

^...

Add a style="display:none;" attribute to the outer div to hide the whole form.

If you need the advanced form but do not need to show specific controls, you can just skip the steps above, go at this point and just add a style="display:none;" attribute to any of the DIVs nested inside to hide the specific control you don't need (e.g. Scope)

Hide Advanced Tips link

File: dnn.SearchResult.js

Location: DesktopModules\Admin\SearchResults

Go to line 359 (it's empty), just above this piece of code:

$('a.dnnSearchResultAdvancedTip').on('click', function () {
            $('#dnnSearchResult-advancedTipContainer').slideToggle('fast');
            return false;
        });

And insert the following line:

$('a.dnnSearchResultAdvancedTip').hide();

Alternatively, you can achieve the same result by adding a style="display:none;" attribute at the A tag in SearchResults.ascx, line 6:

<a href="javascript:void(0)" class="dnnSearchResultAdvancedTip"><%= LinkAdvancedTipText %></a>

Hide Results by Page / Sort section

File: SearchResults.ascx

Location: DesktopModules\Admin\SearchResults

Go to line 13 and add a style="display:none;" attribute to the outer DIV element there (first element in code snippet below):

<div class="dnnSearchResultPanel">
    <div class="dnnRight">
        <ul class="dnnSearchResultSortOptions">
            <li class="active"><a href="#byRelevance"><%= RelevanceText %></a></li>
            <li><a href="#byDate"><%= DateText %></a></li>...

If you hide this section but you need to specify a different sort order and/or results per page setting, you can alter the Javascript call at the same file, line 116 onwards, by altering the sortOption and pageSize initial values:

$(function () {
        if(typeof dnn != 'undefined' && dnn.searchResult){
            dnn.searchResult.moduleId = <%= ModuleId %>;
            dnn.searchResult.queryOptions = {
                searchTerm: '<%= SearchTerm %>',
                sortOption: 0,
                pageIndex: 1,
                pageSize: 15
            };

sortOption can be 0 for date, 1 for relevance.

pageSize can be anything you need.

Hide various elements on Search Results

Well, some people don't like the "last updated" information. Others don't like the "author" info. So let's see how we get rid of anything we don't need:

File: dnn.SearchResult.js

Location: DesktopModules\Admin\SearchResults

Start from about line 112,where you'll see code like this:

markup += '<div class="dnnSearchResultItem-Others">';
        markup += '<span>' + dnn.searchResult.defaultSettings.lastModifiedText + ' </span>';
        markup += data.DisplayModifiedTime;
        markup += '</div>';

        markup += '<div class="dnnSearchResultItem-Others">';
        markup += '<span>' + dnn.searchResult.defaultSettings.sourceText + ' </span>';

Comment lines 112 to 115 to get rid of the "last updated" text

Comment lines 117 to 119 to get rid of the "source" text and link

Comment lines 121 to 123 to get rid of author info

Comment lines 126 to 135 to get rid of 'tags" info

Hide default HTML module titles (if any)

As mentioned earlier, you may not want module titles to appear in search results, but they do, even if your container doesn't display the module's title. The most common is "Text/HTML" and we'll see how to get rid of it in Search Results.

File: dnn.SearchResult.js

Location: DesktopModules\Admin\SearchResults

Scroll down to the bottom of the file and append this function at the end:

function fixTitle (s) {

    if (s=='Text/HTML') {
        return ('...');
    }

    var s1;
    var s2;

    s1=s.substring(0,s.indexOf('>')-1);
    s2=s.substring(s.indexOf('>')+2, s.length);

    if (s2=='Text/HTML' || s2==s1) {
        return (s1);
    }
    else
    {
        return (s);
    }
}

This function accepts a search result item title and first checks if the title is "Text/HTML". If so, it returns three dots ("...") instead. You will find this in grouped results, where the module title is displayed on its own.

If the title does not belong to a group subset, it'll be in the format "xxx > yyy" where xxx is the page's name and yyy is the module's title. The code breaks the string in its two parts and checks if the second part is equal to "Text/HTML". If so, it returns only the first part (the page's name). Also, if both parts are the same it once more returns the first part. Useful when a module has the same title as the page and you don't want to see this in search results.

This is not the best possible solution, but it's a decent workaround, provided that you don't have the character ">" anywhere in your module titles or page names. I know it can get better, but this is only to demonstrate how you can do it.

In order to put our function into effect, we have to go to line 107:

markup += '<a href="' + data.DocumentUrl + '"' + dnn.searchResult.defaultSettings.linkTarget + '>' + data.Title + '</a></div>';

and replace data.Title with fixTitle(data.Title):

markup += '<a href="' + data.DocumentUrl + '"' + dnn.searchResult.defaultSettings.linkTarget + '>' + fixTitle(data.Title) + '</a></div>';

Hide subsets (grouped results)

If, for some reason, you don't want to have any grouped results then you can comment out the code that is generating them. Be adviced that the result that was supposed to be grouped won't display a description underneath, just the title and link.

File: dnn.SearchResult.js

Location: DesktopModules\Admin\SearchResults

Go to line 159 and comment the code there until line 161:

// render subsets
                   for (var j = 0; j < result.Results.length; j++) {
                       markup += '<div class="dnnSearchResultItem-Subset">' + dnn.searchResult.renderResult(result.Results[j]) + '</div>';
                   }

Finally, if you tamper with the way search results are rendered, you may not want to have auto-search (search-as-you-type) get in your way by rendering everything in a different way (e.g. using default text/html module titles). There is no option for disabling it, but we can always hack the code a little more:

File: SearchSkinObjectPreview.js

Location: Resources\search

Go to line 137 and comment out this piece of code (until line 155):

throttle = setTimeout(function() {
                         var service = $.dnnSF ? $.dnnSF(-1) : null;
                         var url = makeUrl(val, service);
                         if (url) {
                             $.ajax({
                                 url: url,
                                 beforeSend: service ? service.setModuleHeaders : null,
                                 success: function(result) {
                                     if (result)
                                         generatePreviewTemplate(result);
                                 },
                                 error: function() {
                                 },
                                 type: 'GET',
                                 dataType: 'json',
                                 contentType: "application/json"
                             });
                         }
                     }, self.settings.delayTriggerAutoSearch);

This will prevent the Search skin object from auto-searching.

Well, that's all! Even if line numbers change with an upgrade, you have a reference point on what to seek in code. I know this is not the prettiest or the most accurate and bullet-proof solution in the world, but until DNN Corp. decides to add more configuration settings to its Search subsystem, it will have to do. In the meantime, you can vote for my relevant suggestion in Community Voice here:

http://www.dnnsoftware.com/voice/cid/420823

Oh, and please feel free to suggest any other improvements / hacks to Search and Search Results! I know I didn't cover the whole range of possible modifications, but these are, IMHO, the most common ones.

Until next time!

DNN Sharp's My Tokens 30% off (until 7/26/2013)

noreply@blogger.com (Gyromyristis) — Mon, 22 Jul 2013 15:12:00 +0000

DNN Sharp are promoting a discount on their popular My Tokens module that will expire on the 26th of July, 2013. To get the discount, you have to buy their Action Form module from the DNN Store.

Action Form is a form builder module which lets you create complex forms quickly and save data to the database / send emails etc. on submission.

My Tokens is a module which lets you include dynamic content from database or HTTP requests in static content.It works with a number of DNN modules out of the box (including Text/HTML and Form and List) but you can even patch the DNN core (with instructions) to extend support to every installed module.

Buy Action Form here

Buy My Tokens here

25% off all Data Springs products (until 7/23/2013)

noreply@blogger.com (Gyromyristis) — Sat, 20 Jul 2013 12:33:00 +0000

Data Springs is taking 25% off all its products until Tuesday, 7/23/2013. You can order your products from the DNN Store and use the promo code BYEANNIE on checkout to get a 25% discount.

If you don't know Data Springs' modules, you should give it a look - their flagship products are Dynamic Forms, Dynamic Registration and Dynamic Login, and there are more than a dozen more. There is also a bundle named Data Springs Collection for a very low price compared to bying the products one by one.

At last! DNN7.1 has extensionless URLs and a "url name" setting for every page

noreply@blogger.com (Gyromyristis) — Wed, 17 Jul 2013 09:45:00 +0000

This is a big step forward. Starting with DNN v.7.1, you can say goodbye to ugly URLs and .aspx extensions. Following a suggestion made by yours truly (here: http://www.dnnsoftware.com/voice/cid/138237), DNN 7.1 has adopted a "Page URL" field in Page Settings, letting you specify the exact URL the page should use.

This is essentially an URL rewrite for the page, that makes the page's URL independent of the page's name, meaning that you can change the name as many times as you like, without affecting any links that are present in text/html modules or elsewhere.

The only bad thing (or good, depending on your point of view) is that the URL is not automatically synthesized based on page hierarhcy, meaning that you have to specify the exact URL for each page, starting from the virtual root.

For example, in the default DNN installation you have the About Us page which has a URL of "/About-Us" while the sub-page Style Guide has a URL of "/About-Us/StyleGuide". The whole URL for the Style Guide page has to be typed again, i.e. the "/About-Us" part is not inherited from the URL field of the parent page.

This makes things a bit more difficult since you have to remember the URLs of parent pages if you want to represent the hierarchy using friendly URLs, but on the other hand gives you a bit of freedom since you do not need to specify exact paths to get to a page - you can easily give the Style Guide page, for example, a URL of "/YourStyleGuide", forgetting the "About-Us" part at all.

It would be nice to see an "inherit" option in future versions though.

Bug: "Redirect after login" not redirecting to localized versions of page

noreply@blogger.com (Gyromyristis) — Thu, 27 Jun 2013 15:44:00 +0000

I am currently working on DNN7, on a multilingual site (4 languages). The site has public registration and users must be redirected to a specific page after they complete their registration.

I found that DNN would not let me specify a different page for every language - in fact, if I went to Admin -> Site Settings -> User Account Settings -> Login Settings -> Redirect after Registration and selected a specific page in one language, it would give me <None Specified> if I went to the setting using another language.

This would probably have no impact if DNN took care to redirect the user to the localized version of the page after registration - which it doesn't (at least until version 7.0.6). So I had to alter a few things, which I'd like to share with you in case you are facing the same problem.

The problem seems to be on the \DesktopModules\Admin\Security\Register.ascx.cs file, which fortunately can be directly edited so no recompilation is needed. If you go to line 162 there, (the "else" portion of a rather large if statement), you'll see that it does the following:

_RedirectURL =

Globals.NavigateURL(Convert.ToInt32(setting));

Where "setting" is the Tab ID of the tab you have selected on the Site Settings section for redirecting after registration. This, of course, is not localized so it'll always take you the the actual page you have specified - regardless of the actual language the user is using to register.

In order to fix this, I copied and adapted some code from the language skin object (yes, the language picker) which can always find the right localized version of a page. So here's what I did:

I changed the line:

_RedirectURL =

Globals.NavigateURL(Convert.ToInt32(setting));

to:

int currentPortal =

PortalController.GetCurrentPortalSettings().PortalId;

Locale currentLocale =

LocaleController.Instance.GetCurrentLocale (currentPortal);

TabInfo localizedTab =

new TabController().GetTabByCulture(

Convert.ToInt32(setting), currentPortal, currentLocale);

_RedirectURL = Globals.NavigateURL(

Convert.ToInt32(localizedTab.KeyID));

And I also had to add two usings on top of the page:

using DotNetNuke.Entities.Tabs;
using DotNetNuke.Entities.Portals;

With those changes, I managed to have the page to redirect to specified only once and have DNN redirect me to the page's localized version depending on the language I used to register.

Also please see here: http://support.dotnetnuke.com/project/All/2/item/26617 for other issues with Redirect after Login functionality. I applied the change to line 136 of the file mentioned in this issue, too.

One caveat: If you upgrade your DNN installation, you will probably lose those changes.

Also, have in mind that the same thing probably applies to the "Redirect after Login" functionality - I'll probably post something similar about that soon :). Plus, I have also created an SQL-based adaptation of GetTabByCulture to be used with OWS - I hope I have enough time to post this here too.

Standard disclaimer: Keep a backup of your initial Register.ascx.cs file. Don't blame me if this doesn't work for you. This is a solution that worked for my own project and it's not guaranteed to work in every case. Did I mention backup?

Until next time!

Great news on Open Web Studio (OWS)!

noreply@blogger.com (Gyromyristis) — Fri, 14 Jun 2013 10:16:00 +0000

If you are using DNN, I'm sure you have at least heard of Open Web Studio, (OWS), a RAD development platform for DNN that is open source, free, and lets you create things for which you would otherwise need full-blown module development. For example: Database - bound grids, forms, queries and templates to view results, AJAX calls, conditional display of information and much more.

In the past few years, OWS has been stuck to version 2, with frequent updates including updates for working with DNN 7, but no new functionality. Although the community is very active, documentation is still lacking and many people keep asking about the future of OWS, worrying that it may be (or has already been) abandoned.

I had a recent chat with Kevin Schreiner, the lead developer for OWS, and with his permission I'm copying here his thoughts and plans on OWS. If you don't want to read all of it, bottom line is that Kevin is actively supporting OWS and preparing for OWS 3!

Here's what I asked, among other things:

I am curious (just as so many people) to learn news about OWS's future (if such a future exists). I've used it so much I have lost count - and I'm eager to see it evolve. As far as I understand, you're (or were) the only developer maintaining it. Should I keep my hopes up high or go desperate? :)

And here's Kevin's reply:

No worries, I understand the anxiety. I created ListX which became OWS while working for Bi4ce - which became R2integrated, and I'm still the only developer maintaining it. This shouldnt be a cause for concern. I've been holding off on releasing OWS3 due to a myriad of complications revolving around the changes to the DNN platform and adjustments to the core libraries needed for the new UI all while keeping the platform releases for OWS2 still working within the latest DNN versions. The issues with the OWS3 UI stem from the fact that DNN which typically struggles to release ANYTHING on newly released technologies, adopted the latest jQuery version in the DNN7 release. Doing this caused the UI Layout Manager plugin which I was relying on for the OWS3 release to malfunction and I've had to resort to building a new logical structure for handling it. Plus, there have been some issues with the logic in use of the UI because it has been confusing while working within multiple configurations and multiple actions simultaneously. You can see from the original comps how this could be confusing, because when you have more than 1 action opened, you dont know which action is linked to which configuration.

Hopefully something that should make the community rest easily, I rely on OWS for 99.9% of my own livelihood, using it as my core development platform, extending its core functionality and keeping it up to date for the latest DNN releases. Obviously, this being the fact means that OWS isnt going anywhere ;) (...) Once I feel comfortable with the OWS3 release stability, I will most assuredly release it to the general public. It has always been and will always be primary in my focus to release something that is solid and stable as it is so important to all of our runtimes.

In the meantime, rest assured that nothing is going to happen to my baby :) It's a labor of love, and something that I personally rely on.

I am extremely happy with his answer! What about you?

Bug: Custom profile properties cannot be selected for custom registration form (DNN 7)

noreply@blogger.com (Gyromyristis) — Thu, 06 Jun 2013 10:12:00 +0000

DNN 7 allows customization of the registration form via an easy interface, with intellisense. You just select "Custom" for Registration Form Type in Admin - Site Settings - User Account Settings tab and you can add all the fields you like to your registration form.

At the moment of writing, this doesn't seem to work well with custom registration properties (i.e. fields you have created yourself via the "Profile Settings - Add New Profile Property button below on the same tab). If you try to type a custom property's name on the Registration Fields box, it just won't come up (although it's been reported that properties of datatype "Text" do come up).

In order to make these properties available to your registration form until a fix is applied to this, you can use SSMS (provided that you have access and experience using it) and do the following:

Go to your DNN database
Open the "PortalSettings" table for edit and find the record that has the value "Registration_RegistrationFields" in the "SettingName" field
You'll see that the "SettingValue" field is a comma-delimited list containing the field aliases of the properties that are to be displayed on the custom registration form. Add the aliases of your own fields in the list.
Update the table and go to your DNN installation (as the Host user), and click on Tools - Clear Cache
If everything goes well, you'll see that the "Registration Fields" box now contains your properties too, and they will appear normally on the registration form.

Another way to do this is to use the Host - SQL section on your DNN installation. To see the current profile properties that are displayed on the custom registration form, type this into the Script box and click "Run Script":

SELECT
SettingValue
FROM {databaseOwner}{objectQualifier}PortalSettings
WHERE
SettingName = 'Registration_RegistrationFields'

In order to add one or more fields at the end of the list, you must run something like this (where 'MyField' is your custom field's alias). Remember the comma and use no spaces.

UPDATE

{databaseOwner}{objectQualifier}PortalSettings
SET
SettingValue = SettingValue + ',MyField'
WHERE
SettingName = 'Registration_RegistrationFields'

After you run it, go to Tools and click Clear Cache and you will see your fields on the "Registration Fields" box in the Admin - Site Settings - User Account Settings tab.

If you still need more power and customization with your custom registration page, take a look at the Dynamic Registration module from Datasprings - at the moment of writing this, version 5.0 has just been released for DNN 7.x.

Standard disclaimer: When you do stuff like the above on your database, you do it at your own risk, and I have no responsibility should you damage your database, your computer, or the universe. Always have a backup handy! :)

Until next time!

Removing Google Analytics from your DNN site

noreply@blogger.com (Gyromyristis) — Tue, 06 Nov 2012 18:39:00 +0000

It's very easy to add the Google Analytics tracking code to your DotNetNuke site: Just go to Admin - Google Anaytics, enter your tracking ID and the tracking code is automatically generated for every page.

But what if you need to REMOVE the Google Analytics code? DNN doesn't let you replace your tracking ID with nothing in the Google Analytics page (the field is mandatory). So, you either stick with it or put an invalid value (such as "0") and have your site generate a totally invalid and useless tracking code all the time.

What you can do, is go to your site's root folder and find the siteanalytics.config file. That's where the tracking code is. (As of DNN version 6.2.4, this doesn't seem to have changed).

The problem is that if you delete this file it keeps getting regenerated. So the only way to avoid generating analytics is to keep the file but COMMENT OUT or DELETE everything inside the CDATA tag (essentially,the script tag from start to finish). This way, DNN will still see the file is there, but won't generate anything for Google to use.

If, at a later time, you need to restore your Google Analytics tracking code, you can either delete the file (so that it can be auto-generated again) or just uncomment what you commented.

Hope it helps!

Quick hints: How to ensure your site remembers your visitors' credentials so that they don't have to login every time

noreply@blogger.com (Gyromyristis) — Mon, 05 Nov 2012 18:52:00 +0000

If you need to make life easier for your portal's registered users, you may have to make it remember them so that they won't have to retype their credentials next time they visit.

Making "remember me" always checked

By default, DNN's "remember me" checkbox on the login page is visible and unchecked. In order to make it checked by default, you'll have to edit the /DesktopModules/AuthenticationServices/DNN/Logon.ascx file (assuming DNN 6.2 but probably same in earlier versions) and find the following control:

<asp:checkbox id="chkCookie" resourcekey="Remember" runat="server" />

Add a checked="true" attribute to the control as follows:

<asp:checkbox id="chkCookie" resourcekey="Remember" checked="true" runat="server" />

And the checkbox will always be checked by default.

If you upgrade your DNN installation sometime in the future, you'll probably lose this setting, so keep in mind that you may have to edit the file again after an upgrade.

Defining the "remember me" duration

The second thing you should define is for how long a user will be remembered. This is controlled by a key in your web.config file, under the <appSettings> section:

The value expresses duration in minutes. So, if you need your portal to remember your users for, let's say, a month, that's 60*24*30 = 43200. A year would be 60*24*365 = 5252600 and so on.

It's important to set that value, since your "remember me" functionality may not work at all, especially in older DNN versions that are using an ASP.NET 2.0 application pool. For more details, see here and also here.

Ensuring that the "remember me" checkbox is enabled

Finally, if you don't see the "remember login" checkbox at all, it may have been disabled in your DotNetNuke installation. The setting to disable or enable the remember me functionality is under Host Settings - Basic Settings - Host Details - "Enable remember me on login controls" checkbox.

Dealing with ‘Could not load type ‘DotNetNuke.Common.Global’’

noreply@blogger.com (Gyromyristis) — Tue, 22 Nov 2011 10:18:00 +0000

There are a thousand reasons this dreaded message can appear, but what if it appears on a site that you are 100% sure nobody has tampered with in any way other than uploading files for quite some time?

The problem

The error itself is as follows:

Parser Error

Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately.
Parser Error Message: Could not load type 'DotNetNuke.Common.Global'.
Source Error:

Line 1:  <%@ Application Inherits="DotNetNuke.Common.Global" Language="VB" %>

Source File: /global.asax Line: 1

The context

That was exactly the case I faced today when a client called me and reported the error. The client was absolutely sure that no changes had been performed other than uploading some files, both to the application and the server itself (no upgrades, no apppool changes, no iis configuration changes). Just to be safe, I checked the dates of the files in the bin folder as well as the date of the global.asax file and all had not been changed during the past few months.

Possible causes

Searching the Web, I was panicked to see that there were at least a few dozen possible causes of this error. For example, there’s a multi-page thread in the DotNetNuke forums dicussing this error. Sadly, most of the cases regarded upgrades to the core platform, recompiling or other stuff that had been changed.

So what else could be wrong? Well, I once more discovered than when something seems inexplicable, it doesn’t always have to be some extremely complicated technical issue.

Solution

The client had access to the full site root via an FTP client. Upon trying to upload stuff, the client accidentally moved the App_Data folder inside another folder. That was it!

I moved the App_Data folder back to the root and everything was fine again.

What I learned from this incident: Always look for the simplest possible cause of an error first. Hope it helps some of you out there.

What modules I used to develop www.alunet.com (Part 3 – Indoo Grid)

noreply@blogger.com (Gyromyristis) — Fri, 04 Nov 2011 15:29:00 +0000

When it comes to displaying data on a grid, you can either choose to implement your own custom module, utilize a module like Open Web Studio (read about it in Part 2) or, if you really want speed and efficiency, install a copy of Indoo Grid.

This module delivers what it promises: Grids. Fully customizable, sortable and editable, either in-line or via a form. Of course, if you really need advanced form functionality, have a look at Dynamic Forms from Datasprings (read about this module in Part 1).

Every multi-purpose module is powerful in a specific area. Indoo Grid is very powerful in presenting data, and provides acceptable functionality for editing data. It’s ideal, though, for administrative tasks, especially if custom tables are involved. That was the case with alunet.com, so I used it heavily at the site administration pages.

Here you can see how the products administration screen looks like. The links to view and edit pages are constructed fields which lead to a Dynamic Forms page and a public detail page respectively. You can sort columns by clicking on them and you can filter data using the text box and the comboboxes above the grid. The “Category”, “Company” and “Views” columns come from respective joined tables. This is not an SQL view you’re seeing – joins are defined in Indoo Grid’s configuration.

You can instruct Indoo Grid to display records from a table or view, defining things such as searchboxes (you can define separate searchboxes for each column or combine them in a single searchbox, excluding the columns you don’t need to search), records per page selector, initial sorting and sortable columns, editable columns (if you need to edit things) and so on.

You also don’t have to worry about those cryptic referential integrity errors when trying, let’s say, to delete something that is related to another table – you can configure it to display messages that are understandable to the user.

This is the grid for managing categories. Remember, the Categories table is a self-joined table that is presented in the form of a tree inside the web site.

You can also create columns that are lookups in joined tables and even automatically create drop-downs from the values of those columns so that you can filter your grid with them. Additionally, you can create “calculated” fields that may contain one or more column values together with other html markup or scripts you may need (yes, that’s an easy way to include pictures or links to other pages).

One thing that Indoo Grid does that you won’t easily find elsewhere is that it can also handle hierarchical data. In alunet.com’s case, the “categories” table is a self-joined table that contains the entire tree of categories, where each record “knows” the id of its parent record. This was easily managed with Indoo Grid.

Here you see the same grid for Categories management, after navigating to a specific category (castings). What we see now are the children of this category in the tree. You can also see that we have an easy way to add new records right below the grid, that will belong to the “Castings” parent category.

Of coure, you can also use Indoo Grid for your front-end. It’s fully customizable in terms of styling and you can always use it in read-only mode. It’s very fast (authors have a demo with a million records which runs pretty smoothly),and there are some predefined templates and samples on their website, too.

Company website: www.indoolab.com

Buy it from Snowcovered: Click

Click here to read Part 1 (Introduction and Dynamic Forms from Datasprings)

Click here to read Part 2 (Open Web Studio)

Adding paging to the core Announcements module

noreply@blogger.com (Gyromyristis) — Fri, 21 Oct 2011 15:12:00 +0000

The Announcements module (at the time of writing this, the latest version was 4.0.3) is a very simple DNN core module that lets you present a list of titles and descriptions leading to files, other pages, external links or nowhere at all. It’s customizable via templates, but it doesn’t include any form of paging. So if you have like hundreds of announcements to publish, you probably have to use another module.

Not any more, since with a little help from a clever JQuery plugin called Pajinate (download from here), you can add paging to your announcements module. Of course, you’ll be loading all items since Pajinate functions on the client side, but it’s better than not having paging at all.

I used the default template that comes with the Announcements module and added what was needed to implement paging on it. Unfortunately, Pajinate does not hide the pager when there’s only one page nor does it hide the First/Previous and Next/Last buttons when we are at the first and last page respectively, so I had to write my own little chunk of Javascript to handle this correctly.

Additionally, I adapted the default header and footer templates to include IDs and other stuff needed for pajinate to work correctly. Those IDs are used in the additional javascript code I wrote.

So here’s the Javascript code. I suggest you put this code on a separate file (I used pajinatehelper.js) and load it AFTER the pajinate javascript file. You will probably need to change the value of the itemsperpage variable (top of script) to your own preference, as well as the literals for the First/Previous/Next/Last buttons that follow.

//Set the number of items per page
 
var itemsperpage = 10;
$(document).ready(function(){
$('#paging_container').pajinate( {
    item_container_id : '#pagetable',  //This must be left as is
    items_per_page: itemsperpage,    
    nav_label_first: 'First',//Change this to whatever you like
    nav_label_prev: 'Prev',  //Change this to whatever you like    
    nav_label_next: 'Next',  //Change this to whatever you like
    nav_label_last: 'Last'   //Change this to whatever you like
});

//Get the total number of items
var total_items = $('#pagetable').children().size()

//Get the number of pages
var numberofpages = Math.ceil(total_items/itemsperpage);

//Since we start at page 1, hide First/Previous buttons
hideFirstPrev();


//Decide what to hide when user clicks on a page number.
$('#paging_container').find('.page_link').click(function(){

    var currpage = parseInt($(this).attr('longdesc'));
    currpage+=1; //longdesc is 0-based but page numbers start at 1.

    if (currpage==1) {
        hideFirstPrev();
    } 

    else if (currpage==numberofpages) {
        hideNextLast();
    }
    
    else 
    
    {
        showAll();
    }
    
});            

//Hide First and Previous links when the user clicks the First link
$('#paging_container').find('.first_link').click(function(){
        hideFirstPrev();
});            

//Hide Last and Next links when the user clicks on the Last link
$('#paging_container').find('.last_link').click(function(){
        hideNextLast();
});            

//Decide what to hide when the user clicks on the Next or Previous links
$('#paging_container').find('.previous_link,.next_link').click(function(){

    var currpage = parseInt($('#paging_container').find('.active_page').attr('longdesc'));
    currpage+=1; //longdesc is 0-based but page numbers start at 1.

    if (currpage==1) {
            hideFirstPrev();
    }
    else if (currpage==numberofpages) {
            hideNextLast();
    }
    else {
            showAll();
    }

});            


//If we have only one page, disable pager completely.            
if(total_items<itemsperpage){
    $('.page_navigation').hide();
}

});
  
//These are helper functions for hiding / showing First/Last/Next/Previous links
 
 function hideFirstPrev() {
    toggleFirstLastNextPrevControls(1);
 }

 function hideNextLast() {
    toggleFirstLastNextPrevControls(2);
 }

 function showAll() {
    toggleFirstLastNextPrevControls(3);
 }

 function toggleFirstLastNextPrevControls (mode) {

    if (mode==1) {
        $('#paging_container').find('.first_link').hide();
        $('#paging_container').find('.previous_link').hide();
        $('#paging_container').find('.last_link').show();
        $('#paging_container').find('.next_link').show();
    } 
    
    else if (mode==2) 
    {
        $('#paging_container').find('.first_link').show();
        $('#paging_container').find('.previous_link').show();
        $('#paging_container').find('.last_link').hide();
        $('#paging_container').find('.next_link').hide();
    } 
    
    else if (mode==3)
    
    {
        $('#paging_container').find('.first_link').show();
        $('#paging_container').find('.previous_link').show();
        $('#paging_container').find('.last_link').show();
        $('#paging_container').find('.next_link').show();
    }
 }

Here’s the code for the Header Template for the Announcements module:

<link rel="stylesheet" type="text/css" href="/portals/0/scripts/pajinate.css"/>
<script type="text/javascript" src="/portals/0/scripts/jquery.pajinate.js">
</script>
<script type="text/javascript" src="/portals/0/scripts/pajinatehelper.js"></script>

<div id="paging_container" style="text-align:left;">
<table class="DNN_ANN_DesignTable" cellspacing="0" summary="Announcements Design Table" border="0" style="border-collapse:collapse;"><tr><td>
<div id="pagetable">

Please note that I include the stylesheet (pajinate.css), the js file for Pajinate (jquery.pajinate.js – you can use jquery.pajinate.min.js too) and my own .js file (pajinatehelper.js) from my /portals/0/scripts folder (I actually created that “scripts” folder, since it didn’t exist in the default skin’s folder structure). You, of course, can load them from whatever path you like, or you can even inject them in the page’s HEAD section (see this post for more on that).

Pajinate demands that the items to be paged are enclosed inside an element with a specific id (in our case, “paging_container”). You can see the complete documentation here. Unfortunately, this doesn’t work well with tables, so I used an enclosing DIV with this id. Of cource, in your implementation, you can ditch the TABLE alltogether and just use DIVs. I tried to alter the default template as little as possible.

Pajinate also needs a second element that contains elements to be paged. I used this also, as a div with “pagetable” id. Those two are configurable (see the script)

And here’s the code for the footer:

</div>
</td></tr></table>
<div class="page_navigation"></div>
</div>

The “page_navigation” div is once again required by pajinate in order to show the pager.

Phew. When you put all the code in place, and ensure that it’s working correctly, the result will be something like this:

The orange pager comes from the default stylesheet that comes with Pajinate. You can, of course, change it at your will. In this example, I used a page size of 2.

CAUTION: Since errors in Javascript can sometimes render your page useless and even disable the edit controls, please take a bookmark of the module edit page URL before you apply changes, so you can always get back to it in case things go wrong.

Have fun and good luck!

What modules I used to develop www.alunet.com (Part 2 - Open Web Studio)

noreply@blogger.com (Gyromyristis) — Tue, 09 Aug 2011 13:43:00 +0000

Open Web Studio (or OWS in short) is a FREE (yes, free!) module from R2integrated, formerly known as ListX. (There are paid subscription options too, although I'm not quite sure what is offered). At first glance, it looks like a module where you can define an sql query and then create a template to render results - something like a glorified data repeater. But it's a lot more than that. It supports AJAX, paging, variables, it can "talk" to DNN and retrieve things like the tab id, the module id, the locale etc. it can make decisions and branch execution, you can nest modules and have one call another via AJAX, you can do redirections or change page and module titles, you can cache query results and you can even write to files!

Activity lists, product and company lists, product and company details, as well as the users' control panel are rendered via OWS. Additionally, OWS is used in all security checks (such as checking if the user has the right to edit a specific company or product or if the user can add another product). This is achieved via modules that have no front-end but nevertheless run when the page is requested.

Development in OWS is done via a handy tree-like interface where you define things like variables, If - else sections, sql queries, header-detail-alternate detail-footer sections etc.

The site's first page is a good OWS example. The asynchronous effect you will see when you load the first page is because only the main activities are retrieved when the page loads. Subactivities are then queried and rendered via AJAX, and query results are cached for each subactivity (yes, OWS can do named caching on query results so that you don't have to query your database all the time - you can even use fields from your queries to construct names for the cached elements). This is on purpose, since there is a large number of activities and counting products and companies for each one can take some time.

What's more is that you can then have more control over your caching - when a new company or product is submitted, you can clear only the cache that corresponds to the specific main activity it belongs to - leaving all the other query results cached. (No, I haven't done that yet - that's why it's a bit slow :))

Another example would be the company details page, in the future - the site will soon be supporting "packages", i.e. there will be companies that will register for free and companies that will pay. The "free" companies will have fewer details shown than the paying ones. This is very easy to control via OWS.

In fact, I could use OWS to even create the submission forms - but it would be very hard since I would have to do it all by hand - Dynamic Forms is very easier for this type of task. I created the quick search form on the company and product lists with OWS, though. When submitted, it runs a stored procedure which brings the appropriate results - illegal character escaping, injection protection, even parameter type checking and default values assignment are all built-in and easily customizable.

What's the catch? Well, lack of documentation. You've got to turn a lot of knobs and push a lot of buttons to understand what OWS really can do. Fortunately, there's a great community of OWS fans (me included), and this has solved most of my problems.

OWS Pros:

Free!
Very few bugs compared to other solutions
Integrated RAD development environment including debugger
It can talk to any external database (you can define connection strings)
Supports calls to webservices or even external DLLs
Supports caching, ajax, paging, sorting, decisions, variables
Can talk to DNN - actually it can retrieve everything the PortalSettings class offers and some more.
Very portable configurations, provides an option to even create your own PA assemblies, meaning that you can create your own modules using OWS.

OWS Cons:

VERY poor wiki-style documentation (but lots of examples in the community forums)
Internal functions have a syntax that is somewhat hard to read (quotes inside quotes, brackets, curly brackets, parentheses, escaped quotes, you can usually find them all in one line)
Developer must be very proficient in SQL and HTML / Javascript in order to achieve good results (actually IMHO, this is not a bad thing)
Can be painful to debug in very complex scenarios

Company website: www.r2integrated.com

Module website: www.openwebstudio.com

Snowcovered: Click

Click here to read Part 1 (introduction and Dynamic Forms from Datasprings)

What modules I used to develop www.alunet.com (Part 1 - introduction and Dynamic Forms from Datasprings)

noreply@blogger.com (Gyromyristis) — Tue, 09 Aug 2011 13:40:00 +0000

Instead of writing another boring "top 10" list of modules "you must use before you die", I chose to present a site I developed (currently online but in Beta stage). This is a unique opportunity, since I usually don't get permission or don't have enough time to publish details on my work.

The site is www.alunet.com, a global directory related to aluminium companies and products, and has been developed using the following DNN modules:

Dynamic Forms from Datasprings

IndooGrid from IndooLab

Open Web Studio from R2integrated

News Articles from Ventrian

Live Tabs from Mandeeps

Navigation Suite from DNN360.net

SmokeRanch Ad Manager from Smoke Ranch Software

(Please be aware that the design is not mine - the layout and site structure was entirely designed by the client and my job was to implement all the functionality needed).

The site is also heavily using jQuery, Fancybox (a jQuery plugin for displaying images and/or html) as well as ImageGen, an image resizer originally developed for the Umbraco CMS that can function stand-alone in any .NET - based website.

Let's discuss where I used what and why:

Dynamic Forms from Datasprings

Dynamic Forms is being used for almost all end-user data submission tasks. This is a very powerful forms generator for DotNetNuke, which allows you to create data-driven forms, storing data either in the module's internal database schema or in any custom external table structure. I am using custom tables for companies, products and categories so I chose the second approach. You can easily load data to your forms as well as save data to your database via SQL queries or stored procedures. You can populate form fields using SQL, and this is especially useful with lookup data used in combo boxes or checkbox groups. The module supports various goodies like injecting your own javascript, creating your own validations and launching events on form submission that can send email or write to the database. I used Dynamic Forms for the product and company data submission forms that are displayed to registered users.

Registered users can submit their company data. Each user can submit only one company, which is approved by the site's administrator. Companies must have a main activity and subactivities that fall under their main activity (it's a tree with 3 levels). After initial submission, the user must select a main activity and subactivities. (again, Dynamic Forms is used for the selection forms).

When this process is complete, the company must be approved by the site administrators. Users get an email when this is done. (Of course, administrators also get an email for each submitted company). This is achieved via Dynamic Forms post-submission events.

Afterwards, the user is able to submit up to a specific number of products for the company (currently 10, but it's as easy to change as a record in a database table) and assign each product to one of the subactivities they have defined for their company. Actually, the "main activity" acts only as a grouping category, while subactivities are the actual activities of the company.

When editing the subactivity list, the forms present only subactivities that can be selected depending on the main activity chosen and do not let the user unselect a subactivity he has already assigned products to.

Users have their own "control panel" where they can manage companies, products and activities. This works mainly with Open Web Studio, which we'll examine later on.

Dynamic Forms pros:

Very powerful
Datastore in own schema or custom database
Post-submission events (email, sql, etc.)
Field events (when you fill a field - you can hide/show sections depending on value etc.)
Great selection of controls - including data-driven comboboxes, listbox/radio groups, rich text editor, image and file upload controls.

Dynamic Forms cons:

Bugs arise when you try to push it too far
Somewhat expensive - you must make sure that you need it
Not very good / easy control on final layout
Image and file upload controls have many features (e.g. unique filenames, automatic thumbnail resizing) but need a lot of work to operate correctly.

Company website: www.datasprings.com

DotNetNuke Store: Click

Click here to read Part 2 (Open Web Studio)

Injecting CSS / Javascript on your page, revised

noreply@blogger.com (Gyromyristis) — Wed, 04 May 2011 12:54:00 +0000

A long time ago, I had posted a method to include Javascript in your .ascx skin’s HEAD section. Things have evolved till then, DNN supports JQuery out of the box, and we need an easy way to inject scripts and css stylesheets in our page, taking care that core stylesheets and jquery are loaded BEFORE our scripts, so they can work correctly. This is especially important with JQuery plugins.

Latest DNN versions include two placeholder controls on the default.aspx page, with Ids CSS and SCRIPTS accordingly. These are the controls that can hold our scripts and stylesheets after all core stuff has been loaded, and we can have code inside our .ascx skins that uses these controls and injects stuff like jquery plugins or custom stylesheets inside our page’s HEAD section.

I’ve written some reusable code to do so, which, in this basic implementation, can be used to control what scripts and stylesheets are loaded per skin. Of course, you can customize it even more to control things even on a tab level.

The code has basically two functions, AddCSS and AddJS (what they do is obvious). You must override the Page_Init function and add your calls to the functions there.

Here’s the code. You can use it inline inside your .ascx page, preferrably right after your last @Register statement.

<script runat="server">
    ''' <summary>
    ''' An enum which holds the various type of elements to be 
    ''' injected in the HEAD section of our page    
    ''' </summary>
    ''' <remarks></remarks>
    Private Enum htmlHeadElementType As Integer
        css = 1
        javascript = 2
    End Enum
    
    ''' <summary>
    ''' Add a CSS element to the HEAD section of our page
    ''' </summary>
    ''' <param name="csspath">The path to the CSS file</param>
    Private Sub AddCSS(ByVal csspath As String)
        AddHTMLHeadElement(csspath, htmlHeadElementType.css)
    End Sub
    
    ''' <summary>
    ''' Add a JavaScript element to the HEAD section of our page
    ''' </summary>
    ''' <param name="jsPath">The path to the js file</param>
    Private Sub AddJS(ByVal jsPath As String)
        AddHTMLHeadElement(jsPath, htmlHeadElementType.javascript)
    End Sub
    
    ''' <summary>
    ''' This is the actual function. 
    ''' It addds the element to the HEAD section of our page.    
    ''' </summary>
    ''' <param name="elementPath">The path to the file (css, js etc)</param>
    ''' <param name="elementType">a htmlHeadElementType corresponding 
    ''' to the type of the element
    ''' we are adding to the HEAD section.
    ''' </param>
    Private Sub AddHTMLHeadElement( _
          ByVal elementPath As String _
        , ByVal elementType As htmlHeadElementType)

        Dim containerControl As Control 
        
        Select Case elementType
        
            Case htmlHeadElementType.css 
                
                containerControl = Me.Page.FindControl("CSS")

            Case htmlHeadElementType.javascript 
        
                containerControl = Me.Page.FindControl("SCRIPTS")
                
        End Select
        
        If Not containerControl Is Nothing Then

            'Create our generic html control
            Dim oLink As HtmlGenericControl
            
            'Decide on what type of element to add
            Select Case elementType
                
                Case htmlHeadElementType.css
                    
                    oLink = New HtmlGenericControl("link")
                    oLink.Attributes("rel") = "stylesheet"
                    oLink.Attributes("type") = "text/css"
                    oLink.Attributes("href") = elementPath
                
                
                Case htmlHeadElementType.javascript
                    
                    oLink = New HtmlGenericControl("script")
                    oLink.Attributes("language") = "javascript"
                    oLink.Attributes("type") = "text/javascript"
                    oLink.Attributes("src") = elementPath
            
            End Select
            
            'Add a script reference to the head section 
            If Not oLink Is Nothing Then
                containerControl.Controls.Add(oLink)
            End If
            
        End If
        
    End Sub
 
    
    Private Sub Page_Init( _
        ByVal sender As System.Object _
        , ByVal e As System.EventArgs _
        ) Handles MyBase.Init

        'Add the various files to the HEAD section of our page.
        AddJS("/somepath/myscript.js")
        AddCSS("/somepath/mystylesheet.css") 
    End Sub

</script>

Fix: Points not added to core DNN Maps module

noreply@blogger.com (Gyromyristis) — Wed, 23 Mar 2011 13:46:00 +0000

The DNN Maps module is very simple and useful, but you may come across a problem: When you add points they are simply not added (and when you go to “data” later you see nothing on the list). This behaviour has been reported for module version 01.00.09.

The fix is very simple and I’m posting it here in order to facilitate anyone who’s been having the same problem:

Go to your DNN root folder and find

DesktopModules\Map\Sources\Dotnetnuke.Map.Standard.js

Change the return value in the mapWriteData function as follows.

from:

return encodeURIComponent(strvalue)
to:

return strvalue

And points will be added normally.

You may need to clear your browser’s cache in order to get it working.

Source: DNN Support Forums

Datasprings Dynamic Forms and image upload problems - a fix for specific scenarios

noreply@blogger.com (Gyromyristis) — Sun, 20 Feb 2011 20:24:00 +0000

This may not interest lots of people, but if you're using the very powerful Datasprings' Dynamic Forms module, you may come across it.

The setup

Historically, there have been quite a few bugs with the image upload field in this module, especially when using in combined with the Preview functionality. I had the following setup:

Dynamic Forms module with more than one image upload field.

Preview ON

Thumbnail ON

Initial SQL rendering/bind ON

More than one image fields

Other attributes for image fields (not that it matters, just describing the full scenario):

Custom image folder

Save filename only

Save system generated unique name

I wanted to setup Dynamic Forms to let a user upload, let's say, four images on the same form. I needed to save those in my own database tables and load them from those tables, so I had initial SQL rendering/bind as well as an sql event to save the images back to my custom database table.

The problem

When you use your own sql query to get data for your form, (at least at versions 03.30 to 03.40) thumbnails do not get loaded the first time the form is loaded. Instead, you see the full-sized image (after all, that's what stored in the database).

If you cause a postback (e.g. by clicking on the "upload new image" link on another image field) then the image url is correctly prefixed with "thumb_" and it is presented in the correct dimensions.

The solution

To overcome this, I just added code to my select query that would put the "_thumb" prefix in place even if it wasn't there, like the following:

SELECT

field1

, field2

, ...(other fields)

, case

when ltrim(rtrim(isnull(myfield,''))) =''

then ''

else 'thumb_' + myfield

end as myfield

, ...(other fields)

...(rest of query)

So this would always add the thumb_ prefix to the field "myfield".

This solved the problem with the initial form rendering. The first time a user sees the form, the thumbnails are shown instead of the full images.

The second problem

The first solution caused an additional problem: In the case of a postback, as I mentioned before, DF puts its own "thumb_" prefix in the images that are displayed on image fields! So if you attempt to click on "upload new image" in any fields, all the other fields will now have an image starting with "thumb_thumb_", and, since no filename exists that starts with this prefix, broken images will be all you'll see.

Please note that you'll see this only if you're using two or more image fields on the same form (or use any other postback that triggers this behaviour).

The additional solution

I found no way to circumvent this, since it's by design. So I had to resort to JQuery in order to correct the problem. I added a Custom Javascript (you can do that in the Module Configuration section) like the following one:

$(document).ready(function() {

    $('img[src*="/Portals/0/imageuploadfolder/"]').each(function(i,d) {

        $(d).attr("src",
                 $(d).attr("src").replace("thumb_thumb_", "thumb_")
                 );

});
});

What it does is take all images that have an src attribute that contains the path /portals/0/imageuploadfolder (replace this with your path) and changes any double "thumb_" prefixes to a single one.

This dual workaround seems to work good so far. Now I know this is a very special situation (Dynamic Forms with more than one image field and initial sql rendering) but I hope someone benefits from this. Take care.

Hide those help icons, site-wide

noreply@blogger.com (Gyromyristis) — Thu, 09 Dec 2010 15:42:00 +0000

Admit it. Those little questionmark help icons are ugly. Even if you replace the icon image with something more fancy, you still have to display them everywhere, even at the front-end (for example, the Feedback module uses them). And, if you’re developing for more than one language, that creates an awful lot of work for you, since you have to translate all texts that appear as tooltips when you hover over the icons.

There’s an easy way to hide them, though, and it’s site-wide. It will also apply to any third-party modules that use the dnn label control for providing labels for form controls.

Go to controls\labelcontrol.ascx and change the following line:

<asp:image id="imgHelp" runat="server" imageurl="~/images/help.gif" enableviewstate="False" />

<asp:image visible="false" id="imgHelp" runat="server" imageurl="~/images/help.gif" enableviewstate="False" />

That’s right. A visible=”false” attribute and the icons will disappear.

Also, if you notice that the labels are shifted to the left a bit (especially in IE), then go two lines above and change the line:

Or delete the span tag all together.

You can find a relevant thread on DotNetNuke.com with some more tips and tricks for the labelcontrol.ascx file here.

Have fun!

Using resource files in embedded user controls in skins

noreply@blogger.com (Gyromyristis) — Wed, 17 Nov 2010 17:38:00 +0000

If you are editing ASCX skins, then you have probably been tempted to introduce a bit of reusability by creating custom user controls and embedding them to your skins. These can actually function like skin objects, but without all the fuss. I’ve found it easy to create a couple of those in cases where I may need, for example, a common footer for all my skins, but of course you can do a great deal more with them, like introduce functionality without having to copy all the code to every skin file you make.

In any case, you have to register your control inside your skin file like this (names of folders, portal and skin path and tagprefix/name are arbitrary):

<%@ Register TagPrefix="MyCompany" TagName="FOOTER" src="~/Portals/0/Skins/myskin/myskinobjectsfolder/footer.ascx" %>

And use it in your skin file like this:

<MyCompany:FOOTER id="myFooterId" runat="server" />

The question is: How do you localize these little bastards? Even if you add DNN controls on them, the ResourceKey property continues to get data only from the skin’s resource file, not the control’s.

Of course, you can use your skin’s resource file to get localized strings and other data but this isn’t very convenient since you’ll have to add data to every resource file corresponding to each one of your skins. And I’m not going to talk about app_globalresources either! :)

(If you don’t know that you can have resource files for your skins, yes, you can. You can have a skins/app_localresources folder and you can have .resx files there and you can use the ResourceKey attribute in your DNN control tags to get localized data for your controls in your skins).

Well, based on this excellent post here about localizing embedded controls, I thought it would be good to summarize and simplify the process a bit. So here it goes:

You can give an embedded user control its own resource file by following two different approaches:

1. Make it inherit PortalModuleBase

2. Specify the resource file yourself and make the control use it.

Approach 1: Inheriting PortalModuleBase

You just have to add:

Inherits="DotNetNuke.Entities.Modules.PortalModuleBase"

in your control’s header.

E.g.

<%@ Control language="vb" AutoEventWireup="false" Explicit="True" Inherits="DotNetNuke.Entities.Modules.PortalModuleBase" %>

Doing so will give you access to the LocalResourceFile property, which will in turn point to the .resx file located in the app_localresources folder right under your control’s location.

But what .resx file, exactly? Not the one you expected.

The resx file will NOT follow the file name of your user control, but the ID by which it is called. If your control’s filename is MyFooter.ascx, and you call it with an ID of “myFooterId” then your resource file must be named “myFooterId.ascx.resx”.

Then, you can use code like this to get a localized value, for example, for the “Footer.Text” key:

<%=DotNetNuke.Services.Localization.Localization.GetString("Footer.Text", LocalResourceFile)

Ugly, because you have to remember to always use the same ID and also because you can’t use two instances of your control in the same skin. Also, inheriting PortalModuleBase restricts your coding flexibility.

Approach 2: Forcing the user control to use a resource file

If you don’t want your user control to inherit PortalModuleBase but you still need it to have its own resource files, you can define a LocalResourceFile property yourself. This is written directly in the .ASCX file but, of course, you can put it in code-behind too. (sorry about the line breaks):

ByVal key as string) as string
    Dim retVal as String
    retVal = _
DotNetNuke.Services.Localization.Localization.GetString( _
    key, LocalResourceFile)
    return (retVal)
End Function

</script>

What we did here was to create our own LocalResourceFile property. This tells the control to use a resource file that follows the file name of the control itself. So, if your control is named footer.ascx, your resource file will lie in app_localresources\footer.ascx.resx. If you need to specify a differently – named resource file, you just replace the GetFileNameWithoutExtension call with your own string. E.g. if you use “myownFooter” there, then there must be a myownFooter.ascx.resx file in the app_localresources folder.

In addition, we created a GetLocalizedString function which will just take the key and return the string from the resource file.

We can use this function in our user control to get localized data as follows:

<%=GetLocalizedString("Footer.Text")%>

This is much simpler and much more flexible.

How to quickly switch your "localhost" binding to another dnn site

noreply@blogger.com (Gyromyristis) — Wed, 03 Nov 2010 22:26:00 +0000

Warning: This is for advanced users only.

The situation

You've got a development machine which has more than one DNN sites that you are currently working on.
You're using host headers on those sites to have multiple root-level DNN sites. (And you know the terms "host header" and "binding")
You are using IIS7 or higher with Windows 7 or Windows 2008. (I suspect it may work on Vista too, but who's still got Vista? :) ).

(Don't continue reading if the above don't match your case. One of the most common reasons for the above scenario could be that there are root-level urls inside your DNN site, generated by custom modules or just hard-coded into skins / modules, so you have to make your development PC believe that this is a root-level site and not a virtual directory of your default web site. Or, even worse, if you're working on a copy of a site that's already online and there are links and other stuff pointing to the WHOLE domain, you may have to alter your hosts file to make your PC believe that your local site is running on the exact same domain. If you're dealing with DNN a lot, you've probably seen that we don't live in a perfect world and such cases do exist.)

The problem

You need to configure some modules on your installations, but the modules you have installed can run without limits only on "localhost". Furthermore, some modules, (for example, IndooGrid) need you to buy a licence if you run them ANYWHERE else than localhost - even if it's a test / development machine. But you don't want to buy additional licences since you can do your development work on localhost.

What you need

You need a way to quickly switch between what you see when you type "localhost" on your PC's browser, so that you can work on the site of your choice each time.

Of course, you can do it by altering your sites' host headers in IIS but that wouldn't be quick. And, I won't say a word about using different virtual machines, each with one localhost site - I've seen it happen. :)

The solution

Let's suppose I've got two sites, let's say Site1 and Site2. These listen to their respective host headers, let's say site1.mypc.local and site2.mypc.local. You have configured your Site1 to listen to "localhost" too. Currently, when you type "localhost" on your browser you see Site1.

Now, you either have configured your IIS to have an extra host header (*:80) for Site 1 or you have changed the location of your "default web site" to point to Site1's folder on your hard disk.

Do the following:

1. STOP your default web site (if that's what you're using to do the trick).

2. Go to all the sites that you need to implement the "switching" on, and add a portal alias for localhost so that they can respond to the call (if there is not one already). If you do so, an IISRESET would be good too, in order to avoid the dreaded "redirect loop" error that can happen from time to time.

3. Create a batch file with the following and save it as changehost.bat (or any name you choose):

@echo off

if "%1" == "site1" goto site1
if "%1" == "site2" goto site2
if "%1" == "" goto error

:site1
%windir%\System32\inetsrv\appcmd set site /site.name:site2 /-bindings.[protocol='http',bindingInformation='*:80:']
%windir%\System32\inetsrv\appcmd set site /site.name:site1 /+bindings.[protocol='http',bindingInformation='*:80:']
goto end

:site2
%windir%\System32\inetsrv\appcmd set site /site.name:site1 /-bindings.[protocol='http',bindingInformation='*:80:']
%windir%\System32\inetsrv\appcmd set site /site.name:site2 /+bindings.[protocol='http',bindingInformation='*:80:']
goto end

:error
@echo You have to provide a parameter!

:end

(Sorry for the wrapping, each call to appcmd should be on a single line.)

Let's explain what this batch file does. You call it like this (make sure you have administrator rights):

changehost site2

And you expect to see your "site2" responding to localhost instead of "site1".

What the batch file does is go to the matching section of the batch code, following the IFs. When it gets there, it does two things:

First, it uses appcmd.exe (an utility located in your windows directory\system32\inetsrv folder, which allows you to access several IIS properties from the command line) to add a binding to localhost (*:80) to the site you need and REMOVE this binding from any other of your sites that possibly has it. Essentially, it does what you would do by hand - go to iis, add a binding to the site of your choice, remove the binding from the previous site since you are not allowed to have two sites with the same host header.

The result is that you will always have one and only one site bound to localhost, and that you can change what site this is by just executing your batch file.

Some things to have in mind:

The parameter's values can be anything you want, as long as there is a section inside the batch file you can GOTO if you match a parameter value. I've used the same names as the names of the sites in order to have some consistency, but this isn't needed. "Foo" and "Poo" would do the same job, as long as there was a "Foo" section for site1 and a "poo" section for site2.

The /site.name switch needs the actual site's name as it is declared in IIS.

You must FIRST remove any possible localhost bindings (/-bindings switch) and add the localhost binding (*:80) last (/+bindings switch), otherwise you'll get an error and the binding won't be added because it will exist on another site.

If a site does not have a localhost binding, you'll get a message that it can't be found, like this one:

ERROR ( message:Cannot find requested collection element. )

Don't be alarmed, it's normal. Appcmd just tried to remove a non-existent binding, no problem.

If you try to run this script twice for the same site, you'll also get an error like this:

Cannot add duplicate collection entry of type 'binding' with combined key attributes 'protocol,bindingInformation' respectively set to 'http, *:80:'. )

This means that you tried to add a binding to *:80 to the site that already had it. That's perfectly normal, too, nothing to worry about, no changes will be made.

The example is for two sites, if you have three you'll have to adjust the number of sections, your IF statements and your appcmd calls accordingly. Remember, we're doing a simple thing: Attempting to remove localhost bindings from sites that may have it (only one will) and add a localhost binding to the site we want.

I hope this helps a bit. It worked for me, if anyone tries it, please let me know if you have succeeded.

Standard disclaimer / warning: Even if you are an advanced user, please use this information at your own risk. It's easy to mess things up (actually, the only thing you'll mess up is your bindings - you won't lose any data but it's enough to make your development sites unaccessible if you don't know what you're doing). I cannot be held responsible if any of the above information proves misleading or incorrect.

Happy localhosting! :)

SupportedFeatures field, Search Indexer exceptions, oh my.

noreply@blogger.com (Gyromyristis) — Thu, 21 Oct 2010 21:29:00 +0000

I had one of my usual strange problems tonight. The search indexer on a DNN web site I created some months ago would not index the entire site. I got suspicious and checked the event log, where there were pages after pages of general exceptions.

Most errors seemed to be something like:

System.ArgumentNullException: Value cannot be null. Parameter name: type at System.Activator.CreateInstance(Type type, Boolean nonPublic) at DotNetNuke.Framework.Reflection.CreateObject(String TypeName, String CacheKey) at DotNetNuke.Services.Search.ModuleIndexer.GetModuleList(Int32 PortalID)

Okay, this could not be the real error! I had to find the real cause.

First try - cleaning the search index in case it's been corrupted

The first thing I tried (and I advice you to do that before you try anything else) was to start with a clean search index, in case it was somehow corrupted. What you can do is the following (taken from this post):

If by accident the search index got corrupted, there will be no serach results displayed any further and you have to delete the search index tables manually. Follow these steps:

Login as Superuser ("host" by default)
In Host Menu select item "SQL"
Copy the following 4 lines and paste them into the text box:
truncate table {databaseOwner}{objectQualifier}SearchItemWordPosition
DELETE {databaseOwner}{objectQualifier}SearchItemWord
DELETE {databaseOwner}{objectQualifier}SearchWord
DELETE {databaseOwner}{objectQualifier}SearchItem
Activate the check box and hit Run
The search index will be rebuilt automatically by the scheduler.

(Although this is the right way, I've found that a DELETE {databaseOwner}{objectQualifier}SearchItem will be sufficient. If you don't have a special db owner or a specific object qualifier, a DELETE from SearchItem will do the same job, either on your SQL Server Management Studio or your Host-SQL page).

Also, you don't have to wait for the scheduler. Go to host-search admin and rebuild the index yourself.

Second try - checking and correcting the SupportedFeatures field on the DesktopModules table

Well, starting with a clean index didn't help, so I searched further. What I found surprised me. Let's see what this post says:

It seems that the desktopmodules table has a supportedfeatures field that should be set to 0 or higher. But sometimes when modules are installed they end up with a -1 so this causes the error. Setting the fields to 0 when they are -1 fixes it, like so:

UPDATE [databasename].[dbo].[DesktopModules]
SET [SupportedFeatures] = 0
WHERE [SupportedFeatures] = -1

This is for SQL Server Express... don't know how it would work in the SQL page of DNN.

The solution

Well, I did a check on my own DesktopModules table. And suprise, surprise, two modules had a value of -1 for the SupportedFeatures field. As expected, these were the two modules that were generating the exceptions and blocked the indexer from indexing the whole site.

I did what the post said, and kaboom! Indexer worked perfectly, no more exceptions.

What the SupportedFeatures field actually does

What troubled me was what this field actually represents. I had values of 6, 7, 0 etc in other modules' records. So I dug a bit further and found this post:

This is a bit field where

2^0 = 1 indicates IPortable

2^1 = 2 indicates iSearchable

2^2 = 4 indicates iUpgradable

add those values for combinations (i.e. 7 = 1 +2+4 = IPortable,iSearchable and iUpgradable)

So this solved the mystery. Those two modules were installed in a wrong way and got an invalid value of -1 for their SupportedFeatures field, which in turn caused the exceptions when the Search Indexer ran.

Where and when can this happen?

My DNN site was version 5.2.2, but as far as I understand this thing can happen on various DNN versions, depending on the modules installed and how well the installation process is executed. I can't say that exceptions from the Search Indexer are always due to this particular problem, so use this proposed solution with extreme caution if it happens to you, and always have a database backup handy!

(Not a) tutorial: Creating my first DNN scheduled task

noreply@blogger.com (Gyromyristis) — Sat, 03 Jul 2010 22:33:00 +0000

In this post, I’ll describe my (successful) attempt to create a basic email queue functionality using a custom DNN scheduled task.

Why not a tutorial? Because my intention is to show you what I have done, without telling you that this is the right (or the only) way to do it, or demonstrating this as a techically complete and correct solution. This work is far from finished – it just covers basic functionality and is not usable out of the box. But if you’re struggling with DNN scheduled tasks, reading below may provide you with a way to get started.

I found great help in this excellent post here, which you should read for more information on creating your own scheduled tasks in DNN. Actually, this article here is a simple application of the tutorial I found in that post. Read it, it’ll be extremely helpful.

Let’s get to the point.

Purpose:

I had the need to notify custom groups of DNN registered users upon submission of some forms created either with the XMOD Pro or the Datasprings Dynamic Forms module. Although both modules support sending emails upon submission, they are restricted to sending emails to specific people, lists, or roles.

I needed something more complex, such as a database query based on several tables, in order to determine who would get the notification. Both modules allow issuing queries to the database upon submission, so it seemed right to create my own email queue, consisting of a database table (the queue) and a scheduled task to send the mails.

What’s more, a queue can help where there is a bunch of emails to be sent – let’s say you need to send 1k emails upon the next form submission – you don’t have to send them all at once. You just send a dozen each time the scheduled task is ran, until the queue is empty.

Database objects

So – what did I need first? Of course, a table to hold my queue.

CREATE TABLE [dbo].[DotSee_MailQueue]( 
    [MailID] [int] IDENTITY(1,1) NOT NULL, 
    [FromUser] [nvarchar](500) NOT NULL, 
    [ToUser] [nvarchar](500) NOT NULL, 
    [Subject] [nvarchar](500) NOT NULL, 
    [BodyHtml] [nvarchar](max) NULL, 
CONSTRAINT [PK_DotSee_MailQueue] PRIMARY KEY CLUSTERED 
( 
    [MailID] ASC 
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, FILLFACTOR = 80) ON [PRIMARY] 
) ON [PRIMARY] 

GO

Yes, it’s a silly table but enough for my basic functionality: From, To, Subject, Body and an id. All the necessary information to send an email.

Then I needed a stored procedure to retrieve information from that table:

CREATE PROCEDURE [dbo].[DotSee_GetMailQueueItems] 
AS 
BEGIN 
SET NOCOUNT ON; 

Select top 10 [MailID],[FromUser],[ToUser],[Subject],[BodyHtml] FROM [dbo].[DotSee_MailQueue] 

END 

GO

Note: I prefix my tables with “DotSee_” since this is the name I have selected for my custom work (namespaces included, as you’ll see below). Don’t give it serious attention, it’s just my convention.

Setting up a project for my scheduled task

There are more than one ways to begin creating a scheduled job for DotNetNuke using Visual Studio, but there is a common denominator: Your job MUST be a DLL file in DotNetNuke’s bin directory. So you can go either with a Web Application Project or with a Class Library. I chose Class Library. Here’s what I did:

Created a new Class Library project.

Added a reference to DotNetNuke.dll from an existing DNN installation (and set Copy Local to false)

Added a reference to Microsoft.ApplicationBlocks.Data from the same DNN installation (in order to be able to use DNN’s own DAL for interacting with the database)

Set the build path INSIDE DNN’s bin folder to save me time copying and recopying the dll.

Went to the project’s properties and deleted the contents of the root namespace field. Yes, it should be empty for your dll to work. Don’t miss that.

Regarding (4), I did this work on a virtual machine, where I had a DNN installation and my class library project on the same computer. I suggest you follow some similar approach, since it is very easy to test and debug (you can debug only by attaching to the w3wp.exe process, but it’s better than nothing).

Writing the code

Two more things you must know: Your custom class must inherit DotNetNuke.Services.Scheduling.SchedulerClient and the only method that is called by DNN’s scheduler is DoWork().

So here’s my custom scheduler class:

Imports DotNetNuke.Services.Scheduling 
Imports DotNetNuke.Services.Exceptions 

Imports System 
Imports System.Web 
Imports System.IO 

Namespace DotSee.DnnScheduledMailNotifier 

    Public Class Mailer 
        Inherits SchedulerClient 

        ' requires a special constructor which 
        ' accepts a ScheduleHistoryItem 
        Public Sub New( _ 
            ByVal objScheduleHistoryItem _ 
            As ScheduleHistoryItem) 

            MyBase.New() 
            Me.ScheduleHistoryItem = objScheduleHistoryItem 

        End Sub 

        Public Overrides Sub DoWork() 
            Try 
                ' perform some tasks 
                MailWorker.DoWork() 

                ' report success to the scheduler framework 
                ScheduleHistoryItem.Succeeded = True 

            Catch ex As Exception 

                ScheduleHistoryItem.Succeeded = False 
                ScheduleHistoryItem.AddLogNote _ 
                    ("EXCEPTION" + ex.ToString()) 
                Errored(ex) 
                Exceptions.LogException(ex) 

            End Try 
        End Sub 
    End Class 

End Namespace

Apart from the MailWorker.DoWork() line (code coming right below), the class can be used as a template for writing your own scheduled tasks. (You will use your own namespace, of course). I put my specific code in a different class so that it would be easy to make the distinction between code needed for my specific need and the “template” code that every DNN scheduled task needs.

Here’s my MailWorker class (DotNetNuke.dll referenced was version 5.2.1, GetHostSettingsDictionary may not work with 4.x):

Imports DotNetNuke.Services.Mail
Imports DotNetNuke
Imports DotNetNuke.Data
Imports DotNetNuke.Entities.Host


Namespace DotSee.DnnScheduledMailNotifier


    Public Class MailWorker

        Private Sub New()

        End Sub

        Public Shared Sub DoWork()

            Dim d As Dictionary(Of String, String)
            d = Host.GetHostSettingsDictionary()

            Dim dnp As DataProvider
            dnp = DataProvider.Instance
            Dim dr As IDataReader

            Dim ids As New List(Of Int32)

            dr = dnp.ExecuteReader( _
                "DotSee_GetMailQueueItems", Nothing)

            If Not dr.Read() Then Return

            While dr.Read

                Mail.SendMail( _
                    dr("fromuser").ToString _
                    , dr("touser").ToString _
                    , "" _
                    , dr("subject").ToString _
                    , dr("bodyhtml").ToString _
                    , "" _
                    , "" _
                    , d("SMTPServer") _
                    , d("SMTPAuthentication") _
                    , d("SMTPUsername") _
                    , d("SMTPPassword") _
                    )

                ids.Add(CType(dr("mailid"), Int32))

            End While

            For Each id In ids
                dnp.ExecuteSQL( _
                    String.Format( _
                        "DELETE FROM DotSee_MailQueue WHERE mailid={0}" _
                        , id.ToString))
            Next

        End Sub

    End Class

End Namespace

What it actually does (in a brutal way, I should add) is check the table, get 10 items at a time (via the DotSEe_GetMailQueueItems stored procedure defined earlier), send an email for each of the items and then delete the corresponding records from the table. (Ok, I know the way it does it sucks a bit, but It’s only quick and dirty functionality, remember).

So when I compile this beauty, my DotSee.DNNScheduledMailNotifier.dll goes inside DNN’s bin folder, and now what I have to do is tell DNN that this is a scheduled task and that the scheduler should include it. Here’s how:

Host-Schedule and click “Add Item to Schedule”.

Set friendly name to whatever you want

Full class name and assembly should be your assembly name and your class name (the class containing the DoWork method) combined, as in AssemblyName.Classname. My Assembly’s name is DotSee.DnnScheduledMailNotifier and my class name is Mailer, so the full name is DotSee.DnnScheduledMailNotifier.Mailer.

Check the “schedule enabled” checkbox

Time lapse MUST have some value or else the task will not run at all.

That’s it! The task is ready to run. I tested it by manually inserting records into the DotSee_MailQueue table and it worked well, even with hundreds of records, sending 10 emails every 5 seconds.

So now I have my basic system ready. When I need to send emails to groups of people not defined by roles or other DNN constructs, I just have to write a good SQL query that fills the table with recipients that correspond to the criteria I need every time and presto!

Of course, there’s plenty of room for configuration / parameterization (for example, the number of emails sent each time or the type of email – html or plain text, or even a check for whether delivery was successful). But I guess you got the idea.

Thank you for your time.

ModuleMaster, an admin module that was really missing from DNN

noreply@blogger.com (Gyromyristis) — Sat, 24 Apr 2010 15:12:00 +0000

ModuleMaster is what I was looking for (and often considered developing myself). It can link modules – along with their settings – on the pages of your choice. Simple as that, but DNN doesn’t give you this option – you can either mark a module as “displayed in all pages”, in which case you only have linked modules to your original one – meaning that if you change something in one, it’ll change in every linked module, or copy the module by hand and then apply settings by hand (IPortable is not always well-implemented).

This module is a time-saver, especially for sites that have a number of pages already developed (and more especially if you’re using templates to create new pages). Imagine the scenario where the client asks you to apply a new text/html module, for example, in about 500 pages that you have already created, demanding to be able to edit each one of them independently of the others and needing to use a specific container. Count the DAYS it’ll take you to do it by hand. EDIT: Unfortunately, as I realised later, the module just creates “shadow” copies – i.e., links and not new instances, but remains useful whatsoever.

If anybody tries it, please post a comment here. I haven’t tried it yet, but looks very promising and it already has a couple of good reviews on SnowCovered.

Using page titles instead of names on the DNN breadcrumb skinobject

noreply@blogger.com (Gyromyristis) — Fri, 26 Mar 2010 11:39:00 +0000

Simple, but useful. A fellow developer needed to use the page title (and not the page name which is the default) on the breadcrumb skinobject of his skin. The reason was that his menu had limited real estate so he had to keep names short, but he needed to give more information on the navigation breadcrumb.

The solution is just so simple! In your skin’s .ascx file, you’ll see a definition like the following:

<dnn:BREADCRUMB runat="server" id="dnnBREADCRUMB" CssClass="Breadcrumb" RootLevel="0" Separator=" > " />

If you add the following attribute:

UseTitle="True"

You’ll have something like this:

<dnn:BREADCRUMB runat="server" id="dnnBREADCRUMB" CssClass="Breadcrumb" RootLevel="0" Separator=" > " UseTitle="True" />

And then your breadcrumb will be using page titles instead of names.

Enjoy.