Extension talk:Bullet Feed

This is my first public extension and have yet to really dive into code and make something really useful. I know that other great php programmer on this site have made probably better structured scripts for the same thing, but I couldn't find one that I could readily put in a minimalistic format such as found on http://hdwiki.nmu.edu. If you have any questions, comments, etc, feel free to email me at cperry@nmu.edu -03:42, 6 February 2008 (UTC)

Updates

 * Updated the links algorithm again to take into account $wgServer instead of computing my own.
 * -muraj 07:17, 3 April 2008 (UTC)


 * Fixed descriptions not parsing html into html code.
 * Implemented a more portable algorithm for parsing default links
 * Default site address is now http://domain_name/$wgScriptPath
 * -muraj 15:43, 28 February 2008 (UTC)

Couple of changes
I made a couple minor changes to the code - adding $wgExtensionCredits so it appears in Special:Version and changing the alt URL generator slightly ($header). I dug into $wgTitle and found that there are quite a few methods for URL generation which helped with that task. $site and $link in feedAction can probably be optimized quite a bit (I didn't spend too long trying to decode what was going on in $link). They both seem to work OK for me though so I left them alone. Thanks for the extension. 67.97.209.36 22:41, 29 July 2008 (UTC)

Possible to use RSS page as normal viewable page too?
Is it possible to use the bullet-list page as a normal viewable page too? i.e. so it doesn't display the  and  tags on the page? I already have a bullet list "news" page so this extension could be ideal... Thanks Jonathan3 07:08, 24 September 2008 (UTC)


 * To answer my own question... the bullet points between the  tags do get displayed as normal; however, the description between the  tags don't get displayed on the wiki page. The extension seems to work very well. Jonathan3 18:58, 2 October 2008 (UTC)


 * There is a reason for this, I was thinking on making this optional in a future edition, but I really wanted to keep the layout of a bulleted list for a minimalist headline for a frontpage, and that they could access the same content albeit more detailed via the rss action page. -muraj 01:20, 4 October 2008 (UTC)

Minor amendment - change link on item's title
Some of my bullet points had links to several wiki pages (in the RSS title as opposed to the descriptions). The code picks the first one and makes the RSS item link to that. To work round this I changed it so that the link is always the "Recent Changes" page of the wiki. I know this isn't ideal, but it saved me some trouble rejigging my bullet points. Change the relevant line to: $i=new FeedItem(strip_tags($title),$desc[1],'http://www.mysite.co.uk/Special:Recentchanges',$Date=wfTimestampNow-$titlekey); I've not made any changes to the code on the extension page. Jonathan3 18:58, 2 October 2008 (UTC)


 * This was intentional too, as the need at the time was one link per title, which really is all you need if you make your headlines correct. Though this assumption is true for most cases, I would like to make it more robust to have it optionally select a site, as well as optionally have it dynamically set a site (the first site) or have a tag to set a static site. --muraj 01:28, 4 October 2008 (UTC)


 * ''There is also a reason for the $link.'#'.striptags($title). Some readers grab new items based off whether the link has been read or not, not based off the publication date.  The anchor I append to that makes it so that the reader will see the new items regardless if this happens. --muraj 15:53, 6 October 2008 (UTC)

Minor amendment - display text inside rss-desc tags on wiki page
All links in the description work on the RSS feed whereas in the title only one can be used (the first one is selected, unless you make the amendment above). So I decided to use the rss-desc tags after all - but the text between the rss-desc tags doesn't get displayed on the wiki page. I wanted to use the rss-desc tags (so that multiple links in the news item could be shown) and wanted the content to be displayed on the wiki page as well as on the RSS. I changed the relevant line to: return $parser->recursiveTagParse($input).''; I have NOT made any changes to the original text on the Extension page :-) Jonathan3 19:24, 2 October 2008 (UTC)


 * This "hidden" text is a feature, but you're right, I should make this optional to the feed. --muraj 01:33, 4 October 2008 (UTC)

RSS autodiscovery doesn't seem to work on IE7
...although it works fine in Firefox. Jonathan3 20:01, 2 October 2008 (UTC)


 * Not sure why this is, make sure you clear your cache for both the wiki and your browser. I use the   tags in the feedparse function to have the rss icon show in the browser.  Not sure what IE7 looks for, but it worked on both at the time of submission. --muraj 01:39, 4 October 2008 (UTC)

Links within description text work with Google Reader but not Google home page
On Google reader the links work fine, e.g. http://www.mysite.co.uk/Page name On i-Google home page the links render as, e.g., http://www.google.co.uk/Page name  Does anyone know why this is? Jonathan3 22:07, 2 October 2008 (UTC)


 * I've heard of this issue, I'm not sure as to the cause, I will look into it. --muraj 01:40, 4 October 2008 (UTC)

More serious amendment - constant pubdate for each item required
The code as it stands on the extension page doesn't seem properly to assign a pubdate to each item. It basically uses the date at the time of the most recent refresh. The effect is that if you have 10 items, the RSS reader adds those 10 items on every refresh, so that in no time the reader will have 100 or 200 items for your feed instead of 10. To make the pubdate fixed for each item, I used the following work-around.

The bullet points are in the format:
 * 01/01/08: Something happened today Detail
 * 01/05/08: Something happened on 01/03/08 as well Detail

I wanted to make the first date on each bullet point become the pubdate, so made the following change. Remove the following line (which you might have already amended: see above). $i=new FeedItem(strip_tags($title),$desc[1],$link.'#'.strip_tags($title),$Date=wfTimestampNow-$titlekey);

Replace with: $pat = "([0-9]{1,2})/([0-9]{1,2})/([0-9]{2})"; $regs = array; if(ereg($pat,$title,$regs)) { $datetimestamp=mktime(0,0,0,$regs[2],$regs[1],$regs[3]); } $i=new FeedItem(strip_tags($title),$desc[1],'http://www.mysite.co.uk/Special:Recentchanges',$Date=$datetimestamp); [NB The reference to http://www.mysite.co.uk/Special:Recentchanges can be left as before, i.e. $link.'#'.strip_tags($title) -- see above for the reason I made this change]

This seems to make sure that each feed item has a constant date, rather than one which changes on each refresh. Note that the date has to be in the format DD/MM/YY with leading zeroes where necessary. US users might want to change this to MM/DD/YY by changing the relevant part to $regs[1],$regs[3],$regs[3]

I hope this makes sense. If someone can verify that the php code works then perhaps this final change could be made to the code on the Extension page. I haven't made any changes to that page.

Best wishes Jonathan3 21:55, 3 October 2008 (UTC)


 * Yes, this was sort of a hack as I was looking for a dynamic method of adding in the dates and removing them when the elements were deleted at the time of user manipulation. I'm still debating several options for this, none of which seem very clean.  I do not want the user to have to input a date, this should be automatic and the format should be easily modifiable to whatever to user wishes to show on the page.  This was going to be a future feature, but as I'm lazy, I haven't gotten around to it :-).  The reason I implemented the above was to make it work with particular RSS readers (the Firefox add-on mentioned on the bottom), it should be more robust.  --muraj 03:17, 4 October 2008 (UTC)