SourceForge DNN News Zips

by Phil 'iwonder' Guerra

- (Mission, KS) - In case you need a previous version of the DNN News module, you can still find them at SourceForge. These previous versions are no longer available on the DNNN Downloads page. Thanks to Jan Olsmar for the info. Of course, you could opt to use the XML/XSL module instead, which basically performs the same type of functions as the previous v03.00.xx module.

Some folks are reluctant to move to the new DNN News module due to the 'breaking' issues reported in the forums. My advice for folks is to install a version of the new News module in a test environment ONLY. Then, evaluate the issues BEFORE moving it to Production areas.

If you are using a lot of non-RSSv2.0 newssources with custom XSLs, these will not work with the new module, and you'll need to move the setup information into an XML/XSL module. There is NO backward compatibilty provided with the new module.

All of your newssources will be converted to DNN's custom RSSv2.0 format, which may not include all of the content you may have provided for with a custom XSL. Some newssources are failing due to using non-standard formatting in the pubDate, and author elements. Validation is strictly enforced with DNN v04.00.00 with an XSD. The issues prompted a 'fix' to the code, which will relax the validation requirements. The Beta version is close to release on this fix, however, there may be other issues that are not fixed in this newer release.

So, again, my recommendation:

Install a version of the new News module in a test environment ONLY. Then, evaluate the issues BEFORE moving it to Production areas.

Note: Currently DNN offers downloads on the Codeplex site. Thanks to Sebastian Leupold for the updated information. As of 3/10/2009, the DNN Codeplex site has versions:

Released |

	04.00.01 Nov 3 2008, Stable
	04.00.00 Aug 21 2008, Stable
	03.01.01 Jun 21 2006, Stable
	03.01.00 Jun 9 2005, Stable

Can't See the Tree for the Forest...

by Phil 'iwonder' Guerra

-- (Mission, KS) - A question popped up on the forums the other day asking a simple question, 'Why would the 4.0.0 upgrade not preserve XSLs?'. My answer was to offer that the module was completely redesigned and the new design took a path that changed how news feeds were handled. The module takes an incoming news source file, converts it to a 'standard' RSS v2.0 feed. This processing is needed only for the aggregation of dissimilar feeds, but is forced in the case of a module setup for just single feeds, which is what most folks have with existing modules using the previous version of the Newsfeeds (RSS) module.

You can combine different feed formats into a module for presentation, but they all must ultimately be in the same format. The trouble with this design is that the underlying conversion of feeds has issues that you would never see without digging into the code. Mostly, when that type of issue happens, the feed will just throw an exception saying the feed could not be downloaded, or you get errors in feed validation. I've been working on testing the beta correction to the issues with the new module, but what I found last night was that many of these types of errors could probably be attributed to feed conversion issues rather than due to the validation of the final feed formatting. I'll take about that more in another entry, though.

My main point with this entry is that many folks are seeing a lot of extra work because they lost all of the formatting in their feeds if they used a custom xsl for presentation. The new module only allows 3 basic xsl choices. One of them really doesn't work well, the Horizontal Ticker. Now, you can write a custom xsl for your feeds that are converted to the RSS v2.0 DNN standard, but it has to be written for the DNN RSS v2.0 format, which is very limited in what it will include from a feed. Again, this is due to the need to have content that is similar, with a small subset of the RSS v2.0 elements. Basically, what you get is similar to the RSS v0.91 content.

Now, on the way to work I had a thought. Why not just add a Module 'Mode' option? You could allow a module to be setup that only is used for 'Single Feed' Mode, and an option for 'Aggregate' mode. The 'Single Feed' mode would allow the user to specify the URL, and the XSL for use in presentation, without worrying about having to conform to one standard presentation format. If the mode is 'Single Feed' you don't have to use the logic that converts the incoming format to the DNN RSS v2.0 format. You would just use a custom xsl for the feed type you are using. Sounds simple enough, right?

Well, that's the theory. Now, in practice, more is required. The beauty of one standard presentation layer is that users don't have to think about the type of feed format their chosen feed is in, the module takes care of it all. However, I think that with a little more effort, a feed can be analyzed, and then present the results to the user, or give a dropdown of available xsl choices to use for the feed type. Admittedly, that's more work, but it is a slicker, backward compatible design.

Now, with a site that is already using different types of news formatted feeds, and custom xsl files, the upgrade would simply default to 'Single Feed' mode, and use the existing settings for use in the new module setup. Thus, you preserve the existing feed setup, and the loss of functionality by merely upgrading is gone.

That's my thinking this morning, anyway. Instead of not seeing the 'tree' for the 'forest', you can actually see the 'tree' and if you want to see the 'forest', you can do that too!

Let me know what you think?

Progress - News Beta Testing...

by Phil 'iwonder' Guerra
--- (Mission, KS). While testing I found some Atom feeds failing to download. It's strange, but I did manage to get at least one to download and display, but others failed. I took a look at the conversion xsl files in the RssToolKit.

I actually found a line in the AtomToRss20.xsl that seemed to be the culprit, moreso than the date cnversion, although there is an issue with that too. The basic reason why it wouldn't load was becasue the conversion xsl has an invalid directive:

<xml:output mode="xml" encoding="UTF-8"/>

This was probably throwing an error during the attempt to convert it or download it. I put the xsl into my xsl editor, with an input Atom xml file, and it choked, with an error: The namespace prefix is not allowed to start with the reserved string "xml". So, I replaced that line with this one:

<xsl:output method="xml" encoding="UTF-8"/>

Then, it began to work. The date conversion routine had issues too, with not producing a proper formatted date. I corrected that issue, too. I'll send the updated xsl file to Peter, as soon as I can go through the other files in the RssToolKit.

Strange thing, though I don't know why one of the feeds I tested, actually did work.?!? I'll have to go back to that one, to check it out more closely.

Now, after looking at the conversion xsl again, I noticed some other issues with it. For example, the title links to a comment area, and not the actual article. More work needs to be done.

DNN Make Feed Display on All Pages

by Phil 'iwonder' Guerra
--- (Mission, KS). A common question about the News Module, or any DNN core module for that matter, is how to make it show up on all portal web pages. It's pretty simple, but can be easily overlooked. Here's the simple solution, most modules have an option that give an administrator the option to display it on all pages.

In the news module, just go to the module settings, expand the Advanced Settings area and check the box next to the settings label:
Display Module On All Pages?

This will display the module in all of the pages. I use it to display a Headline ticker in the top pane on all of the pages.

Most core DNN modules work the same way.

Localized RSS Date Time...

by Phil 'iwonder' Guerra
--- (Mission, KS). Not sure why folks want to change the pubDate format given in a newsfeed. I have nothing but trouble when I try to base anything on pubDate. I can understand the desire to show feeds with localized date/time, but seems like a whole lot of trouble to go through. My experience with most feeds generated is that they don't even reflect correct information in about 80% of the usage I've seen. The discrepency usually can be attributed to developers not understanding how to correctly use date/time fields and convert them, and the further complication of date/times being formatted in databases based on the server date/time setup, which may not be correctly setup or maintained.

It's really puzzling to me how RSS specs decided to use the RFC822 date/time format in the first place. This was a standard developed for first gen email text messages. Peter's correct in that it was an American originated spec, but it did have a group of international folks working on it, which is why the format doesn't even match American date formats either. Now to really confuse matters, the RFC822 spec is really obsolete, the newer RFC2822 is the defacto standard. So, why in the world do we not use it? Well, it isn't all that much better for this type of usage, folks.

Perhaps a better standard would be ISO8601 (see a Wiki entry here. If you still are not totally confused, and want to press further, I suppose you are just bent that way, and since you are using MS prodcuts with DotNetNuke, you could prolly find a way to do this in the News module, since it's rewritting the incoming news source anyway. However, that brings us back to the lack of folks using any standard to start. Any code fix requires some kind of 'rule' to fallback on, and with many news feeds, there just isn't any reliability. Also, what do you suggest is used for the default language? Is it the portal setting for preferred language, the host server setting for language, or the end-user's machine language setting? Those questions have never been answered in the core DotNetNuke code. I know because, I tried to get folks to make a decision on it, and never got any DNN Core Team members to attach enough significance to it to make it happen. It's still not resolved in the DNN.

In fact, to be fair, it's not really resolved in Microsoft's world either. Yes, I know about the Olson timezone, tz database in use on Unix, Linux, and other implementations. I am a member of the tz mail list, and over the years, even that solution goes through incredible changes in year, almost daily. I've come to the conclusion that until the world comes under one umbrella, there is not going to be a solution to please everyone. Although, if you need me to vote, I'd say hitch your wagon to the tz database if you can, at least it has provision for being used for historical context, supported by users throughout the globe, not just in Redmond.

Now, you can change the format using XSL, but it's a real chore to provide a solution that's universal and fully globalized. Most solutions are going to be local solutions as far as I can tell. I've done a bit of that stuff, but reverted back to not caring about it because most feeds don't always give you pubDate in the rfc822 format, and trying to figure out universal routines to deal with all the variances of gloablized date/time formats is difficult to say the least. So, I just take it as it is - much like the content in a feed.

I don't even like to validate the pubDate format because I'd rather worry about getting the content than stressing over whether the pubDate is valid and miss displaying the content. Maybe I'm funny that way, but my usage of feeds is not based on pubDate, and if I choose to cache, I think the better approach would be to simulate a ttl element based on the date/time I pulled the feed originally, if one is not available. I'd use whatever is there, if easily parsed, so I can display the pubDate as given, and still have control over timing for feed retrieval and display. Just my thoughts...

RSS XSL Stripping HTML

by Phil 'iwonder' Guerra

I get a fair amount of questions about how to handle transformations, either related to custom XML data islands or RSS newsfeeds. One question that seems to be near the top of the list is "How can I get rid of all HTML in the description of an RSS newsfeed?" Well, the answer involves a bit of study of the source, and then, a bit of tweaking, and testing of a custom XSL.

Searching the web, I located several examples of XSL functions that I could tweak to provide a flexible solution that integrates well into the DotNetNuke framework, either with the News module or the XML/XSL module. I found the code that worked the best for me at this URL:

http://code.techinterviews.com/xslt-to-strip-html/26

Stripping HTML Template

<xsl:template name="strip_HTML">
<xsl:param name="value"/>
<xsl:choose>
<xsl:when test="contains($value,'&lt;')">
<xsl:value-of select="substring-before($value,'&lt;')" disable-output-escaping="yes"/>
<xsl:choose>
<xsl:when test="contains(substring-after($value,'&lt;'),'&gt;')">
<xsl:call-template name="strip_HTML">
<xsl:with-param name="value"><xsl:value-of select="substring-after($value,'&gt;')"/></xsl:with-param>
</xsl:call-template>
</xsl:when>
<xsl:otherwise>
</xsl:otherwise>
</xsl:choose>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="$value" disable-output-escaping="yes"/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>

Using my basic XSL, I added the template for 'stripping-HTML' and tweaked it until it functioned as I needed. Now, it's just a matter of calling the template when I want to use it. In this case, I want to strip the HTML from the <description> element, so the call to the template is done this way:

<xsl:call-template name="strip_HTML">
<xsl:with-param name="value" select="description" />
</xsl:call-template>

DNN News Failing? Relax...

by Phil 'iwonder' Guerra

Woe is us, huh?!? The DNN News module is failing on many newsfeeds sources that worked without issue on the previous version. Why? Well, the new module places some very tight constraints on the incoming newsfeed used. They must be able to be successfully transformed into a valid RSS v2.0 to be displayed using the News module v04.00.00. Simply, a newsfeed will fail if the elements do not pass validation specified in the module's XSD file.

The problem is most newsfeeds do not care about conforming to any RSS spec, their developers do not understand what is needed, or the users creating them do not understand what to use in the placeholders to which they add content. Anyway you slice it, there is a problem that is causing many users to shy away from the new module, or move back to the previous version of the News module. There's even a thread to report a feed that does not work here.

Now, the issue is a hot topic on the forums, especially visible within the first few days of the modules' release. In the process of these discussion some folks found a workaround that takes the steps of relaxing those constraints, by modifying the modules' XSD file.

You can read about the issue here on the forums, or take a look at another's view of the situation here, which includes some detail on how to fix it. I've already commented on the issue, but am adding my fix, which is basically the same as Craig's. He beat me to posting it. No matter, because the point is folks needed a fix.

Since, I knew about the XSD issue, but didn't yet have the source, I couldn't fix the problem. The fix involves modifying the Rss20.xsd file located in the \Website\DesktopModules\News\RssToolkit\Resources folder. There you will find the description of the elements used to validate a feed which eventually gets transformed from its' source format, Atom, RDF, RSSv0.91, RSSv1.0 to RSSv2.0.

The constraints used to descibe some elements can be lifted entirely, or you could manage to ease them back a tad, depending on your capability and needs. I chose to relax them entirely for the elements using these custom types:

- tEmailAddress
- tRfc822FormatDate

<xs:simpleType name="tEmailAddress">
<xs:annotation>
<xs:documentation>Not Using the regexp definiton of E-Mail Address </xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="tRfc822FormatDate">
<xs:annotation>
<xs:documentation>A date-time displayed in RFC-822 format.</xs:documentation>
<xs:documentation>Not Using the regexp definiton of rfc-822 date </xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
</xs:restriction>
</xs:simpleType>

Making those changes, recompiling the module, and placing the resulting DotNetNuke.Modules.News.dll into the \Website\Bin folder fixed many of my issues. There are still some odd ones floating about, like constraints on image size, but this first set of mods, gives me the most benefit.

Now, is this the way to fix it overall? I don't think it is a 'best practice' by any means. I'm testing it at this point, so you can follow this example and test it yourself, or wait for the 'official' fix. My plan is to provide validation at the time of adding a feed, rather than validating after the feed is fetched. Also, I think it better to provide a gracefull correction to these issues by coding a way to provide a usable alternative element.

I'll post more details later. BTW - Thanks to Craig Hubbard for adding the information in the forums about how he fixed his issues. I was floundering about making the XSD changes, and didn't realize I had to recompile the project for it to pick up the changes.