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...

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...

Fix: Points not added to core DNN Maps module

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

Read more...

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

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.

Read more...

SupportedFeatures field, Search Indexer exceptions, oh my.

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!

Read more...