ThinkofDesign Blog

There are cases that an image for the logo can be optional like in small personal sites and blogs. By default within a DotNetNuke site we have to choose between two options, either an image or no logo at all. So today we see how to make DNN show our portal name instead of a logo image in a search engine friendly manner.

Let's first see the code example and then we explain it.

 <% if len(PortalSettings.LogoFile) > 0 then %>
 <dnn:logo runat="server" id="dnnLOGO" />
 <% else %>
 <h1 id="logo"><a href="http://<%= PortalSettings.PortalAlias.HTTPAlias %>"><%= PortalSettings.PortalName %></a></h1>
 <% end if %>

What we do is pretty obvious. First we check if there is an image selected in site settings to be the logo of the portal. If there is one then we show it. That's the default DNN behavior actually. What we added is the way to handle the "else" case where a logo image has not been selected. So in that case we show an h1 and inside that a link to the portal's URL. I know that Tom will really love this! We also set the id of the h1 to be "logo" so we can customize it with CSS. And of course the text in the link is the name of our portal.

You can see that in action in the "Nucleus" skin I'm currently working on.

That's it folks. We could also update the logo skin object to do the same.

I hope you find this tip useful.

Blog.10.0 Skinning Utopia... or taking DNN skins to the next level

Vasilis Terzopoulos — Sat, 27 Jun 2009 02:28:00 GMT

I am just thinking of this so much time that I cannot keep it for myself for any longer. I love DNN skinning engine but I really think there is something important that is missing. Something that will take DNN skins to the next level.

So what is the problem

The problem is more obvious with the skins for sale on Snowcovered or on the DNN Marketplace. Those skins are not enough dynamic. DNN site owners need to be able to customize a skin upon their needs. They can do that now only if the know HTML and CSS or if they hire someone to do it for them. Skinners try to make their skins flexible and give their customers some power over the look and feel of their site by offering many page skins. Obviously creating more and more page skins is not the solution. Ten, fifty or a hundred page skins are not enough to cover all possible combinations. Not to mention that in most cases, the only difference between the page skins that included within a package is different headers or background colors.

Looking for the solution

DNN site owners need to be able to customize their skins through a friendly interface. Skinners need tools so they can offer this kind of flexibility with their skins. Skins need to be as powerful as the modules are. Skin Designer feature in the recent DNN versions seems to walk in this direction but what I envision is much more than that.

WordPress is a good place for inspiration

The first time I saw a WordPress theme with a Theme Options page I thought "Yes, this is a great idea!". DotNetNuke and WordPress have not much in common. But I find the idea to have a Skin Options page really exciting. A user friendly interface where the site owner will be able to customize a skin without HTML and CSS to be a requirement.

Implementation

OK, now begins the imaginative part. I'm not a programmer so what you will read in the following lines is probably far far away from a real world implementation.

We want the site owner to be able to customize both the HTML and the CSS part of a skin through a dynamically generated form. We'll do that with a module. Let's name it the "Skin Options" module. Through the module we can customize the skin at portal level or at page level. So a "Skin Options" page will be created automatically, when we install the module, under the "Admin" site section where we can set the skin options at portal level. But we can also override these options at page level just be dropping the module in a page and set new skin options for that particular page. The module will work only for the skins that include an options.xml file in the skin folder. In the options.xml file the skinner will be able to define what kind of input needs from the site owner and how this input will affect the skin.

Overriding skin.css

So for example the skinner could ask for a text input with "Background color:" label that will override a style within a CSS selector in skin.css (ideally multiple styles within multiple CSS selectors in skin.css). Or a select box where the user will be able to choose between several background images. Or a Boolean value based on which we'll be able to know if the user wants the login link to be visible or not. The module will create a new css file based on the user input that will override skin.css either for the whole portal or for a specific page.

Beyond skin objects

With the same process we can get some input from the site owner and put it in the DB. Then we can use that input in the skin.ascx to add logic to our skin code. So for example on some pages instead of the breadcrumbs skin object we show the page title or we don't show anything. Why not and small text parts in areas of the skin that panes are not appropriate. For example a custom message before the register link or two three additional links on the right of the login and register links. So in options.xml the skinner would be able to define custom tags that will return either a text or a Boolean value.

Conclusion

As I wrote, the implementation part of this post is imaginative. I have no idea if it makes any sense or not. What I wanted to do was to point out something that I see as a need in the DNN skinning market and then just imagine a possible solution from the perspective of a skinner.

I would love to read your thoughts in the comments.

Blog.10.0 Role Based Skinning

Vasilis Terzopoulos — Thu, 25 Jun 2009 08:58:00 GMT

Similar to the "CSS Selectable Pages", we shall keep adding efficiency to our skin code. This time we have a look at ways to reveal or conceal parts of our skin to the users according to their role or authentication. For example we could have a common header image for our guests and a more particular one for our members. Or even a special one for the users in a specific role. You got the idea.

There are not much to explain actually. Instead, all we need is small pieces of server side code. The reason these techniques are not so known to the public is because they are not documented. I'm doing skins for several years and have been in situations where I had to find solutions that common skinning techniques don't make it. It's about those small code hints that really make a difference but we need to spend time to discover.

How to check whether a user is authenticated in skin code

<% if Request.IsAuthenticated then %>
 skin code for authenticated users
 <% end if %>

Real world example: On the PokerDIY web site we have a "Take a Tour" link in the header which becomes a link to your inbox once you are logged in.

How to check user's role in skin code

<% if UserController.GetCurrentUserInfo().IsInRole("Special Members")  then %>
 skin code for registered users in the "Special Members" role
 <% end if %>

Real world example: On Seablick we replace the fancy header with a dynamic menu when logged in as Admin or Host.

I tried to give you some ideas but I'm sure you will find many other ways to use the above. I would love to read about your findings in the comments... Sometimes what seems to be obvious for you is well hidden for others.

Blog.10.0 Watercolors on transparent background

Vasilis Terzopoulos — Fri, 19 Jun 2009 14:38:00 GMT

That's the first collaborative work with my daughter! She's the one who put the colors on the paper. I scanned them and removed the background in photoshop. The result was interesting so I thought to make the images available for download.

There are four huge PNG images 3508 x 2552 px that can be used in many ways. For those who want to know how I removed the white background, the process is really simple. We just go to the Channels and Ctrl + Click on the RGB icon. Then Select > Inverse. Then copy and paste in a new canvas. To increase the color strength we can duplicate the layer, setting the blending mode of the new layer to Multiply.

Be creative!

Blog.10.0 CSS Selectable Pages

Vasilis Terzopoulos — Sat, 30 May 2009 13:32:00 GMT

Consider the following scenario. We have a portal with decades or hundreds of pages. Some of those pages include content that needs special styles to look good. Inline CSS is not an option as we talk about a good amount of CSS code. What we need is CSS selectors that will target on those specific pages. How can we do that?

Introducing CSS Selectable Pages

I always wrap my skin code in a DIV. It helps me in several ways, like avoiding CSS conflicts or writing styles for a page skin without having to create an additional CSS file.

That usually goes like this:

<div id="skinname" class="pageskinname">
 
 skin code
 
 </div>

Here comes the cool part. Wouldn't be nice if we could add a dynamic CSS class to this DIV? A CSS class that will be generated by DNN and will be unique for every single page of our site. Oh yes, that's what we need. And know what? It is possible and it's also dead simple.

 <div id="skinname" class="pageskinname page<%=PortalSettings.ActiveTab.TabID %>">
 
 skin code
 
 </div>

Isn't nice? Isn't great? How come I hadn't thought of this before? That's what came into my mind the first time I thought of this trick!

<%=PortalSettings.ActiveTab.TabID %> will generate the current page ID. So when we browse a page with ID=75, our code on the client will look like this:

 <div id="skinname" class="pageskinname page75">
 
 skin code
 
 </div>

Now we can go in the stylesheet editor and write some styles for this particular page.

 .page75 p { font:normal 1.1em/1.5 Tahoma,Sans-serif; color:#555; }

That's it. Simple and powerful. A technique that obviously adds efficiency to our skin code.

Blog.10.0 CSS Specificity

Vasilis Terzopoulos — Tue, 20 Jan 2009 02:03:00 GMT

I had a quick chat with a friend who was trying to override some CSS styles so he can change the look and feel of the Telerik menu for DNN and I thought to post some useful information that many others could benefit from.

It's about CSS specificity and I will not go in the details of this concept because it's well covered in several good articles, some of them are listed at the bottom of this post. I just want to point out that it is a concept that may not be so important on web sites that use one style sheet but within a framework like DNN where multiple CSS files and CSS overrides are so extensively used, it is really something that we need to be aware of.

Just to give a quick overview of the concept, every CSS selector has a weight which is called specificity. The more specific is a selector the more weight it has.

See this example:

span.text{color:red;}

	

.text{color:green;}

In the above we have two selectors that look similar but the first one is more specific (has more weight) because it targets only SPAN elements. The second targets any element with class="text" so it will not be applied on SPAN elements with class="text" because it can't override the first one.

If we want to override the first selector, we have to create another one with more weight like below:

div span.text{color:green;}

Keep in mind that specificity is more important than the order of the selectors in our sheets. So a selector with more weight will override another with less even if the second one came last in the browser.

Hope I gave you a very basic idea. Below you can find some good articles for further reading about the topic.

Blog.10.0 How to avoid the SPAN in the dnn:TITLE

Vasilis Terzopoulos — Mon, 19 Jan 2009 00:16:00 GMT

This is just an answer to a question posted on my twitter from @horacioj.

It's about how to avoid the SPAN and get a clean heading tag in a DNN container title.

Below you can see the code for a simple container that demonstrates exactly that.

 <%@ Control language="vb" AutoEventWireup="false" Explicit="True" Inherits="DotNetNuke.UI.Containers.Container" %>
 <%@ Register TagPrefix="dnn" TagName="TITLE" Src="~/Admin/Containers/Title.ascx" %>
 <%@ Register TagPrefix="dnn" TagName="Actions" Src="~/Admin/Containers/Actions.ascx" %>
 
 <dnn:title runat="server" id="dnnTitle" visible="false" />
 <% Dim ModuleTitle As String = GetPortalModuleBase(dnnTitle).ModuleConfiguration.ModuleTitle %>
 
 <div class="common">
 <h3><%= ModuleTitle %></h3>
 <dnn:Actions runat="server" id="dnnActions" />
 <div id="ContentPane" runat="server" />
 </div>

I have to mention though that with this implementation, the inline title editing won't work.

Blog.10.0 An easy way to test containers

Vasilis Terzopoulos — Fri, 26 Sep 2008 11:52:00 GMT

If you ever tried to create a set with several containers, I'm sure you have seen how time consuming can be, to apply one by one the containers you have created so you can be sure that everything looks and works as it should.

DotNetNuke from the very early versions, give to the skinners the ability to preset the usage of a specific container in a pane. This concept is known as Pane Level skinning. Take a look in the following code:

<div id="ContentPane" runat="server" containertype="L" containername="SkinName" containersrc="ContainerName.ascx" />

The containertype, containername and containersrc are the attributes we're talking about. Let's see what they mean.

containertype

With this attribute we tell DNN whether our container is stored under the \Portals\_default\Containers\ directory or under our \Portals\{portal ID}\Containers\ directory. In the first case the containertype needs the value G and in the second the value L.

Just a reminder here that we store our skins and containers under \Portals\_default\, when we want to make them available to all portals that will be created with our DNN installation. Instead, when we put them under \Portals\{portal ID}\, they will be available only to that specific portal (for example \Portals\0\).

containername

This is the name of the folder where our containers reside in, which is also the name of our containers set. For example \Portals\0\MyContainers. There is no default value and we use just the name of the folder, not the full path.

containersrc

This is the file name of the container we want to apply, which is also the container name. For example \Portals\0\MyContainers\MyContainer.ascx. There is no default value and we use just the name of the file, not the full path.

All three attributes are required. If we forget one of them or there is an error with one of their values, the default DNN container will be applied.

This concept intended to give the skinners the power to override the Portal Level container in situations that this is suitable. With Portal Level container we mean the Portal Container the administrator has been selected in the Appearance section in Site Settings. The administrator is still able to override the container has been preset from the skinner, applying a new container as Module Container in Module Settings.

Portal Container - set by Administrator
Pane Container - set by Skinner
Module Container - set by Administrator

The problem with this concept is that the containertype, containername and containersrc are not standards compliant attributes. So if we want our skin code and therefore our site to validate, we cannot use them in production. But I find them extremely useful during the development. Instead of going in Site Settings or Module Settings and apply the containers I want to test again and again, I just change the file name value of the containersrc attribute in my skin code.

Blog.10.0 How to fix the DNN File Manager appearance

Vasilis Terzopoulos — Fri, 26 Sep 2008 09:15:00 GMT

Sometimes the File Manager does not fit in the content area. I got this issue in many skins that use vertical navigation. To fix it, we just have to put a fixed width using the FileManager CSS class in skin.css or in portal.css which is easier for administrators because they can edit this file in Site Settings (Stylesheet Editor). We can also use the !important keyword to make sure that our style will be applied no matter what.

.FileManager{width:680px !important;}

In the above, we can adjust the width upon our skin's needs.

Another thing that looks annoying in the File Manager when our skin's default font size is larger than 11px, is that many labels or even the file names in the list, wrap and the whole thing becomes a mess. Adding one more line in our skin.css or portal.css, we can fix that too.

 .FileManager{width:680px !important;}
.FileManager *{font-size:11px !important;}

In general, we can update about anything in the File Manager appearance using the FileManager CSS class. For example we could also add a background color or change the font color, to make it look OK with skins that use a dark background.

I hope you find this tip useful.

Blog.10.0 DotNetNuke CSS hierarchy

Vasilis Terzopoulos — Sun, 21 Sep 2008 23:47:00 GMT

If you ever tried to view the source code when a DotNetNuke page is loaded in the browser, you probably noticed that there are several CSS files attached in the head area. In this article we'll try to break down this concept and understand how it works and how we can benefit from it. I think it's essential knowledge for administrators who need to make simple tweaks to the appearance of their DNN web sites, but also for developers and designers who make their first steps into the module and skin development.

Not only on a DNN web site but even on a single static web page, when we attach more than one CSS files, the styles that are included in all of them will be applied to our document. Many web designers use this method to separate their styles so for example they can have one stylesheet to control the layout, another one for the typography and so on. Another common technique is to have browser specific stylesheets, like one that includes styles only for IE6. Using IE conditional comments, we can attach this stylesheet only when the the request comes from a user with IE6. This technique has been very popular lately.

DotNetNuke makes extensive usage of this method but not for the reasons we described above... at least not until version 04.09.00 where having browser specific stylesheets is also possible. We need to talk a little more about this method so we can better understand the DNN reasons.

Let's assume we have two CSS files attached to an HTML document and both of them include the same classes and style rules. What will happen in this case? Which styles will finally be applied to our page? Here comes the interesting part... The styles that are included in the second CSS file will override those in the first one. In the following example the font size of our paragraphs will be 14px.

<link rel="stylesheet" type="text/css" href="Stylesheet1.css" />
<link rel="stylesheet" type="text/css" href="Stylesheet2.css" />

Stylesheet1.css
p{font-size:12px;}

Stylesheet2.css
p{font-size:14px;}

The browsers load the CSS files from top to bottom. If they find the same rules in two or more files, they apply the one found last. Even in just one CSS file, when a rule exists more than once, the lower in our CSS code is the one that will be applied. Let's see now how DNN uses this method to offer a flexible solution to developers and administrators.

The following list of CSS files is what we usually find when we view the source of a DNN page.

/Portals/_default/default.css
/Portals/0/Skins/SkinName/skin.css
/Portals/0/Skins/SkinName/container.css
/Portals/0/portal.css

Well, we can find more but let's keep it as simple as possible for now. Later we will see when and why more CSS files find their place in this list. Two of the above files are really important, the first one (default.css) and the last one (portal.css).

/Portals/_default/default.css

This is the first stylesheet that we will find attached to all DNN web sites. It is responsible to bring some style to our pages no matter what. We can describe it as a fall back solution... when there are no other styles to be applied, our pages will still have some basic format with styles that come from this file. As you can understand, all CSS files to follow can override this one.

/Portals/0/portal.css

Like default.css, we will find portal.css attached to all DNN web sites but this time at the end of the list. The zero in the middle of the path is the portal ID. As you probably know, with one DNN installation we can have more than one portals and each one of them will have its own portal.css that can be found at /Portals/PortalID/portal.css.

On a fresh DNN installation, this file includes a list of CSS classes without style rules in them. These empty classes are there to give us an idea of what this file is all about. The portal.css is the last one in our list so we can use it to override styles that exist in the other CSS files. Can you now tell what those empty classes are? I guess you can! They are classes we can also find in the default.css but in the default.css they are not empty. So the DNN guys have kindly put the names of the most common default CSS classes in portal.css for us to have quick access and be able to override them, giving a personal touch to our DNN web site. Quick access means that all we have to do to edit this file, is to go to our Site Settings and open the Stylesheet Editor. Oh yeah... the file we're editing in there IS the portal.css. Cool eh?

Anyway, the point is that using the Stylesheet Editor, we can override not only the default DNN styles but also skin styles, container styles and module styles. But let's walk the bridge and move on to the next level. Are you following?

DotNetNuke CSS hierarchy

Having a better understanding of how things work, I think we can now talk about the DotNetNuke CSS hierarchy. With the term "CSS hierarchy" we mean which CSS files will be at what position in our list and why. So let's first create a quick diagram and then we'll get into the details.

1. default styles: default.css
2. module styles: module.css or styles that come from module templates
3. skin styles: skin.css, PageskinName.css, container.css, ContainerName.css
4. administrator styles: portal.css

There are two categories we have not examined yet, the module styles and and the skin styles. We need to make clear though that the files these styles reside in, are optional and we will not find the same files attached to all DNN web sites... not even from page to page on the same DNN web site.

Module styles

DotNetNuke module developers have the ability to optionally define CSS styles that will be applied to their modules, in a file called module.css. The number of module.css files we will find attached to a page of our DNN web site obviously depends on the number of modules we have put in our page and how many of them do have a module.css. If there are more than one, the order they will appear in our list is the same with the order the modules appear in our source code.

/DesktopModules/ModuleName/module.css

Some more advanced modules support templates. This means that the appearance of the module can be controlled with additional files, usually HTML and CSS. As administrators we can alter these files or add a new template and then select it from the admin interface of the module. The templates usually live under the module's directory. Can be something like /DesktopModules/ModuleName/Templates/Templatename/. So when a module supports templates and the template we're using includes a CSS file, for example template.css, this will appear in our list under the module.css of that module.

/DesktopModules/ModuleName/Templates/Templatename/template.css

The CSS files that are responsible for the appearance of the modules, come after the default.css in our list so the module developers can override the default styles, but also come before the skin styles and administrator styles, so either with a skin or using the Stylesheet Editor, we can override the module's styles and make it look good upon our needs.

Skin styles

Before we talk about the CSS files that can be included in a skin, we need to explain that a skin may have one or more page skins. Page skins are the HTML or ASCX files that are included in a skin and define the structure of a page. We call them page skins because they can be applied on pages. A simple and common example is the home page skin and the inner page skin. The home page skin is the one we can use for our home page and usually has a more complicated layout, with more panes. The inner page skin is the one we can apply to the inner pages of our site and usually includes two or three panes.

Now let's see how many CSS files can be included in a skin. First of all the skin.css. The styles that we put in skin.css will be applied to all page skins. Then comes the PageskinName.css, for example home.css or inner.css. The styles we put in the PageskinName.css will be applied only to PageskinName.ascx or, to make it more familiar, the styles we put in home.css will be applied only to home.ascx and can override the skin.css styles.

/Portals/PortalID/Skins/SkinName/skin.css
/Portals/PortalID/Skins/SkinName/PageskinName.css

In most cases the skins include also a set of containers. The containers have their own place under the DNN directory which is the /Portals/PortalID/Containers/. A set of containers consists of one or more ACSX or HTML files, a container.css file and one or more containerName.css files. As in the skins, the container.css will be applied to all the containers and ContainerName.css will be applied only to ContainerName.ascx. When there are more than one ContainerName.css, the order they will appear in our list is the same with the order the containers appear in our source code.

/Portals/PortalID/Containers/SkinName/container.css
/Portals/PortalID/Containers/SkinName/ContainerName.css

DotNetNuke version 04.09.00 introduced a new skin object that give us the ability to attach even more stylesheets to our pages. The new skin object's name is "Styles" and its purpose is to allow skinners attach browser specific stylesheets. The position of these files can be defined from the skinner to be either at the top or at the bottom of the list.

How to identify an element's CSS class in the browser

Now that we know how CSS works in DNN, we need a way to identify an element's CSS class so we can override its styles. With the evolution of the browsers this is not a problem. All modern browsers have tools, either built-in or developed as plug-ins, that make this task really easy. Opera has built-in Developer Tools. We can find them under Tools > Advanced. In Google Chrome the only thing we have to do is right-click anywhere in a page and select the Inspect element option. For Firefox there is Firebug, an excellent tool for everyone and a must-have for developers. Internet Explorer users can install the Developer Toolbar and Safari users the Web Inspector.

Summarizing we can say that the DotNetNuke CSS file system and hierarchy, probably seems to be too complicated for the newcomers. Believe me, it's not that much. After a few hours of practicing, we can enjoy the power and flexibility of this platform.

Blog.10.0 The Styles Skin Object

Vasilis Terzopoulos — Sun, 21 Sep 2008 09:08:00 GMT

DotNetNuke version 04.09.00 introduced a new skin object that give us the ability to attach even more StyleSheets to our pages. The new skin object's name is "Styles" and its purpose is to allow skinners attach browser specific stylesheets.

The code as we can find it in the new default skin:

<dnn:STYLES runat="server" ID="StylesIE6" Name="IE6Minus" StyleSheet="ie6skin.css" Condition="LT IE 7" UseSkinPath="true" />

Of course it has to be registered first.

<%@ Register TagPrefix="dnn" TagName="STYLES" Src="~/Admin/Skins/Styles.ascx" %>

And here is the description of its attributes as we can read in the /Admin/Skins/Styles.xml

Condition

Internet Explorer specific condition. All valid conditional expressions are allowed, for example "LT IE 7", "gte IE 7" or "(IE 6)|(IE 7)". See MS MSDN Library for more information.

IsFirst

Boolean value that defines whether the stylesheet link should be loaded as first link or not. If false, the link will be added as last.

Name

String value that will define the ID of the stylesheet link

StyleSheet

String value that contains the path to the style sheet that needs to be loaded. The path is relative to the root of the application.

UseSkinPath

Boolean value that, if set to true, will make the reference to the Stylesheet relative to the path of the skin.

Cambrian tastes really good, don't you think?

Further resources

DNN Tips & Tricks #3: Conditional Stylesheets

Blog.10.0 Add Flash content to your skins, the right way

Vasilis Terzopoulos — Sat, 07 Apr 2007 09:16:00 GMT

February 5, 2009
Update: This post is pretty old... there are many tools out there now that you can use to embed Flash content on your skin or web pages.
Check this out: http://flowplayer.org/tools/flashembed.html

I'll show you how to put Flash content in your DotNetNuke skins using the SWFObject. In case you're wondering, here is why this method is much better than the default Adobe's embed method:

You get rid of the "Click to activate and use this control" message in IE
Can be used in valid HTML and XHTML documents
It's search engine friendly
The script also includes Flash plug-in detection and
Support for the Adobe Flash Player Express Install feature

Before you try to use the SWFObject in your skins, it is recommended to read all details about it at the official page as I'm not going to explain how it works or describe its features further. What we are going to accomplish is to import the SWFObject in our skins so we can then use its methods to embed Flash content either in our skin's code or in our DNN pages that use this skin.

Here is the simple process:

Download the SWFObject which comes in a zip file with examples of usage in static pages
Extract the zip to find the swfobject.js and put it in your skin's folder
Put the following line of code at the top of your skin's code:

If you're using ascx files:

<script type="text/javascript" src="<%= SkinPath %>swfobject.js"></script>

If you're using html files:

<script type="text/javascript" src="swfobject.js"></script>

That's it! Now every time you want to put Flash content either in your skin's code or directly in your pages (using a Text/Html module) you can use the following code:

 <div id="myFlash1">This text is replaced by the Flash movie.</div>
 <script type="text/javascript">
 var so = new SWFObject("myFlash1.swf", "myFlashTitle", "400", "200", "8", "#336699");
 so.write("myFlash1");
 </script>

You need to put a second one?

 <div id="myFlash2">This text is replaced by the Flash movie.</div>
 <script type="text/javascript">
 var so = new SWFObject("myFlash2.swf", "myFlashTitle", "400", "200", "8", "#336699");
 so.write("myFlash2");
 </script>

Easy eh?

Here is a quick explanation of the above code:

First we create a DIV with a unique ID that will be used by the script to put in it our Flash content. If our guest's browser doesn't support JavaScript or Flash, the text we put in this DIV will be visible.

<div id="UniqueID">This text is replaced by the Flash movie.</div>

Then we create a new instance of the SWFObject using JavaScript.

var so = new SWFObject("myFlashFileName.swf", "myFlashTitle", "Width", "Height", "RequiredFlashPlayer", "BackgroundColorHEX");

And then we replace the text in the DIV with our Flash content.

so.write("UniqueID");

Of course there are much more you can do with the SWFObject. You can add more parameters, you can pass variables to your SWF, either directly or from the URL string... but I won't say more. Further details on the usage of the SWFObject you can find on the official page.

Pay attention on using the right path!

When you use the SWFObject to embed Flash content in your skin's code and your Flash file is in your skin's folder then your path should look like the following:

<%= SkinPath %>myFlashFileName.swf

so when you're creating a new instance of the SWFObject the code should look like this:

var so = new SWFObject("<%= SkinPath %>myFlash1.swf", "myFlashTitle", "400", "200", "8", "#336699");

The above applies to both HTML and ASCX skins! DotNetNuke won't fix the path in HTML skins when it's part of JavaScript code.

But when you want to put Flash content directly in your pages using a Text/Html module, then you should use absolute path. So if your Flash file is in the root of your portal, the code should look like this (considering that your portal's ID is 0):

var so = new SWFObject("http://www.yoursite.com/portals/0/myFlash1.swf", "myFlashTitle", "400", "200", "8", "#336699");

That's all you need to know to use the SWFObject with your DNN skins. I think it's painless but still if you know other solutions, I'd love to hear about them so let me know in the comments!

Blog.10.0 Two words before skinning

Vasilis Terzopoulos — Sat, 24 Feb 2007 08:29:00 GMT

I don't want to disappoint or discourage anyone but I feel that I have to point out some simple facts about DotNetNuke skinning.

To put it straightaway, when we talk about DotNetNuke skinning we talk about a pretty simple process with a pretty quick learning curve. But the point is that a DNN skin is not just some special tags and content panes. To design and then develop a DNN skin means that you know at least the basics about web design. How to produce optimized graphics using photoshop or any other graphics software, how to code an HTML page and how to apply CSS styles, is essential knowledge someone who wants to create a skin must have. Even further, when someone wants to produce professional and high quality skins, have to be a professional and skilled web designer.

So, before start thinking about how to create your own custom DotNetNuke skin, be sure to ask yourself about your web design skills. If you don't do that, you'll end up thinking that a custom DotNetNuke skin is a very painful process which is not true... not at all.

Blog.10.0 DotNetNuke Links and Clicks

Vasilis Terzopoulos — Mon, 19 Feb 2007 13:37:00 GMT

Let's see an idea of tracking any link on a DotNetNuke web site and then producing a report with the most popular links. For this task we'll use two DotNetNuke modules that come out of the box, the Links and the Reports. To help you decide if it worths your time, I'll show you how to produce reports like the ones I have put on this page.

As you probably already know, the Links module has advanced tracking features which means that when you add a new link, there are options to "Track Number Of Times This Link Is Clicked? " and "Log The User, Date, And Time For Every Link Click?". When we check those checkboxes, we enable the tracking for this specific link. We'll use only the first option for now, as we just want to check the popularity of our links and the number of clicks is just fine for that.

What you probably haven't thought is that using this feature, we can track any inline link on our web site. All we have to do is to place a hidden Links module somewhere, add a link and copy the tracking URL which automatically will be produced by DotNetNuke. Then we can use this URL instead of the real one to put the link in our text. I have to say thanks to Tom Kraak who introduced this simple but valuable idea to me.

I'll add here a link to Cathal's Free DotNetNuke Modules. Mouse over this link and see what appears in your browser's status bar. This exactly is what we're talking about.

The Cathal's URL is:

http://www.cathal.co.uk/Default.aspx?tabid=80

but the URL I use is:

http://www.thinkofdesign.com/LinkClick.aspx?link=http://www.cathal.co.uk/Default.aspx?tabid=80

which gives me the ability to track the clicks on this link.

Let's do it together and see how it works.

Place a Links module somewhere in your web site and set its visibility to "Page Editors Only" to prevent your guests from viewing this module.
Add a link to thinkofdesign.com (oops! just kidding), add any link and check the "Track Number Of Times This Link Is Clicked?" checkbox. I consider you know how to add a link. Click Update.
Right click the link you just created and "Copy Link Location" in FireFox or "Copy Shortcut" in IE.
From now on you can use this URL every time you want to link to this web site in your text. And you can do that as many times as you want and anywhere in your web site.
After the first click, a simple report will appear at the bottom area of this link's edit page. Just click the small pencil on the left of the link and you'll find it.

But what if we have lot of links we want to track? And how can we find out which one is the most popular? We have to browse each one's edit page and write down the clicks. No! There is a much better way to do it and here comes the second part of our task. As we initially said, we'll use the Reports module here.

With the Reports module we can pretty easily bring to light any data from our database. All we need is some SQL magic to write the query that will open the door. I am totally newbie with SQL queries but with a little education I was able to accomplish this simple task.

Before we use the Reports module we'll need the ModuleId of the Links module with the links we're tracking. To find that, we just browse the Module Settings and we find it in the URL (it's /ModuleId/345/ in my case).

So, we place a Reports module somewhere in our web site (I created a new Reports page) and then we browse this Module's Settings. At the bottom of this page we find the Report Settings and then the Data Source Settings and the field where we can put our query. Here comes the query I used:

SELECT Url,CreatedDate,Clicks FROM UrlTracking WHERE ModuleID='345' ORDER BY Clicks DESC

This will produce a report with the Url of the links we're tracking, the date we created them and of course the clicks. The most popular link will go first. In the Display Settings we choose the Grid Visualizer. We can also Enable Paging and Sorting or Show a Header above each column with the results. We click Update. Cool eh?

There are cases where the Url of the link we're tracking isn't so descriptive and we need the title of our link. But the titles of our links exist in another table of our database so here the query becomes a little... longer (I spent half an hour to write this):

SELECT Links.Title,UrlTracking.CreatedDate,UrlTracking.Clicks FROM Links,UrlTracking WHERE UrlTracking.Url=Links.Url AND UrlTracking.ModuleID='345' ORDER BY UrlTracking.Clicks DESC

This will produce the same report but instead of the Url, we can see the titles of the links we're tracking.

Check my Reports page.

That was all about it! What do you think?

Blog.10.0 Tom's new DNN blog on Seablick.com

Vasilis Terzopoulos — Fri, 12 Jan 2007 18:38:00 GMT

I'm so excited to tell you about this one! Tom Kraak, the owner of Seablick.com, is my business partner in NY but also a very good guy and a very good friend. During the last year, many times we discussed about the creation of his own blog. He knows DotNetNuke inside out and he's so involved with DotNetNuke business, I was sure that his blog will be a good resource for many people.

Tom's DNN blog is here, coming along with a new optimized skin for Seablick.com ;) Still with several things in beta but I'm sure you'll find it interesting!

Did I mention that he's a proficient consultant and a SEO freak?

Check it out: Seablick.com

Blog.10.0 "Subscribe to RSS" browser support

Vasilis Terzopoulos — Tue, 21 Nov 2006 11:09:00 GMT

I'm sure you have noticed that when you're browsing some web sites, an orange RSS icon appears on the right of the Firefox address bar or in the new Internet Explorer's 7 icon toolbar. This icon makes the subscription to this web site's feeds quick and easy. We just have to click the icon once to find out the available feeds and subscribe to the ones we want.

You can add this feature to your web site just by adding the line below in the head section of your default.aspx page:

	<link rel="alternate" type= "application/rss+xml" title="Feed Title" href="Feed URL" />

Feed title can be anything. Just use a title that describes your feed better, for example RSS: Articles or RSS: Forums.
Feed URL is the absolute path of your feed.

Of course you can add more than one feed by just adding one more code line with a new title and URL.

Blog.10.0 PageTitle: The hidden DNN skin object

Vasilis Terzopoulos — Wed, 08 Nov 2006 09:05:00 GMT

Follow these steps to activate the PageTitle: The hidden DNN skin object skin object for your HTML skins.

Log in to your DNN site with your host account.
Browse the Host > Module Definitions page.
In the Modules list find the [Skin Objects] label (usually the first in the list).
Click the small pencil on the left of the [Skin Objects] label.
You are at the Edit Module Definitions page. Scroll that page to find the list with the controls.
Click the Add Control link to open the Edit Module Control page.
In the Key field write PAGETITLE.
In the Source field there is a drop down menu where you have to find the DesktopModules/PageTitle/PageTitle.ascx.
Click update at the bottom of that page.

The PageTitle: The hidden DNN skin object Skin Object is now available to your DNN site and you can use it in your skins. You can also include a CssClass property with it to apply CSS styles.

The PageTitle skin object in DNN 4.x

DotNetNuke 4.x does not include the PageTitle skin object out of the box. So if you want to make it work in your DNN 4.x web site, you have to either install the skin object from DNN 3.x or put the files manually.

To install the skin object from DNN 3.x, find the zip file which is located in the (DNN 3.x root)\DesktopModules\PageTitle folder, and then install it at your DNN 4.x web site following the common module installation process.
To put the files manually, you have to copy two files from DNN 3.x to DNN 4.x. These are the ~\DesktopModules\PageTitle\PageTitle.ascx and the ~\bin\DotnetNuke.Modules.PageTitle.dll

The PageTitle in ASCX skins

In ASCX skins you don't need a skin object. Use the code below to get the title of the page you're browsing:

 <%=PortalSettings.ActiveTab.TabName %>

I found this tip among others on Snapsis forums. Check this thread: DotNetNuke Tokens: Some tricks for getting more than SkinPath in your skin.