I’ve been working on implementing DotNetNuke at work for a few weeks now. After finally getting the hand of skinning DotNetNuke and building a custom skin that mimicked the look of the design provided by Marketing, I wanted to create a set of styles for formatting text. This would allow users to format text (and other elements) with a pre-set look and not have to use font-size, font-color and other outdated markup, thereby creating uniformity and smaller page/code sizes.

Well, after trying many attempts using the FCK Editor settings, I found the steps necessary to implement a set of custom CSS styles in DotNetNuke using the FCK Editor.

  1. Add your customs styles to portal.css in the portal root (Site Settings > Style Sheet) and save. These styles will be applied to your module text outside of the editor.
  2. Create a text file: FCK.xml. Here is where you will define styles to appear in the style list inside the FCK editor.
  3. Using the information in the FCK Editor Wiki help site, create your custom styles in FCK.xml. There should be an entry for each style you want to appear in the editor and in the order you want them to appear. See example below.
  4. Create a text file: FCK.css. These styles give the formatting to the styles you defined in FCK.xml so text in the editor will be formatted properly.
  5. Add your custom styles to FCK.css. This file contains ONLY your custom styles which are exactly the same as the custom styles you added to portal.css. There should be an entry for each style in FCK.xml you want to format.
    Using these lists limits the styles that appear in the editor to only those you want, rather than the long list of styles in portal.css.
  6. Upload FCK.css and FCK.xml to your portal root using the File Manger.
  7. Log in to your portal as Host and edit an HTML/Text module with the FCK Editor.
  8. Select “Show custom editor options”
    Select “Portal” for Settings Type.
  9. Expand “List of available styles for the editor”
    Select “URL” for Style list generation mode. Do not choose “Dynamic” or you will get a style list of garbage.
    Select “File” for Custom XML file, and select FCK.xml you uploaded to the root.
  10. Expand “Editor area CSS”
    Select “URL” for CSS Generator mode. Again, do not select “Dynamic”.
    Select “File” for Custom CSS file, and select FCK.css you uploaded to the root.
  11. Confirm “Apply custom settings to: Portal” and click “Apply”
    Close the FCK Editor custom options page and Cancel module editing.

  12. Refresh your browser with Ctl-F5 to force a refresh of the cache.

The list of styles should appear in the editor now. If you don’t see your styles and the formatting is not right, you might try deleting files in your cache. Also, check for mistakes in FCK.xml, FCK.css and portal.css. They must all be in sync and correct.

Here is a sample FCK.xml adapted from FCK:

<?xml version="1.0" encoding="utf-8" ?>

<Styles>
 <Style name="Image on Left" element="img">
  <Attribute name="style" value="padding: 5px; margin-right: 5px" />
  <Attribute name="border" value="2" />

  <Attribute name="align" value="left" />
 </Style>
 <Style name="Image on Right" element="img">
  <Attribute name="style" value="padding: 5px; margin-left: 5px" />

  <Attribute name="border" value="2" />
  <Attribute name="align" value="right" />
 </Style>

 <Style name="Title" element="span">
  <Attribute name="class" value="Title" />
 </Style>
 <Style name="Topic" element="span">

  <Attribute name="class" value="Topic" />
 </Style>
 <Style name="Custom Bold" element="span">
  <Attribute name="style" value="font-weight: bold;" />

 </Style>
 <Style name="Custom Italic" element="em" />
 <Style name="Title" element="span">
  <Attribute name="class" value="Title" />

 </Style>
 <Style name="Code" element="span">
  <Attribute name="class" value="Code" />
 </Style>

 <Style name="Heading H1" element="H1" />
 <Style name="Heading H2" element="H2" />
 <Style name="Custom Ruler" element="hr">

  <Attribute name="size" value="1" />
  <Attribute name="color" value="#ff0000" />
 </Style>

</Styles>

And corresponding FCK.css:

body, td {
font-family: Verdana, Sans-Serif;
font-size: 13px;
}

.Title {
font-family: Ariel, sans-serif;
font-size: 16px;
font-weight: bold;
color: red;
}

.Topic {
font-family: Ariel, sans-serif;
font-size: 14px;
font-weight: bold;
color: red;
font-style: italic;
}

.Bold {
font-weight: bold;
}

H1 {
font-family: arial, sans-serif;
font-size: 1.7em;
font-weight: bold;
color: #006699;
}

H2 {
font-family: arial, sans-serif;
font-size: 1.3em;
font-weight: bold;
color: #006699;
}

Those steps worked perfectly. Now I’ve just got to create the XML file to match the CSS file. I’ll go ahead and complain. It seems like there should be an easier way. Second, I don’t like the way it applies the styles. If I have a style “.red” (to make the text a specific shade of red) and I’ve got a style .bold (to make the font-weight:bold), DotNetNuke applies each one in a separate SPAN tag. I guess chaining CSS styles (span class=”red bold”) is too complicated.

Ugh! I guess this is the trade off. Moving the tedious task of menial updates to the users means uglier code underneath.

It seems that on Friday, my hosting provider, EuroVPS decided to perform another upgrade. This time they added PHP 5 support and upgraded the PLESK control panel to version 8. As with their previous IP address change, things didn’t go so well, at least on my end.

The upgrade killed all my permanent links, meaning that anyone looking for the “House for Sale” page or the Top 10 Spider-Man 4 Villains story, got a 404 error page.

Seems they’ve disabled custom php.ini support, but added limited support for clean URLs in Windows IIS. I had to change my URL structure to accommodate this, so any Search Engine Indexing will be incorrect now.

UGH…

Playing around with DotNetNuke again today for work and the CSS implementation leaves a lot to be desired. For some reason (open source? – multiple contributors?) the CSS has hundreds of redundant definitions and the code base itself adds unnecessary or at least unwanted IDs or CLASS tags to everything.

Rather than have a single FONT-FAMILY declaration, it was declared on almost every style. Instead of BORDER, BORDER-RIGHT, BORDER-LEFT, BORDER-TOP, and BORDER-BOTTOM are used. It’s really insane. Almost every element of content gets assigned with CLASS=”Normal” and put inside a DIV with a uniqe ID ending with ModuleContent.

All of this rambling led to a cool way to assign CSS properties to certain elements based on Wild Card characters. This only works with Firefox, but if you’re trying get Firefox to display something differently than IE, it can be a big help.

/* all DIV tags with an ID ending in ModuleContent */
div[id$=’ModuleContent’] {
border:2px #000 solid;
}

/* all A tags whose HREF attribute ends in .pdf */
a[href$=’.pdf’] {
border:2px #000 solid;
}

Works great for debugging browser differences as well. Anyway, back to cleaning up the DotNetNuke default.css file. I’ve already got it pared down to 14k (from the original 18k).

The decision was made at work to start moving content to a Content Management Systems. IT wants to move to mostly Microsoft products, so we chose DotNetNuke as the CMS platform.

I wasn’t overly excited. Much more info is already available for PHP systems like Drupal (or even WordPress), not to mention the size of their development community.

Anyway, DNN 4.5 seems to be a nice release. Much easier to install and I think I’m getting the hang of it. Thanks to Microsoft’s lack of standards support, a total CSS layout is out of the question. DNN likes to drop and add columns depending on where you’re at in the system and it requires a full page for the Inline Editor.

I did manage to generate a nice layout using a one row, three column table to hold my layout divs. This allows DNN to drop and add the columns without messing the formatting up.

This site has also be a great resource for skinning (creating a theme) for DotNetNuke. The Dreamweaver extension is also nice and gives you easy access to all the necessary placeholders for DNN content.

Computerworld published an article entitled “Top 10 Firefox Extensions to Avoid” and of course I had to read it. Some of their choices were odd, most I agreed with and one made me write this post.

ScribeFire (formerly Performancing)

This falls into the category of extensions that seem pointless. What we have here is a browser-based tool for writing blog posts. But don’t most blogs already have a browser-based editor that works just fine?

Perhaps there’s a blogging system out there that needs this kind of helper app, but we’re not familiar with it. Until we come upon such a beast, we’d rather skip the overhead of an extension and stick to our blogging software’s built-in editor.

Don’t get us wrong, ScribeFire is a nice piece of software. We just don’t see a need for it at this time. If you do happen to be using blogging software without a decent editor, ScribeFire would be a fine addition to your extension toolbox.

Yes, WordPress and other blog engines have build in editors, if they didn’t, they wouldn’t be very useful, now would they? I think they’re missing the point with ScribeFire. The nice think about this extension is I can post to my blog without having to go there. I can keep all my tabs open in Firefox, click back and forth between them, copy and paste, and all the while, the ScribeFire window stays in place below. It makes it terribly easy to reference what you’re writing about. If I used the WordPress editor, I would have to click back and forth between tabs or have multiple windows open to do the same thing.

Sorry ComputerWorld, but you missed the mark on that one.