MSDN-style core DNN documentation

Mr. Ernst Peter Tamminga has created a help (.CHM) DNN Core reference file, based on the inline code documentation comments found on the DNN source code. Pretty useful, if you want to have a quick browse at all the DNN classes. The latest download is based on DNN 4.8.4.

You'll find it here: http://www.codeplex.com/DNNHelpSystem

Read more...

Changing what appears on the title bar

DotNetNuke has two ways of setting the title bar, depending on whether you set the "Page Title" field in Page Properties. It either displays your page title as you have set it, or the full path to your page (similar to the breadcrumb) when you leave it blank.

Some third-party modules, though, do use the page title for their purposes so you may want to have a page title exactly the same as the page name (reminder: the page name is what you see in the navigation component, while the page title is what you see at the browser title bar).

But you don't want the page title to appear "naked" in the title bar. You may still want to display the full path, or even just the portal name along with the current page's title.

To do either:

- Open default.aspx.vb (you'll find it in the root folder) with your favourite editor, even with notepad.

- Locate the InitializePage() function.

- Find the following chunk of code:

' set page title
Dim strTitle As String = PortalSettings.PortalName
For Each objTab In PortalSettings.ActiveTab.BreadCrumbs
strTitle += " > " & objTab.TabName
Next
' tab title override
If PortalSettings.ActiveTab.Title <> "" Then
strTitle = PortalSettings.ActiveTab.Title
End If


The first part of the code (set page title) says: "Put the full path in the title"
The second part of the code (tab title override) says: "If the title is not empty, just show the title the user has entered and nothing else".

In order to show the portal name along with the title the user has entered, change the line:

strTitle = PortalSettings.ActiveTab.Title
to
strTitle = PortalSettings.PortalName + " > " + PortalSettings.ActiveTab.Title

In order to show the full path in any case (regardless whether the title is empty or not), DELETE the second part of the code all together (the last if...end if part). That way, the title will always be the full path to your page, comprised of the corresponding page titles of all the parent pages till the root page.

Read more...

Retrieving tabs using SQL, security-aware

There are times when you like to go deeper with DNN and retrieve certain information by means of an SQL Query or a stored procedure. That's what happened to me when I needed to create a custom combo box which would redirect the user to specific pages.

In order to achieve that functionality, I had to use a module which would permit me to issue SQL queries to DotNetNuke and then format the results as I wanted. As I've stated many times before, I find the ListX module pretty useful in these situations.

One thing I discovered, though, is that you need to have a deeper understanding on what's going on with security in order to issue an SQL query that selects ONLY the tabs that a registered user has the right to see. You see, DNN tabs are not always visible to all user roles, so when using SQL you must be careful not to retrieve tab records that lead nowhere for the current user.

I'm not going to go into details on what I've done with the ListX module, unless someone asks specifically for it. Instead, on this post, I'm going to focus on how to issue a SQL query that retrieves records from the Tabs table that are visible for the current user.

For this post, it is assumed that you already know the ID of the current user in some way.

If you issue something like:

SELECT tabid, tabtitle FROM Tabs

Then you'll have all tabs, even those that are deleted. So we first need to have a WHERE clause to exclude deleted tabs, like this:

SELECT tabid,tabtitle FROM Tabs WHERE isDeleted=0

That leaves as with all active tabs, even those that are accessible by the administrator. In order to make our query security-aware, we have to see what tables the Tabs table is related to, in the context of security permissions.

The related tables are the following:

• TabPermission: A table which holds role permissions for every tab. Remember, DNN security works with roles. (We assume that we're not using the special "specific userid" feature that was introduced in later version of DNN).
• UserRoles: A table which holds the participations of DNN users to DNN security roles
• Users: A table which holds the actual DNN users.

The table that interests us more is the TabPermission table. Let's see the fields that interest us the most from this table:

TabId:

The tab id the record is referring to. There may be more than one records per tab id in the TabPermissions table, if the tab is available to multiple roles or even to one role with multiple permissions (DNN grants VIEW and EDIT permissions to tabs).

PermissionID:

The number you see here is the type of permission specified, and is related to the Permission.PermissionId field. If you do a SELECT * FROM Permissions you'll get, among other records, the following two records:

3    SYSTEM_TAB    -1    VIEW    View Tab
4    SYSTEM_TAB    -1    EDIT    Edit Tab

For our purposes, we will need permission id 3, i.e. VIEW permissions. Remember, we need the tabs that our user is allowed to see.

RoleID:

This is where things get a bit complicated. The RoleID field is related to the Roles.RoleId field (try a SELECT * FROM Roles to see what you'll get). But here, we don't need all the roles but just the roles our user is participating in. So we need to relate this field to the UserRoles table, which holds that information. If you do a SELECT * FROM UserRoles WHERE UserId=xxx (put your user id in the place of xxx), you'll get all role participations for the specified user.

(You'll notice that the UserRoles table also has the fields ExpiryDate, IsTrialUsed and EffectiveDate. For the sake of simplicity, we'll suppose that we don't have any roles with dates set, although it would be very easy to extend our final query to include only roles that are effective in the current time period.)

In the TabPermissions table, you'll notice two additional role ids that DO NOT exist on the Roles table: -1 and -2. -2 stands for "Host", and concerns pages accessible by the host user. -1 stands for "All Users" and concerns all non-administrative pages that are accessible from the "All Users" virtual role (this role actually does not exist anywhere).

Try doing the following:

--Fetch only admin pages accessed by the Administrators role 
select * from tabpermission 
inner join tabs 
on tabs.tabid = tabpermission.tabid 
where roleid=0

--Fetch only non-admin pages accessed by all users 
select * from tabpermission 
inner join tabs 
on tabs.tabid = tabpermission.tabid 
where roleid=-1

--Fetch only host pages 
select * from tabpermission 
inner join tabs 
on tabs.tabid = tabpermission.tabid 
where roleid=-2

And observe the different results.


So what do we need in order to get the tabs that are accessible from a single, specific user? We'll take our initial query:

SELECT 
    tabid,tabtitle 
FROM 
    Tabs 
WHERE 
    isDeleted=0

And we'll amend it as follows:

declare @userid int 
select @userid = 2 

    select 
        tabs.tabid, tabs.title 
    from 
        tabs 

inner join ( 
    select 
        distinct tabpermission.tabid 
    from 
        tabpermission 
        left outer join 
        userroles on tabpermission.roleid = userroles.roleid 
        left outer join 
        users on users.userid = userroles.userid 
    where 
        tabpermission.permissionid=3 
        and (users.userid = @userid 
        or tabpermission.roleid=-1 or @userid=1) 
    ) as perm 
on perm.tabid=tabs.tabid 

where 
    tabs.isdeleted=0 
order by tabs.tabid ASC

What we did was to initially declare a @userid variable and give it a value (4 for our example, whatever suits you for your DNN installation - if you're making an SP out of this you can just provide the user's ID value as a parameter to the SP).

We're using the @userid variable inside our JOIN statement, which actually joins the Tabs table with the TabPermission table, but restricts the TabPermission table results to where the permission type is VIEW (id 3) and our user id is equal to @userid (users.userid = @userid) OR there are view rights for all users (tabpermission.roleid=-1)  OR our user is the administrator. (@userid=1), which overrides everything else. The DISTINCT clause is used to ommit propable multiple results for the same tab.

This will essentially get us the tab records that are accessible with VIEW permissions for the given user.

As I've mentioned before, some things are not covered in this query:

• Permissions to a specific user id



• Roles with start and expiry dates

But in my opinion it's a good starting point for anyone who needs to create a security-aware tab retrieval query in DNN.

Please let me know what you think.

Read more...

The dbo.tabs.IconFile field issue

The case is fairly simple: In a DNN installation, we needed the user to use the IconFile field (i.e. the "Icon" field in the Advanced Settings section of the Page Properties page to add a custom icon to each page they made. We would then use a query created in Bi4Ce's ListX module to present a list of pages in the form of an in-page navigation menu for a specific portion of the portal.

To our horror, we discovered (using DNN version 4.8.2), that the IconFile field in the Tabs table takes two types of values: Either a value like "FileID=xxx", where xxx is the id of a record in the Files table, or the full path of the image file (Portals/0 is implied, so the file path is starting with the next sub folder).

That is, if you've set the icon to be in portals/0/myimages/myimage.jpg, you either get an entry in the Tabs table like "FileId=2312", or an entry like "myimages/myimage.jpg". At this point we are not sure why this is happening, but the truth is we don't care. We just want the path to the actual file either way.

In the case of the fileid thing, you can get the path by joining the tabs table with the files table and then the files table with the folders table (the folder path itself is in the folders table) and voila. In the case where the full path exists in the IconFile field, you obviously don't need to do anything else.

We created a query which decides on what to do and produces a result set with two fields: tabid and img where img ALWAYS contains the full path to the image file (provided that one is set for the page), regardless of whether it's in the form "FileID=xxx" or in the full path form, and I'd like to share it with you.

You can easily make a view out of it and use it where appropriate. It hasn't been tested on multi-portal installations, maybe things will differ a bit there. Comments are always welcome. Here goes:

select 
 tabid
 , case 
  when ltrim(rtrim(iconfilepath))='' 
  then folderpath+filename
  else iconfilepath
  end 
 as img

from 
(
select 

   tabid
 , taborder
 , case
  when patindex ('FileID=%', iconfile) >0
  then convert(int, replace(iconfile, 'fileid=', '')) 
  else 0
  end 
 as iconfileid
 , case
  when patindex ('FileID=%', iconfile) =0
  then iconfile
  else ''
  end 
 as iconfilepath
 
from 
 tabs 
where 
 isdeleted=0 


) mytabs

left outer join files
on files.fileid = iconfileid
left outer join folders
on files.folderid = folders.folderid

order by 
 taborder asc

Read more...

Solving the Search Results problem when using the free MMLinks localizable module

(This article assumes that you have an advanced knowledge of what's going on inside the DotNetNuke portal framework and its Search indexer.)

For those of you who don't know what the MMLinks module is, go here to find out.

(waiting for you to read...)

Okay, now you know. With MMLinks, you can replace your standard Text/HTML modules with fully localizable ones, localizing both the title and the Text/HTML part. With one slight defect: Since DotNetNuke's search indexer doesn't know anything about the localized titles, it insists on presenting the default, non-localized module title in the Search Results page (that would be "MMLinks" if you leave it intact).

The reason for this is that localized titles for the MMLinks modules are kept in a different table: Delisoft_MMLinksTitleLocales. DotNetNuke doesn't take this table into consideration when indexing, so no localized titles in Search Results.

I tried to solve this problem by creating a trigger which affects the core SearchItem table. That's right, the table where all indexed items are kept. The trigger investigates whether the row being updated belongs to an MMLinks module instance (by checking the ModuleDefinitions table). If it does, it replaces the contents of the Title field with the localized MMLinks title. Since MMLinks modules produce one entry for each locale, voila. You've got localized MMLinks titles in Search Results (which, by the way, uses the contents of the SearchItem table).

I am providing this code in order to receive comments and / or improvements to it. Please do not use it anywhere near sensitive data or production databases. It may not work correctly.


So, first, a catch-all disclaimer to make the above statement even stronger :) :

CAUTION: THE TRIGGER HAS BEEN ONLY TESTED A COUPLE OF TIMES. IT IS SUGGESTED THAT YOU DO NOT USE THIS CODE IN A PRODUCTION ENVIRONMENT. IT IS STRONLGY ADVISED THAT YOU BACKUP YOUR DOTNETNUKE DATABASE FIRST. I DO NOT TAKE RESPONSIBILITY FOR ANY MALFUNCTION OR DATA LOSS THAT MAY RESULT FROM USING THE CODE PROVIDED HERE. USE AT YOUR OWN RISK.

And now, the code:

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
-- =============================================
-- Author: Tool
-- Create date: March 2008
-- Description: A trigger which changes the title
-- field in the SearchItem table and replaces it
-- with the LOCALIZED title when using the MMLinks
-- module. USE AT YOUR OWN RISK.
-- =============================================
ALTER TRIGGER [dbo].[tr_Tool_setLocalizedTitleForMMLInksModule]
   ON  [dbo].[SearchItem]
   AFTER INSERT, UPDATE
AS
BEGIN
 -- SET NOCOUNT ON added to prevent extra result sets from
 -- interfering with SELECT statements.
 SET NOCOUNT ON

 DECLARE @searchItemId int
 SELECT @searchItemId = searchItemId FROM Inserted

 DECLARE @moduleid int
 SELECT @moduleid = moduleid FROM Inserted

 -- Do work ONLY if entry in SearchItem table concerns an MMLinks module instance.
 IF EXISTS
  (
  SELECT
   ModuleId
  FROM
   dbo.Modules
  WHERE
   ModuleDefId in
    (
    SELECT
     ModuleDefId
    FROM
     dbo.ModuleDefinitions
    WHERE
     FriendlyName ='MMLinks'
    )
  AND ModuleId = @moduleid
  )
 BEGIN

  DECLARE @localetext nvarchar(150)

  --Get the localized text
  --In order to find the localized text, we use a trick.
  --MMLinks fillds the SearchKey column in the SearchItem table with the
  --moduleId concatenated with the locale, in the form xxx-yyy. We use this
  --information to track the correct entry in the MMLinksTitleLocales table.
  
  SELECT
   @localetext = LocaleText
  FROM
   dbo.Delisoft_MMLinksTitleLocales
  WHERE
   (CONVERT (varchar(5), ModuleId)+'-'+ LocaleKey) =
   (SELECT SearchKey FROM SearchItem WHERE SearchItemID = @searchitemid)

 
  --Once we have the localized text, do the update.
  IF @localetext IS NOT NULL AND rtrim(ltrim(@localetext))<>''
  BEGIN
   UPDATE
    dbo.SearchItem
   SET
    Title = @localetext
   WHERE SearchItemId = @searchitemid
  END

END


 SET NOCOUNT OFF
END

If you want to see immediate results, just delete everything in your SearchItem table and do a content re-index from the Host Search Admin menu.

I'm anxiously waiting for comments.

Read more...

Integrating the Lightbox JS 2.03.3 image overlay script with DNN

According to its creators, "Lightbox is a simple, unobtrusive script used to overlay images on the current page. It's a snap to setup and works on all modern browsers."

And it really does what they say. So, why not use it with DNN? The fact that it can also work with groups of pictures providing basic back/forward navigation functionality makes it ideal as a lightweight picture gallery. Of course, it can be used with single pictures too, eliminating popup windows in order to see a picture, complete with (optional) caption, at a larger size.

In order to get Lightbox to work, you first need to go get if from http://www.huddletogether.com/projects/lightbox2/ . There you can also see examples and the way you can integrate Lightbox in an HTML page. So we'll only concentrate on things needed to be done in DNN here.

Our aim is to integrate Lightbox with a specific skin, not with the whole DNN installation. This way we'll have more flexibility regarding access to hosted DNN installations which may only allow access to the "Portals" folder.

So here are our steps:

1. Under the skin folder you wish to use for your DNN portal, create a folder called "Lightbox" and drop the contents of the .zip file you downloaded there. Three directories will be created: js, images and css.

2. Delete the html file as it only serves as an example.

3. Append the contents of the lightbox.css file that you'll find in the css folder into your skin.css file. You can keep the lightbox.css file, but you'll only make things more complex :)

4. Delete the lightbox/css folder if you like, as it is no longer needed.

5. In the ASCX file you will be using for your skin, put the following code immediately after the "@Register" tags as follows:

 <script src="<%=skinpath%>lightbox/js/prototype.js" type="text/javascript"></script>
 <script src="<%=skinpath%>lightbox/js/scriptaculous.js?load=effects" type="text/javascript"></script>
 <script src="<%=skinpath%>lightbox/js/lightbox.js" type="text/javascript"></script>

Update: For LightBox v2.04, the second line must be:
<script src="<%=skinpath%>lightbox/js/scriptaculous.js?load=effects,builder" type="text/javascript"></script>

SKINPATH is a DNN token and will be replaced at runtime with your current skin's path.

6. Immediately after the above piece of code, insert the following code:

<script type="text/javascript">
 var fileLoadingImage = "<%=skinpath%>lightbox/images/loading.gif";
        var fileBottomNavCloseImage = "<%=skinpath%>lightbox/images/closelabel.gif";
</script>

Why do we need this? The javascript file declares these two variables supposing they will be inside a folder relative to the physical position of the script, but that's not how DNN works, since our current path is NOT the skin's path, but the root path of the DNN installation! So we must override the paths here in order to be transparent to the image paths (using the skin path). We also have the additional ability to change the images used for the "close image" function here.

7. Open your skin.css file, locate the part you have copied from lightbox.css and locate the #prevLink, #nextLink classes. Change the paths to the three images for blank background, previous and next picture mentioned there as follows:

../images/blank.gif to lightbox/images/blank.gif
../images/prevlabel.gif to lightbox/images/prevlabel.gif
../images/nextlabel.gif to lightbox/images/nextlabel.gif

These images are unfortunately defined by the stylesheet, so since we moved the contents to skin.css we must make the positions of the images relative to the position of our current skin file. I will say again that you could always include the original lightbox.css but the current way is just my suggestion.

Of course you can use any image you like for next, previous and close functions as long as you maintain correct paths.

8. Try entering some image links into a text/html module as described in the original instructions for Lightbox and see what happens. Note: You can't use the aspx page link provided by the file manager when using lightbox. You must provide the links exactly as described in their (simple) instructions.


Finally, if the required JS files seem too big (approx. 103K total size) you could always use a JScript compressor like http://javascriptcompressor.com/ to reduce the total file size.

Please send comments if something in the instructions is not correct, so as to have it immediately corrected.

Happy Lightboxing! :)

Read more...

Video: Creating DotNetNuke Modules

A free video from JumpStart TV explaining how to create your own DotNetNuke modules. You can watch it online right here.

Read more...