Tuesday, May 5, 2009

DNN Core Team Not Working on Improving Internal Syndication

by Phil ‘iwonder’ Guerra (Countryside, KS) -

I finally got a response to my question about what was being done to improve DNN’s internal syndication. The answer: N-O-T-H-I-N-G. That’s right nada, zip. I guess there are too many other pressing matters to deliver a commercial version of DNN that doesn’t have the many holes that the ‘community edition’ has in it.

Ah, well, I guess I’ll do my own thing, even if it breaks with every new release. It’s really a shame that I hear DNN needs help with this and that, and folks offer to help, and never get any contact from the gods on the mountain. Makes me wonder why anyone is trying to do anything for DNN for free.

Thursday, April 30, 2009

DNN News v4.0.01 Custom XSL - pubDate Sorting

by Phil 'iwonder' Guerra (Happy Rock, MO) -

First, in order to provide aggregation features to the module, all feeds used in the News module must be converted to an RSSv2.0 type of feed, which I'll call a DNN_RSSv2.0 format. The intention and goal was to allow different formats of feed sources to be aggregated, and rendering such a diverse collection called for some type of standard format, and RSSv2.0 was chosen.

So, how do you render a feed sorted by pubDate? Well, here' s where some of that sanitation and validation of source news feeds pays off. The News module takes an incoming news feed source, validates it, and transforms it into a new RSS feed, and one of the elements used in this process is a special custom namespace element called, pubDateParsed. This element is created during the transformation process, and turns out to be handy for providing a simple way to sort the item elements by it. You can see the feed that the module creates by looking at the database table for the News module, and looking at the data in the Cache attribute. I suggest copying an example, and pasting it into a text file for review, but here's what an example item element contains:

<item>
<description>Polish prosecutors are raising the death toll from a fire that ripped through a homeless shelter in mid-April to 23 after DNA ...<p>
<a href="http://feedads.g.doubleclick.net/~at/RWMBZpjtAANqdf4thEFQrwJI_pI/0/da"><img src="http://feedads.g.doubleclick.net/~at/RWMBZpjtAANqdf4thEFQrwJI_pI/0/di" border="0" ismap="true">
</img>
</a>
<br/>
<a href="http://feedads.g.doubleclick.net/~at/RWMBZpjtAANqdf4thEFQrwJI_pI/1/da"><img src="http://feedads.g.doubleclick.net/~at/RWMBZpjtAANqdf4thEFQrwJI_pI/1/di" border="0" ismap="true">
</img>
</a>
</p>
<img src="http://feeds2.feedburner.com/~r/usatoday-NewsTopStories/~4/O6aWvd6_g_Q" height="1" width="1"/>
</description>
<link>http://rssfeeds.usatoday.com/~r/usatoday-NewsTopStories/~3/O6aWvd6_g_Q/2009-04-30-poland_N.htm</link>
<pubDate>Thu, 30 Apr 2009 15:16:07 GMT</pubDate>
<pubDateParsed xmlns="http://www.dotnetnuke.com/modules/news">2009-04-30T15:16:07</pubDateParsed&gt;
<title>DNA results in; Poland raises fire death toll to 23</title>
</item>

The pubDateParsed element uses the pubDate information to convert it to a sortable format date, although there is no real support for its use yet, we can create a custom XSL to 'activate' it. All we have to do is add the sort statements to the default.xsl and save it as a custom xsl.

Here's how it works. We use the pubDateParsed element and define a custom namespace to declare it. Then, add the sort function call, feed it the sort key, and sort order. Resulting in the XSL that follows...

<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:dnn="http://www.dotnetnuke.com/modules/news">
<!-- DNNv4.0.1 pubDateSortDSC -->
<!-- by Phil 'iwonder' Guerra -->
<!-- 2008-11-23 -->
<!-- Use with attribution please -->
<xsl:output method="html" indent="yes"/>
<xsl:param name="ItemsToShow"/>
<xsl:param name="ShowItemDetails"/>
<xsl:param name="ShowItemDate"/>
<xsl:param name="Locale"/>
<xsl:template match="rss">
<xsl:for-each select="channel/item[position()&lt;=$ItemsToShow or $ItemsToShow&lt;1]">
<xsl:sort
select="dnn:pubDateParsed"
data-type="text"
order="descending"/>
<p class="DNN_News_ItemLink">
<a href="{link}" target="_main"> <xsl:value-of select="title"/>
</a>
</p>
<xsl:if test="$ShowItemDate='true'">
<p class="DNN_News_ItemDate">
<xsl:value-of select="pubDate"/>
</p>
</xsl:if>
<xsl:if test="$ShowItemDetails='true'">
<p class="DNN_News_ItemDetails">
<xsl:value-of select="description" disable-output-escaping="yes"/>
</p>
</xsl:if>
</xsl:for-each>
</xsl:template></xsl:stylesheet>

I just create 2 custom XSL files, one to sort ascending and the other sorts descending. Then, I choose which one I want to use in the module instance setup. It's pretty simple once you understand what the module is emitting and giving you.

Hopefully, the next version will add support in the setup to allow passing a sort order, and the option to sort. Until then, you'll need to create two versions, one that sorts ascending and another to sort descending. Of course, you could add support to the News module yourself, which I did, but I would not advise it, as custom work done once to a DNN module needs to be done over and over as new versions are released. Sometimes the effort is worth it, others may not be. This is one of those times where it's not really a good idea, in my opinion, I am comfortable with having the two versions handy, all I have to do to change the sort order, is just specify the desired custom XSL in the module setup.

Wednesday, April 29, 2009

DNN News Module - Bridging the Gap

by Phil 'iwonder' Guerra (Avondale, MO)

"I know nothing is perfect, but..." That's a line I hear so much in my day to day work. Seems my job as a Technical Coordinator, System Administrator, System Analyst, Programmer, and Technology Trash man is knowing enough about imperfection to provide workarounds for those times when software or circumstances fail to reach their mark, and leaves a huge gap. Most of these moments come to me at the 11th hour in a project that I knew nothing about, because Directors or Project Managers didn't think I would be needed at the early project meetings. Anyhow, if you work in IT, you know what I'm talking about. So, what has this to do with the DNN News module?

Well, though the News v4.x module is a ambitious step forward, there are a few gaps that folks have pointed out. (Read the DNN News forum) I've been openly critical of some of these gaps, only with the intent of making it better. I have the utmost respect for the project leader, Peter. I know the personal and professional challenges in taking on any project with such a huge following, having too few resources to help, and the politics of not being able to bring innovation too quickly. So it is with the News module.

I've had a little custom XSL hanging about unpublished, as I thought maybe the gap would be filled with the next release, and it still might be. The real question is when, though. Since, I've gotten enough email about the issue, I decided, I'd go ahead and publish a solution. This custom XSL is my little innovation to bridge one gap, the lack of a sorting routine, which hopefully is in the works.

I will present a way to provide sorting by a news feed's pubDate element, using a custom XSL specifically for the DNN News v4.0.1 module in the next post.

Monday, March 30, 2009

DNN Internal Syndication - Branding Syndicated Content

by Phil 'iwonder' Guerra - (Avondale, MO) - As you’ve probably seen, the latest versions of browsers provide a quick interface to syndicate newsfeeds and present them with just a few clicks of a button. It’s a nice feature, and for those folks that don’t want to use a stand-alone news reader, it offers a quick link to keep up with their favorite web sites. The one problem with using a browser to present a news feed is most do not support use of your site’s Channel details to be rendered. That’s an unfortunate situation, as it takes away one of the primary reasons for creating syndicated content. No doubt many companies would like their company icon and a brief note about what they offer, displayed with their syndicated content. However, browser technology is deciding what to render, whether you like it or not, and your site's channel details are often left out. The end result is you may be missing out of a marketing opportunity to brand your syndicated content when it is used with browsers.

Using Microsoft’s Internet Explorer and Apple’s Safari, you get a feed rendered, and only the Channel Title is displayed. With the FireFox browser, you may get the site title and description. So, what can you do about the situation?

The simple solution with DNN is to always include an entry that contains that information. However, that approach may not be possible if the module you are syndicating doesn’t give you an opportunity to do it. This simple solution may be impractical depending on how many module instances you have that offer syndicated content because you have to add an entry item for each one. Implementation of internal syndication varies by DNN module, so there is no one set way to achieve the solution.

Another approach that I took involves adding a bit of code to the DNN core, RSSHandler.vb. You’ll find this code in the /Library/Services/Syndication folder, with DNNv5.0.0. The bit I’ve added calls a simple routine to always add an item to syndicated content, which includes the Portal title, description, and you could add graphics if you choose to do it. Now, when a users clicks the syndicate icon, and their browser renders it, they will get the Site branding displayed as a newsfeed item.

The code I’ve added may not be best practices, but it’s working for me, and the client is happy, and that’s the most important item of all. Here’s the code, and note after you’ve added it, you can just choose to build the library from VS2005 or VS2008 to implement it. I place the call to the routine right about the line that checks searchResults, this way I always add my site branding item, even if there are no other items available. In fact, RSS v2.0 specifications state that there should always be at least 1 item in a feed, so this makes DNN internal syndication more RSS v2.0 compliant.

Channel.Items.Add(AddSiteBranding())

If searchResults IsNot Nothing Then….

Next, the routine that adds the site branding item:


Private Function AddSiteBranding() As GenericRssElement

Dim item As GenericRssElement = New GenericRssElement()
item("title") = GetPortalSettings.PortalName
item("description") = GetPortalSettings.Description
item("link") = AddHTTP(GetDomainName(Request))
item("pubDate") = Now().ToUniversalTime.ToString("r")
item("guid") = AddHTTP(GetDomainName(Request))
Return item

End Function

Now, be sure that you add only item tags that match what the feed is already adding to maintain consistency in your newsfeed. The result gives you a syndicated feed that displays your Portal Name, along with the Description of your portal. Now, when folks syndicate it in a browser, you’ll have a bit of a marketing edge always available. I’ve thought of some other variations of this type of branding, including adding some database items and using a routine to fetch items randomly. Otherwise, what is being displayed actually comes from your Portal’s information. Hopefully, you are using the Host Administration page to add your portal description, which is the source for this information. You can even add an image to the Portals description textbox to add more branding to your feed.

Here’s what an example implementation looks like in IE8, the first item in the feed is the branding item.






Of course, you might want to make the other core code changes I’ve mentioned in previous installments on my blog to get other enhancements. I use a slightly modified version of the Announcements v4.0.1 and vw_Search SQL view in conjunction with this change.

Sunday, March 29, 2009

News v4.x Module Recommendation

by Phil 'iwonder' Guerra - (Mission, KS) - I can’t say I’m a big fan of the new version of the DNN News v4.x module. It’s not the effort, as the DNN News project team has done quite a bit of work on this module updating it, adding features that a lot of the DNN community was asking to be included. The trouble for me is more with certain aspects of the implementation of the changes, and the lack of any support for the previous version of the module. One of the major additions to the module was the inclusion of the feature to aggregate many news feed sources into one News module instance. This aggregation feature comes at a price, and the old expression, ‘be careful what you wish for’, rings out again.

The main trouble with the DNN RSSv2.0 custom newsfeed translation is the lack of support for foreign namespaces, and support for all of the tags in the RSS v2.0 specification. The result of the custom newsfeed is a compromise that is made to make the aggregation of news sources with differing news specifications structure possible. The News module was intended to support RSSv0.91, RSSv2.0, Atom, and OMPL news feeds. However, testing and the News Forums are full of reports of the module failing to present Atom, OPML, and some RSS feeds that worked with the previous version News v3.0.1.

Why is there so much trouble with the News v4.x version of the module? Good question, and there are a variety of answers. Perhaps the single point of failure is in the underlying validation and translation methods of the module. Remember, the module must take and translate feeds from a variety of feed types, and translate it into a version of a feed that can be readily consumed. The compromises made required only a minimalist approach in producing a RSS v2.0 compatible news feed. RSS feed types vary widely in their use and availability of XML tags used in their news feeds. Some like the pubDate element do not exist in the Atom or OPML item elements, and others like author, have a strict definition in the RSSv2.0 specification. During the initial read of a news feed source, the module must be able to rely on the RSSv2.0 specification to help transform or reject the incoming elements to produce the resulting custom DNN RSSv2.0 news feed that is ultimately presented. Sadly, even news feed providers do not follow strict adherence to RSSv2.0 specification, as in the cases of the tags, pubDate, and author. If an incoming news feed source cannot be validated it will be rejected the newsfeeds fails to be presented, which generates the most common error, ‘feed failed to download’.

Another issue with the new module is the lack of support for the previous version. If you have a number of news feeds already in use on a site using the News v3.x version, updating to the new version wipes them out and converts them to using the new methods. This type of upgrade effectively creates issues as the new validation methods most often will fail, especially in cases where custom XSL was used to present a feed. The process results in the news feeds used previously not to be rendered. This situation is due to the forced usage of the new methods even for cases where no aggregation of feeds is needed. A better approach would be to allow the module to specify a usage flag to indicate whether the module is being used in a ‘single’ or ‘aggregation’ mode. If the ‘single’ mode was chosen, the simple presentation model of the older module could be used without disrupting existing usage on a site.

While the News project team did try to relax the validation of the pubDate element, it’s not always possible to fix the issue with this type of method. Many other elements have a strict usage specification, and cause news feeds to fail. In practice, there are very few RSS feeds that can be used with the News v4.0.1 module without errors of some type, or missing essential attributes. So, what’s to be done?

Well, my recommendation is to avoid using the News v4.x module entirely, and use the XML/XSL module in its place for presenting single news feeds on a DNN website. Of course, you can remove the module and load the older News v3.0.1 version of the module, too. Both of these alternatives allow use of custom XSL files to present a newsfeed. However, even this approach will not please everyone, as some insist on having the aggregation features. For those circumstances, the alternative module Feed Explorer can be used, but it is harder to implement, and browser issues exist.

The above recommendation may anger some, but the number of issues being posted on the DNN News forums, are an indicator of the lack of success of the module in practical usage. Hopefully, the DNN project team will overcome the issues in the near future, or someone will offer a suitable replacement.

Wednesday, March 25, 2009

News v4.x Alternating color background...

by Phil 'iwonder' Guerra - (Mission, KS) - Sometimes you would like to change the look of your news feed presentation. One such possibility is alternating background color of a news feed item. It's fairly easy to do, but with the new version of the News module v4.x you must remember to fashion your new custom xsl to respect the parameters used in the module setup.

The simplest way to develop a custom xsl for the News v4.x module is to just copy the existing default.xsl which resides in the ~/DesktopModules/News/transformations folder. Use your favorite text editor and make whatever changes you need. Be careful to keep the parameters that are used in the default.xsl that match what is setup in the News v4.x module.

Now, after modifying your custom xsl, save the new file to your portals/n folder and change the module setting to use the new xsl. Always test your new xsl, either using a suitable XML/XSL editor, or in a test instance of your DNN site. Also, I find it works best to place your test News module in a special page of it's own, to avoid causing issues. If your test module fails to display with your new xsl, it could cause your site to 'freeze' or lock up, so you do not want to test a new moduel setup on your 'home' page.

Here's an example xsl that alternates the background of the items in a feed. Try it out and make it your own.

<?xml version="1.0" ?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" >
<!-- alternating background color -->
<!-- for use with DNN News module v4.x -->
<!-- by Phil 'iwonder' Guerra' -->
<!-- 2008-09-21 -->
<xsl:output method="html" indent="yes" />
<xsl:param name="ItemsToShow" /> <xsl:param name="ShowItemDetails" /> <xsl:param name="ShowItemDate" />
<xsl:param name="Locale" />
<xsl:template match="rss">
<xsl:for-each select="channel/item[position()<=$ItemsToShow or $ItemsToShow<1]">
<div>
<xsl:if test="position() mod 2 != 0"> <xsl:attribute name="style">background-color: #F5F5F5</xsl:attribute>
</xsl:if>
<p class="DNN_News_ItemLink"> <a href="{link}" target="_blank">
<xsl:value-of select="title" /> </a>
</p>
<xsl:if test="$ShowItemDate='true'">
<p class="DNN_News_ItemDate">
<xsl:value-of select="pubDate" />
</p>
</xsl:if>
<xsl:if test="$ShowItemDetails='true'">
<p class="DNN_News_ItemDetails">
<xsl:value-of select="description" disable-output-escaping="yes" />
</p>
</xsl:if>
</div>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>

Sunday, March 15, 2009

Back In the Saddle…

by Phil ‘iwonder’ Guerra

(Mission, KS)

Been awhile since, I last blogged.  Short explanation, I’ve had pneumonia, and slowly I  am getting back to feeling up to working on extra projects.  So, look for more blogs at regular intervals, hopefully, I can do at least one a week, but will really try to do more.

Sunday, January 4, 2009

Updating the RSSHandler and vw_Search

by Phil 'iwonder' Guerra

--- (Mission, KS) - I've wanted a better DNN internally generated news feed for quite some time. I had so much work in my queue that updating the DNN core code was one project held back. For the most part, I left the project up to the Core Team, afterall it is core code.

Well, I'm not satisified with the progress, and the DNN CT certainly has their priorities, and I'm not going to criticize the lack of attention, but I'm moving forward with taking on the project. It's not a very easy set of tasks to undertake, though. There's a lot involved, due to the coupling of the RSS feed generation to the Search mechanism, but I was surprised at how relatively fast I could deploy an improved news feed with a few minor changes to the RSSHandler, and the vw_Search SQL view. The results yield a much more rich RSSv2.0 feed, giving your public feed branding and support for many of the standard RSSv2.0 tags, not all mind you, but enough to allow you to syndicate with the internal methods, rather than a custom approach.

There's a lot more to be done, as I've only been targeting one module to incorporate the changes, the Announcements module. The enhanced approach requires some tweaking of a module's support of RSS, which is seriously deficient in most modules. I don't understand why most module's even have the ability to syndicate without providing support for it. Oh, well, that's another story.

I'll post more about the effort and provide the code in another post. Right now, it's time to celebrate my son's 21st birthday.

Cheers

Saturday, January 3, 2009

DNN v5.0.0 Internal Syndication - Part 2

by Phil 'iwonder' Guerra

(Denver, CO) - Don't know if folks recognized this issue just yet, because it seems to be new with the DNNv5.0.0 release. In the Announcements module, I noticed that my generated newsfeed had changed somewhat. In previous versions, an syndicated news item had the following format: ModuleTitle - AnnouncementTitle. So, if you had setup an Announcements module to syndicate, what you got when you clicked on the syndicate icon was something like this:

Announcements - My Actual Announcement Title

In fact, I read a recent post on the Announcements forums where someone asked how to change that format, getting rid of the ModuleTitle. He was told by the project lead that it was not possible. Huh? Now, I don't mean to be disrespectful, because as a former DNN Core Team Memeber, I did not advocate changing DNN Core Code, unless there was a good business reason to do so. Changing Core Code means there's impact when the code is eventually upgraded, your mod will need to be redone at the very least, at worst- your mod will not buy you anything because the method you altered might be obsolete.

However, I knew there was a piece of code that could be tweaked to do it, so I set off on getting rid of this annoyance. Before I started work on it, I loaded up an Announcements module, put in some content, and hit the syndicate icon. Lo and behold, what did I see? Well, instead of the ModuleTitle - AnnouncementTitle being rendered as the Title in the news feed, I was getting just the ModuleTitle for every Announcement in the feed. Oh, man what a terrible implementation. I had to do something.

Anyways, I went about making the small tweak in the Announcements module I was set to do, because, it looked like that was something that still needed to be done. I really don't think folks want the ModuleTitle as part of any syndicated content, at least in the items listed. From what I could see this type of concatenated string was being populated into the SearchItem table, and at least I could change that piece.

Long story short, I made the change, and although, I could see that the SearchItem table reflected the change, the resulting news feed was unaffected. Now that set me off on a long search for the culprit. I was about to give up for the night, I simply could not find anything in the code that could cause this new format to be rendered. I decided to take another approach.

I brought up the database, and looked at the stored procedures, thinking maybe a call to one of those procs was responsible. Still no luck. Then, I thought, maybe there's a View causing this issue. Well, it didn't take long to verify my thinking (there aren't many views setup in the DNN database). I found the following View, vw_SearchItems that contained the following:

SELECT
si.SearchItemID,
m.PortalID,
tm.TabID,
m.ModuleID,
m.ModuleTitle As Title,
si.Description,
si.Author,
si.PubDate,
si.SearchKey,
si.Guid,
si.HitCount,
si.ImageFileId,
u.DisplayName AS AuthorName,
FROM

dbo.dnn_SearchItem AS si
LEFT OUTER JOIN

dbo.dnn_Users AS u ON si.Author = u.UserID
INNER JOIN
dbo.dnn_Modules AS m ON si.ModuleId = m.ModuleID
INNER JOIN
dbo.dnn_TabModules AS tm ON m.ModuleID = tm.ModuleID

As you can see, the offending line, in bold and red, was responsible. Instead of using the information directly from the SearchItem table for the item title element, the module name was being substituted. Well, I changed the view to use the si.title data, and the results were immediate. Now, my announcement's news feed was correctly displaying the Announcement Title as the newsfeed item 'title' element. Something like this example:

My Actual Announcement Title

Now, you'll have to make the change in the code and recompile for every module that you want to show up without the ModuleTitle in the 'title' element, and that's a heavy chore. I'm hoping that the DNN CT will listen to an appeal to change this implementation. In case you want to look for the code for the Announcements, look at the code:

Announcements\Components\AnnouncementsController.vb

Search for the Function GetSearchItems, and in that routine is a line:

SearchItem = New SearchItemInfo(ModInfo.ModuleTitle & " - " & .Title, strDescription, .CreatedByUser, .PublishDate, ModInfo.ModuleID, .ItemId.ToString, strContent, "ItemId=" & .ItemId.ToString)

Change it to this line, which gets rid of the concatenation of the ModuleTitle '-' to the .Title:

SearchItem = New SearchItemInfo(.Title, strDescription, .CreatedByUser, .PublishDate, ModInfo.ModuleID, .ItemId.ToString, strContent, "ItemId=" & .ItemId.ToString)

Compile the Announcements solution, and replace the existing Announcements.dll with the newly created one. Then, make your change to the SQL database View as described above.

You can do this change yourself, as well if you want, but it does alter the Core code, so unless the CT decides that this is a better approach, your change will get lost when you upgrade.

Also, from what I can tell, any module that assigns a 'title' that isn't the module name will be changed as well, becuase the View change is a global.

Friday, January 2, 2009

vs2005 Error - The project type is not supported

by Phil 'iwonder' Guerra

(Mesa, AZ) - As if there aren't enough problems to sort out... This morning on my development workstation, which has worked fine until today, vs2005 studio is giving me the following error message - 'The project type is not supported in this installation.' Now, I'm not sure what it is that changed a project over the holidays, while I was away, but last week, I had no trouble loading this project.

Oh, well, happy new year. More on the issue, when I've found a fix. Until then, keep your workstation unplugged when not is use, avoid those pesky Microsoft Updates.

Thursday, January 1, 2009

DNN v5.0.0 Internal Syndication

by Phil 'iwonder' Guerra

--- (Phoenix, AZ) - With the New Year underway, I thought I'd start out right by installing and testing the new version of DNN v5.0.0. Installation went without a hitch, so no worries there. However, I'm just putting in some test content using the Announcements module to see what the DNN internal RSS news syndication is doing. Having been away from looking into that side of syndication with DNN, I was curious to see if anything new is available to us. Sadly, I can report that DNN internal RSS syndication is below par and is a real disappointment from an otherwise improved look and feel release.

Does anyone really think that a DNN news feed is worth anything? It's the barest form of RSS, and the implementation of what gets syndicated is really confusing. For example, the Announcements module has taken some strides in allowing a bit more flexibility, giving the user the ability to specify how much of the text content is used in the syndicated description. Trouble is - you can change this field, but it only affects items added after the change. Probably a caching issue somewhere, and not the Announcements module's fault, as there is no real indication that there is anything that limiting in the tables for it.

The other frustrating issue is how the syndicated content is built. With the Announcements module, the DNN created feed uses the module's Name for every entry as the title element. instead of the title of the actual announcement title, which is what I would expect. With this type of usage a DNN internal syndicated feed offers very little in the way of driving traffic to your site with it's lack of syndication features. Small wonder, then, that many DNN projects have gone to creating their own syndication routines. That's at least something, but it's not the best of world's. What is really needed is a standard syndication API that is followed by all DNN project module developers. Without this kind of API, DNN default projects and DNN syndication will always remain a mystery to users.

As I've blogged previously, there is a serious need to overhaul all of the default DNN standard modules to include better support of syndication. Every module capable of implementing syndication ought to have the basics information available to syndicate, title, pubDate, author, and description are really needed for a bare bones syndicated content. There are many many other useful options available, it's a real shame to see DNN so far behind in news syndication.

So far, I give it a failing grade, and hope that someone is working on improving it.