Setting the title of pages in DotNetNuke to include portal name

Go to the root of the DotNetNuke install and open the “Default.aspx.vb” file. Find the code:

‘ tab title override
If PortalSettings.ActiveTab.Title <> “” Then
strTitle = PortalSettings.ActiveTab.Title
End If
Title = strTitle

and change this to include the portal name with “PortalSettings.PortalName”:

‘ tab title override
If PortalSettings.ActiveTab.Title <> “” Then
strTitle = PortalSettings.PortalName & ” – ” & PortalSettings.ActiveTab.Title
End If
Title = strTitle

This may change with later versions of DNN (such as 5) but this works in 4. Why this isn’t the default setting I have no idea.

Fixing the DotNetNuke javascipt menu bug in IE8 (dnn.dom.positioning.js)

For some reason my dnnNAV menus which worked on one site weren’t working on another. In IE8 the menus were rolling over fine but could not be clicked on to go to other pages. The javascript error was with the dnn.dom.positioning.js file, which I had not touched on either site.

Turns out the error is due to how the z-index element is used in the javascript. As found from the DotNetNuke forums, where surprisingly someone had an answer:

This error occurs because javascript is trying to retrieve the z-index order of the sub menu, which IE8 returns the default value of auto.

As a workaround edit the menu style sheet as follows.

Change the css file menu.css wich is in the folder “/Portals/_default/skins/MinimalExtropy/css/” :

/*  SUB Menu Normal */
.main_dnnmenu_submenu {
z-index:1;
border:1px solid #C0D6E5;
}

Press CTRL+F5 in the end to force the refresh of the css

Finding the size of each table in a SQL Server database

I needed to work out how to get the size of each table in a DotNetNuke database to work out why the DB was 3.9gb in size. I found a stored procedure from The Right Stuff which gives me the details on the database and each table within it using the undocumented sp_msForEachTable stored procedure:

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE checksize
AS
BEGIN

SET NOCOUNT ON

DBCC UPDATEUSAGE(0)

-- DB size.
EXEC sp_spaceused

-- Table row counts and sizes.
CREATE TABLE #t
(
[name] NVARCHAR(128),
[rows] CHAR(11),
reserved VARCHAR(18),
data VARCHAR(18),
index_size VARCHAR(18),
unused VARCHAR(18)
)

INSERT #t EXEC sp_msForEachTable 'EXEC sp_spaceused ''?'''

SELECT *
FROM   #t

-- # of rows.
SELECT SUM(CAST([rows] AS int)) AS [rows]
FROM   #t

DROP TABLE #t

END
GO

With this I could see that the DotNetNuke search cache was getting massive as the SearchItemWord and SearchItemWordPosition were both huge.

Content Versioning and Workflow in DotNetNuke

One of the biggest things missing from DotNetNuke is a robust versioning system to allow you to roll back changes and mistakes made by content editors. I’m not the only one that thinks so either as can be seen from the Roadmap page of the official site. A link on this page led me to Effority.net where I found this free module for workflow and versioning of Text/HTML modules. It’s not quite content versioning for entire pages or sites but is a good start and will hopefully allow us to correct mistakes (and entire Text/HTML content deletions) by some of the content providers.

Disappearing Menus & Menu Items in DotNetNuke

We had to restore a backup of one of our virtual machines (hosted on Microsoft Virtual Server) as the content for one of the DotNetNuke sites had been removed in an editing accident. I copied the backup vhd/vmc files across and restarted the server using the web interface only to find when I checked the website that the DotNetNuke menu, and our Inventua menu were both empty! I logged in and the “host” menu item appeared along with its subtree but still there was nothing else in the menu.

First thought, maybe it’s my browser? I was in Firefox so switched to IE and the same thing, no menu items. I cleared the cache and again, nothing. I even tried another PC, with the same result.

We have had this problem before with DotNetNuke, which is doing its best to convert us to another CMS as a result of slow speed and flaky reliability. Last time we just restored from a backup and the menu reappeared fine, making us believe it was a problem with the database getting corrupted or something (unlikely but a reasonable assumption).

Next I tried clearing the DotNetNuke cache by deleting everything in “[dotnetnuke_install_dir]Portals[portal_number]Cache” and retarting IIS with “iisreset” in a command window on the virtual pc.

Then i deleted browser temp files and refreshed the page, success! So the solution to disappearing menus in DotNetNuke when restoring from a backup is to clear out all the DotNetNuke cache and restart IIS.

also: I highly recommend the Inventua sidemenu module for DotNetNuke. Forget trying to make the default menu skin properly and try this, its been great for us.

Importing / Deleting / Copying Users in Bulk in DotNetNuke

I found a great free module at dnnVillage that uses an xml file to import /delete users in DotNetNuke en masse.

To copy users between a site I ran a “SELECT * FROM Users” on my original site and copied the output into a csv. Then I opened it in Access 2007 and selected the columns I wanted before clicking “External Data” in the ribbon then “More” then “XML File” in the “Export” section.

There was a bit of formatting text replacement I needed to do after the xml was generated but this was easy following the examples in the module. I then added the module to a page on my new DotNetNuke site and imported the users using the interface and my new xml file.

Unfortunately I still had to go through and edit everyone’s profile information (we are using custom profile fields) but I bet you could use the module to fill these in if you wanted. Regarding passwords, I set a default one for everyone and then emailed them to tell them to change their password at next login. We then set an option in everyone’s profile to force them to change their password at login and let the users choose a new password.

Creation of New Portals in DotNetNuke 4

This is the process for adding a new portal when we work in a development Virtual PC. The order below isn’t too important as long as each stage in the process is done completely. This also assumes you already have a DotNetNuke site set up and working on Windows Server 2003.

First decide on an address (lets call it www.dnn4.com), then open your hosts file and add it to the end of the 127.0.0.1 line. The hosts file is located at c:windowssystem32driversetc

This means that every time your point your browser on the local virtual pc at www.dnn4.com it will redirect to 127.0.0.1, which is where we will be hosting our DotNetNuke portal.

Next open up your DotNetNuke install and log in as your host account. Navigate to “Host” then “Portals” in the DotNetNuke menu.

On the page that comes up you should see a list of portals (probably only 1 as you only have a single portal with a default DotNetNuke install). Click on the drop down menu at the top and then “Add New Portal”.

You want this to be a parent portal with the alias “www.dnn4.com” if we are following this example. Fill in the other details including the “Security Settings” section, which is the details of an admin account you are going to add to this new portal. Click “Create Portal”.

Your portal is now created but unfortunately you can’t get to it externally as there is no way of resolving that alias.

Open up your Internet Information Services (IIS) manager. Right click on “Web Sites” and then click “New” then “New Website”. This will pop up a wizard to create a new website.

Type in your description, I always use the alias here (www.dnn4.com in this case), click next. On the next page leave everything the same and put your alias in the box under “Host header for this Web site (Default: None):” and click next. On the next page but in the path to your DotNetNuke install and click next. Finally make sure you click “Run scripts (such as ASP) and click next to end the wizard.

Now your new portal is set up you can wonder why you didn’t always do this instead of installing DotNetNuke all over the place.

Be warned: If something goes really wrong with your DotNetNuke database (it can happen, especially with dodgy modules) you run the risk of breaking all the portals associated with it. Always make a backup of your data before you add new modules / change DotNetNuke.