This morning I added images to the RSS feed HTML for all of the feeds on the CMS. Most of the feeds on the CMS are collections of News postings made by various functional areas. We have a page set up that indexes all of the live feeds on the CMS. If any of these News postings contain an image or are redirects to another news posting that contains image, that image will be displayed in the feed source. This only works for images which are in the default image placeholder control on the News template.

This appears to work in all major browsers and in the RSS Feeds component of Outlook 2007. For Outlook, I had to manually specify the height and width of each image because if you don’t Outlook will resize your image to 50×50 pixels for “security reasons”. I can’t quite figure out what those reasons might be, but fair enough. Now I trigger an additional callback to the Resource in the Resource Gallery that contains the image, render it in an Image Stream and access the height and width parameters to include in the img tag in the RSS.

We’ve successfully consolidated the News published by Public Affairs today. All news can now be found at http://go.middlebury.edu/news. This is the source for front page News items on the CMS, which previously had been drawn from a different News channel. This change should make it easier for Public Affairs to get their important stories onto the front page, since they won’t need to recreate them in a second location any more.

I made another News related improvement on the CMS yesterday that managers of Newsletters will appreciate. Each Newsletter has a set of pre-created “right nav objects” (check out SportsNotes to see what I mean), which are common design items that can be displayed on multiple Newsletter issues. Since the code for this was reused from a different part of the CMS, the right nav objects would only display if they were applied to the current channel. That’s fine when you want to display a link to the Initiative website on the front page of Supporting Middlebury, but not fine when you want to show this on every issue of a weekly (or daily!) Newsletter. You’ll be spending a lot of time setting up each channel to do this. Now, just for Newsletters on the CMS, the right nav objects will look to their parent channels to see if any are specified and inherit from there. This can be overridden at the issue level as well, allowing for variety if the author so chooses.

Newsletter administrators who want to know more about this should contact myself or Chris Norris.

When we first implemented the CMS here at Middlebury I was a summer intern working in a closet in Warner basement between stacks of printer cartridges and Dell driver CDs. One of my job responsibilities at that time was to fix any broken links on the CMS. To “help” me out, a script was created that sent an email to a central mailbox account every time somebody tried to access a page that didn’t exist on the CMS. In web terms, this is know as a 404 error. I received several thousand of these messages each day.

The volume of emails was too great for anyone to keep up with and so the script was turned off. We now rely on the sub-site content providers to maintain their own site and fix any broken links they might hear about from peers. Rather, that was the case until last night when I re-wrote the 404 Email script for our new CMS framework. Stephen Kiel, Technology Coordinator for the Career Services Office noticed a line in our CMS documentation which said:

“404 email notifications can be delivered to Content Providers upon request. Know about broken links on your sub-site as users discover them, very handy for large sub-sites with many channels/postings.”

As far as I can figure, this was to be a new feature of the MiddCMS framework that was just never added to the code, but was placed in the documentation. There is a section in the code that tries to log each 404 request to the server, but it is commented out with a note about performance concerns and even that doesn’t do what our documentation is saying we do. Still, the functionality is simple enough. We just need a configuration file with the email address of a person to whom we’ll send an email and the part of the site they’re concerned with, then just parse the configuration file every time you get a 404 message and send them the email with the information. This took me about a half hour to put together, with some time to add error handling for parsing the configuration file and other concerns.

Now we can send our content providers an email letting them know that a user wasn’t able to get to a site within their sub-site just by adding a line to an XML document like this:

<ErrorMails>
<ErrorMail path=”/administration/cso” email=”imcbride@middlebury.edu”></ErrorMail>
</ErrorMails>

With that in place, I would receive an email for every bad request to anything under “/administration/cso” containing two URLs. The first is the address to which the user attempted to get, such as http://www.middlebury.edu/administration/cso/does_not_exist.htm and the second URL would be the referer of the page request, if it exists. Typically, the referer will be the page the user just came from. This is useful so that the content provider can go to that page and fix any bad links to content that doesn’t exist. There are some times when the referer will be blank. The most common of these are:

1. If the user typed the page address directly into their address bar
2. If they used a bookmark
3. If they clicked a link in an email

There are certainly other scenarios, but those are by far the most common for our site. So if you want this functionality for your sub-site, just let us know by sending an email to the Helpdesk requesting it. I’ll be glad to add your email address to the list!

The updates to the web environment that we performed over the holiday break, including updating the MCMS database to use SQL Server 2005 and applying MCMS Service Pack 2 with a ton of fixes went forward successfully. There were a couple bumps in the road after applying the changes, but for the most part the upgrade went well. One of the most glaring changes caused a rendering issue with many pages on the CMS, namely those in which the content flows around another framework element, like a picture. The two most prominent of these pages were the Language Schools and Schools Abroad home pages.

As you can see, the content doesn’t properly flow around the “post it” in the upper right corner of the content area. I was able to track down this issue to the editing interface we use for the CMS, Telerik’s r.a.d. Editor, which in .NET 2.0 aparently inserts a style=”display:inline-block” attribute on the element where it renders the content from the editing control. This messed with our CSS, forcing the wrapping to break. I fixed this by manually adding a style element inline in the template that we use for these pages, like so:

<telerik:RadEditorPlaceholderControl style=”display:inline” id=”mainContent” Placeholdertobind=”mainContent” toolsfile=”~/RadControls/Editor/ToolsFile.xml” configfile=”~/RadControls/Editor/ConfigFile.xml” runat=”server” />

Problem solved! Or so I thought. I figured this would be the only place on the CMS where this particular issue would occur since I couldn’t recall where else we were wrapping content around elements like this. Unfortunately, I forgot about the News template, which wraps its content around a picture with a caption. My colleague, Brett, helped me track this down by looking through the Telerik support forums and finding that the display:inline-block style is hard coded into the control and can’t be easily removed from the editor. We could override the whole control and implement our own styles, or we could force a global append of the correct style. We chose the latter as it meant writing one line of code, rather than several and changing every instance of the editor throughout the application.

  protected override void OnPreRender(EventArgs e)
  { 
    foreach (RadEditorPlaceHolderControl editor in FindRadEditor(Page))
    {
     editor.Style.Add(“display”, “inline”);
    }

   base.OnPreRender (e);
  }

 Now it’s fixed everywhere and the CMS seems to be running well in the new environment.