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.
Sunday, March 29, 2009
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>
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
--- (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.
(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.
(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.
--- (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.
Subscribe to:
Posts (Atom)
