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.