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?

DNN News Module Too Strict?

by Phil 'iwonder' Guerra

One thing that is difficult to manage is the aggregation of feeds without standards. Unfortunately, the strict enforcement of RSS v2.0 implementation is more for the aggregation rather than just the display of a single feed. At this point, I believe the DNN News module is being too strict, as most newsfeed sources will never all comply with the specs for any version of the RSS or Atom specs. One of the more common errors is in the display of date of publication, which is not even a standard element between RSS v2.0, RSS v1.0 (RDF), and Atom feeds. Also, the date formatting is totally out of whack for for a lot of feeds, even when somethings gives GMT as its' base, you cannot rely on the develper actually giving you that correctly.

Other troublesome elements are those that are supposed to include and email in the content, but only provide a name. This is a common error emitted for a lot of popular newsfeeds, but one easily avoided with including the Dublin Core namespace in a feed, and using one of the 3 included metadata elements that do not require email:

- creator
- publisher
- contributor

There are other DC elements that are useful, as well. In fact many newsfeeds incorporate them as extensions to whatever version RSS they emit.

The other option is for the DNN module to include the Dublin Core namespace and use one of the above elements in place of the RSS v2.0 author element when an email format fails, and always provide the associated DC element with the email stripped when one is present. In this way the feed validates and can be used without penalty.

With the apps I write for desktop, I just take this information without trying to validate it or use it for anything other than displaying it as given. If I can't make sense of a date element in a feed, I find it easier to fashion a date for sorting, or caching, which I take from the time I first bring in the element. It's not going to make a whole lot of difference in the presentation anyway IMHO. The main usage for me of having a pubDate is for sorting, and accuracy in attribution of the news source.

It's mostly a matter of lack of attention by developers writing the feed generators. We see it in the DNN modules as well. The whole point of specs is to keep folks from having to worry about issue with code that is supposed to be compliant. Of course, that's not what we see in the real information world. If auto makers disregarded safety specifications as much as developers, we'ld have pulled the offenders off the market. Unfortunately, there is no similar enforcement in our IS world.

I think going into this update, most didn't realize the number of newsources that were not compliant. If something says it's RSSv2.0 then it should be expected to be a valid feed. There's the trouble, even larger news providers don't offer compliant RSS, so it's something the industry just avoids by coding around it. In the end, that's probably what will have to be done in the module, because aggregation should not cause aggrevation.

DNN News Module v04.00.00 Released

The new release of the DotNetNuke News module brings some nice new features to the module. Peter Donker blogs about it on his DNN Blog. You'll need at least DNN v04.06.02 to integrate into your DNN website. Also, the new module has some gotchas, so visit the DNN News Forum for a review of the discussions.

Be aware that the new module is very strict in its' validating a newsfeed source, so don't expect all of your existing newsfeeds to work straight away. The issues causing folks so much trouble are mostly due to the lack of newsfeed providers to emit valid RSS feeds. The most troublesome aspect of all of all is that even certain DNN Core modules suffer this same condition.

Most feeds that are being reported as failing are due to validation failing on the newsfeed item elements that do not provide rfc822 dates or valid email information for elements that require them.

I've been using the module for a bit now, and will blog more about it later. For now, download it, install it in a test environment, and put it to the test. It's more advanced than the previous version, which only used a news source link to make a web request and transform it using xsl. The new module is the second DNN attempt at news aggregation (the FeedExplorer was the first). It works reasonably well, but newbies and some 'oldies' with little experience with RSS and newsfeeds will need help in using it out of the box. The strict RSS validation is rough going.

Also, new is the ability to use passed parameters to control some of the display of a newsfeed. You can control the number of elements and choose to display or not display the item date and details.

There are some included XSL files which allow scrolling and default look and feel. The basic approach is to provide a newsfeed display much like many new browsers are doing, but allowing several differnt types of newsfeeds, Atom, RSSv0.91, RSSv1.0 (RDF), and RSSv2.0 to be used without worrying the details. Of course, the implementation still needs some work, but the overall direction of the DNN News module is finally getting an update.

More on the module later. I'll have some tips, and workarounds posted for you.