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

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.

Read more...

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

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!

Read more...

Great news on Open Web Studio (OWS)!

 

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?

Read more...

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

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!

Read more...

Removing Google Analytics from your DNN site

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!

Read more...

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

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:

 

<add key="PersistentCookieTimeout" value="0" />

 

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.

Read more...

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

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.

Read more...