Extension talk:WikiArticleFeeds/LQT Archive 1

Rename?
Whoops, didn't realize there was already an Extension called WikiFeeds out on Meta. In good conscious, I should rename this one. But to what? Now accepting suggestions. Thanks in advance. --Jimbojw 13:59, 5 January 2007 (UTC)


 * I haven't looked at the details of your extension, so if you can find a unique name that would be better, but if not we tend to use the username to distinguish, e.g. "WikiFeeds (Jimbojw)". --HappyDog 03:57, 8 January 2007 (UTC)


 * Thanks HappyDog - I'm thinking about renaming it to "ArticleFeeds" since that's essentially what it does: convert articles to feeds. --Jimbojw 18:02, 8 January 2007 (UTC)


 * Sounds good to me. --HappyDog 23:11, 8 January 2007 (UTC)


 * Done deal - just 'moved' it to Extension:WikiArticleFeeds. When the original WikiFeeds gets ported over from Meta, it can just overwrite the #REDIRECT --Jimbojw 19:47, 3 February 2007 (UTC)

getTitle Error when using version 1.8.2
I'm using MediaWiki 1.8.2 and I've installed the WikiFeeds extension. However, when creating a page using a simple example from the usage instructions, I get the following error: Fatal error: Call to a member function getTitle on a non-object in $IP/extensions/WikiFeeds.php on line 110

Has anyone experienced this? --Cmac4011 01:35, 21 January 2007 (UTC)


 * Thanks for trying out my extension. I unfortunately haven't tried this extension on any version other than 1.6.8 (my provider caps me at PHP 4).


 * I'll be happy to look into this as time permits. Are you getting this on page-preview? or after submitting the page?  I'm wondering if $wgArticle is not being populated for previewed pages.


 * --Jimbojw 18:31, 22 January 2007 (UTC)


 * Thanks sir. To answer your question, I'm getting this error when the published page is being rendered.  If you have any hunches or things you'd like me to try, I'd be glad to play around with the code in my PHP5 environment.


 * --Cmac4011 04:46, 24 January 2007 (UTC)


 * Hey Cmac - sorry for the delay, finally got around to fixing that issue. Turns out that in MW 1.8 and above, the $wgArticle global variable had not been initialized by the time the hooked methods were being executed.  The fix was to turn this line: $title = $wgArticle->getTitle; Into this line: $title = $wgTitle;  In any case, I've now tested on 1.6.8, 1.6.9, 1.8.3 and 1.9.1 - but not 1.8.2 explicitly.  I plan to support 1.6.x, 1.8.x and 1.9.x (as indicated on the extension page), so if you find that it's still acting up, please let me know.  Thanks!
 * --Jimbojw 19:47, 3 February 2007 (UTC)

Only shows one feed, the oldest on the list?
Thank you very much for this extension: exactly what I was looking for! Unfortunately I have two problems that completely elude me. I have MW version 1.7.1 and the page I am taling about is here Anyway I created a test page using only your example here I don't want to bother you but I you could point me to my mistake, if any, it would be so great! Thanks in any case! Guy gmalacrida at gmail.com EDIT: Thank you so much!
 * 1) Only the oldest (last on the list) item shows if you subscribe using the rss or atom links in the toolbox?
 * 2) Although my browser shows a feed icon in the address bar, clicking it opens a blank page with this in the address bar feed:http://www.yonis.ch/wiki/index.php?title=Actualit%C3%A9s&action=feed&feed=atom (NB: if you click on the link though, it will looks OK! You need click the rss icon in the address bar instead to replicate the problem. Also, Looking at the SpecialPages:Version the last line indeed indicates "UnknownAction: wfWikiFeedsAction" in the Hook section?).
 * Take all this away!
 * Just downloaded/installed last version 0.4 and my problems disapeared!


 * No worries - glad you like it! If you run into any more issues, I'll be glad to investigate.  Out of curiosity, how did you find my extension?  I'm always interested in hearing how people discover my creations.  Thanks again!
 * --Jimbojw 22:34, 28 February 2007 (UTC)

Object of class Title could not be converted to string
I'm using this extension on Mediawiki 1.9.3 and it appears there is a small bug which can be duplicated by doing the following.

Noopectro 14:47, 19 March 2007 (UTC)
 * 1) Create a template page, e.g. Template:Updates
 * 2) Add a few headers and text to the template and set up them up to work with WikiArticleFeeds
 * 3) Use the template in another page, E.g. on Main_Page.
 * 4) After using the template, the "RSS Atom" option should appear on the toolbox.
 * 5) Click RSS
 * 6) The following error appears: Catchable fatal error: Object of class Title could not be converted to string in /home/path/to/wiki/extensions/WikiArticleFeeds.php on line 266

EDIT: Turns out that somewhere between step 5 and saving this article, the Atom link does the same thing now too. EDIT.2: Even stranger is that some times it works as required, and some times it doesn't.


 * Thanks for bringing this to my attention, Noopectro. I have not yet been able to reproduce this issue (works for me).  I'm using PHP 5.1 in standard mode.  What version of PHP are you using?  Is your PHP running in Safe mode?
 * If you'd like to try something, change line 266 from this: $feed = new $wgFeedClasses[$feedFormat]($wgSitename.' - '.$title,, $title->getFullURL); To this: $feed = new $wgFeedClasses[$feedFormat]($wgSitename.' - '.$title->getText,, $title->getFullURL); Does this fix the issue? It continues to work for me with this change.
 * I just noticed something else too, it looks like updating an included template does not invalidate the parser cache in the way I would have expected, so updating the contents of a template will not necessarily make the next request for the including page's feed show the changes. I'll have to look into this more later to see if there's an easy fix.
 * --Jimbojw 18:33, 19 March 2007 (UTC)

For reference, i'm using PHP 5.2.1 (And Apache 2.2.4 if it makes a difference), and that small code change seems to of fixed it- thanks a lot. Hopefully this will help anyone else who was in the same situation as me. Noopectro 20:58, 19 March 2007 (UTC)


 * No worries! Glad we got it figured out.  By the way - I just released a new version of WikiArticleFeeds.  It contains this fix as well as some additional enhancement. --Jimbojw 23:00, 19 March 2007 (UTC)

Pb when create my fisrt feed
Hy,

i have installed release 0.6 of WAF (running on apache 2, php5, mediawiki 1.8.2) Installation is right and i create a new article as given into your examples.

I test with Firefox and when i try to register the feed by a right click on the RSS icon on the left of the URL toolbar, i have this error:

In english, it'a a firefox error whihc indicate the bad format for the xml output.

any idea ?

Thx --Ouaibsky 14:42, 26 March 2007 (UTC)


 * Hi Ouaibsky, if you could send me the generated XML file, I could take a look. Email: wilson.jim.r at gmail dot com --Jimbojw 16:52, 26 March 2007 (UTC)


 * Hello Jimbojw
 * Find below the source code of the generated page. Notes we have many blank line at the top of the result.

   http://frontools/wiki/index.php?title=News_Letter&amp;action=feed&amp;feed=atom Front Tools wiki - News Letter

  2007-03-28T10:06:00Z MediaWiki 1.8.2 via WikiArticleFeeds 0.6


 * --Ouaibsky 10:08, 28 March 2007 (UTC)


 * I think it has something to do with the extra whitespace at the top. If you save the file locally and remove the whitespace, then open the file with FireFox, do you get the same result?  I believe the XML specification requires that the first line has to be: &lt;?xml version="1.0" encoding="utf-8"?&gt;


 * I'm not sure why the extra spaces are being inserted, and I haven't tested on 1.8.x recently (it works for me on 1.6.x and 1.9.x).


 * As a side note, you should re-download the WikiArticleFeeds.php file if you can - I just had to fix a bug this morning, so it's a good idea to get the latest instance. --Jimbojw 16:30, 28 March 2007 (UTC)


 * Update: I've seen this behavior myself now. It happens when there are trailing newlines at the end of extension files.  It may be that either my extension or others installed have trailing whitespace at the end of the included PHP files.  (Mine shouldn't - but copy-pasting the content with a text editor rather than downloading the raw source may result in this unintended consequence).


 * In my case, the extra newlines were in the DynamicPageList2 extension's i18n file. --Jimbojw 20:03, 18 April 2007 (UTC)

Warning messages in 0.6.1 when run in MediaWiki 1.9.3

 * Undefined index: 'href' WikiArticleFeeds.php on line 205
 * Undefined variable: wgSitename in WikiArticleFeeds.php on line 343

I changed line 205 from:

if (!$rssArr['href']) {

to:

if (!array_key_exists('href', $rssArr) || !$rssArr['href']) {

and I added above line 343:

global $wgSitename;


 * Thanks! I've implemented these bugfixes in the downloadable version on jimbojw.com.  I really apprecaite you taking the time to not only identify the problem, but provide a fix.  Thanks a bunch! --Jimbojw 19:59, 18 April 2007 (UTC)

error: Call-time pass-by-reference has been deprecated
Hello ! I'm really interested by your extension, however I can't get it to work. When I activate the extension (using mediawiki 1.10) I get this warning message:

'''Warning: Call-time pass-by-reference has been deprecated;  If you would like to pass it by reference, modify the declaration of [runtime function name]. If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. in /xxxx.org/html/testwiki/extensions/WikiArticleFeeds.php on line 150 '''

Do i really need to change a setting on the ini file or did I just made a stupid mistake (which is likely!) ???

thanks for your help

Lilious 13:29, 24 May 2007 (UTC)


 * Hi Lilious - I haven't seen that before, but it's probably because I'm running older versions of PHP (I suspect you're either using PHP 6 or PHP 5 under stricter rules like "safe mode"). I should refactor my code such that the function declaration itself defines whether the parameter is reference or value (not the other way around). --Jimbojw 16:08, 24 May 2007 (UTC)


 * Update: I've corrected this issue, Lilious. If you redownload the extension, I think you'll see the issue go away (though I haven't been able to reproduce your exact issue locally, so we'll have to wait and see).  Please let me know if this doesn't solve the problem.  Thanks! --Jimbojw 18:52, 24 May 2007 (UTC)

Bad format for the xml output & trailing newlines at the end of extension files
Hello;

In what extensions do you guess, could be the Trailing new lines that provoked a bad xml output format?. I have checked many of them and it remains one blank line at the beginning of the xml output file. I am using mediawiki 1.11.0 version--Jbujosa 11:52, 5 November 2007 (UTC)


 * Hello Jbujosa - see previous messages in this page on that topic. It's probably another extension which has additional leading or trailing whitespace in the file - either before the leading   or after the trailing  ?> </tt>. Good luck! -- Jimbojw 00:19, 11 December 2007 (UTC)

$wgWhitelistRead don't allow to access a page with a WikiArticleFeeds extension
I am working with version 1.11

In my wiki Anonymous users cant read pages: $wgGroupPermissions['*' ]['read'] = false;

I am trying to allow, feeds integrators, to access to pages that are built with the WikiArticleFeeds, using $wgWhitelistRead, but it doesn't work. Any one can help me?


 * Hello there. I'm sorry, but that doesn't make any sense.  If users can't read the page, why should they be able to get a feed of it? -- Jimbojw 00:19, 11 December 2007 (UTC)

error while retreiving feed

 * 1) Installed the extenasion successfully
 * 2) when i try to subscribe to the feed i get the following link in my browser?

XML Parsing Error: not well-formed Location: http://caddcentre.org/caddwiki/index.php?title=Feeddata&action=feed&feed=atom Line Number 2, Column 1:﻿ <?xml version="1.0" encoding="utf-8"?> ^

Abhi kalyan 12:09, 30 November 2007 (UTC)


 * Hello Abhi kalyan, Please see the previous messages about leading and trailing whitespace. Usually this is a result of some other extension which has extra newlines before the beginning of a PHP file, or at the end of it.  Good luck! -- Jimbojw 00:21, 11 December 2007 (UTC)

Can you add media?
Great extension, thanks a ton for making it. I was wondering, what would it take to be able to turn this into a podcasting extension? I was trying to have Zune or iTunes be able to pick up my feed and download audio but I couldn't get it to work using standard [[Media:SomeFile.mp3]] formatting. Am I missing something or is this not possible?--76.254.7.17 22:59, 21 January 2008 (UTC)

Invalid URL problem
Cannot get it work, please help.


 * 1) I've installed the extension successfully;
 * 2) When I try to subscribe to the feed my browser (Explorer, Firefox alike) complains:

Clearly, there's a ':' missing from after the 'http' string. Could you please hint me why?

Thank you in advance, Lenny.

DPL and WikiArticleFeeds does not update
I used Extension:DynamicPageList to produce an RSS feed dynamically of all articles in a category, most recent first:

<startFeed/> <endFeed/>

The  line produces each line as a heading, which WikiArticleFeeds uses to produce the RSS.

This renders perfectly, with working "RSS" and "Atom" links appearing in the Toolbox. However, when the data changes (e.g., an article in the category gets modified, or an article is added to the category), the RSS feed does not update. It updates only if the article containing the DPL tag is modified.

Any ideas why this happens, and is there a workaround?

--Maiden taiwan 17:49, 13 May 2008 (UTC)


 * When WikiArticleFeeds renders an rss or atom feed, it caches the result in much the same way that the Parser caches its results. This is to prevent excessive re-parsing and re-rendering every time a request is made.  Just like MediaWiki, WAF will re-render the feeds when either the page itself has changed, or if a template it transcludes has changed.  I suspect that the pages themselves do not update either, or do they?


 * The problem you're seeing happens because the mechanisms which WAF checks for "change has occurred" are not being triggered. I'd have to dig into DPL more closely to give you any more information.  --Jimbojw (talk | blog) 05:24, 14 May 2008 (UTC)


 * Thanks Jim, I understand now. DPL is merely emitting dynamic content between the startFeed and endFeed tags, not updating any wiki article revision. To make this work, I imagine WAF would have to detect that the content of the page had changed, or provide an author-selectable option not to cache...? --Maiden taiwan 14:26, 14 May 2008 (UTC)

removing endFeed requirement
Here's how to change the code so that the "<feedEnd />" tag is no longer required:

Find the line that has both FEED_START and FEED_END in it. (in version 0.6.3 this is line 427) '/(.*?)/s',

and replace with '/(.*?)(?:|$)/s', //                             ^^^- (NEW) ---^^^ (you don't need that last line, that's just to show you what changed). --otheus 16:04, 14 July 2008 (UTC)

Also, to the author: a minor bug fix. Line 440 or so: if (empty($matches[1])) next; that "next" should be a "continue". This will only happen if the content of the Feed is completely empty. --otheus 16:09, 14 July 2008 (UTC)

Extra Characters in the Feed
When I try and point a RSS Reader to my wiki feed, extra characters get add onto the feed making it hard to read. Its something along the lines of " &lt;p> ". Any idea on whats going on? Thank you!

--Andy, 17 July 2008

Disabling default Wiki feeds
I added a news page to my wiki and create the contents using WikiArticleFeeds. The RSS and ATOM links are added to the generated HTML. However the standard/default MediaWiki RSS and ATOM feed links to RecentChanges still appear in all pages of the wiki. Using the "Feeds" button of MSIE7 four feeds can be selected on this news page. On all other pages (without WikiArticleFeeds) the RecentChanges feed will be used.

How do I remove the standard/default MediaWiki RSS and ATOM feed links to RecentChanges on all pages? So I will only have the RSS and ATOM links from WikiArticleFeeds on my news page.

--Rebbyte 09:43, 24 July 2008 (UTC)


 * I found a solution. As of MW 1.13 it is possible to disable the default MediaWiki feeds from within LocalSettings.php with:

$wgFeed = false;
 * The WikiArticleFeeds feeds remain working. --Rebbyte 07:54, 1 September 2008 (UTC)

Feed only shows first item(s)
I've just installed this extension - it's a terrific feature. But I'm running into the same problem described above some time ago. It was reported solved by the user in an earlier version. The feed seems to be static - no matter what I add, my feed reader reports "No New Items".

I'm using Mediawiki V1.10 and a just-downloaded version of WikiArticleFeeds   Any thoughts?

Mgreis 04:13, 23 October 2008 (UTC)


 * I'm running into the same issue. I think it may have something to do with how often the feed expires in the .php. I'm trying to test it, but depending on which reader you are using there also may be a timer for how often it checks for new information.


 * beacoupfish 10:46, 4 November 2008 (CST)

A different error with getTitle
Hi Jimbojw,

Thanks for the extension. I think I have installed the extension correctly. But when I use the tags to create RSS feeds and hit save page or show preview I get this error:

Fatal error: Call to undefined method OutputPage::getTitle in !!initial pathname taken out!!extensions\WikiArticleFeeds.php on line 241

I am using mediawiki version 1.14.0. I would really appreciate some help with this regard. Thanks.

Tengo el mismo problema! Mediawiki version 1.14
 * I had the same problem (also in MW1.14) after upgrading to vers. 0.6.4. I changed line 239 and 241 back as they was in the previous version (0.6.3) of this extension, and it worked again. Hope this helps.

239: global $wgServer, $wgScript, $wgTitle; 241: $baseUrl = $wgServer. $wgScript. '?title='. $wgTitle->getDBkey. '&action=feed&feed=';


 * I got the same problem with MediaWiki 1.15.3. The solution worked for me, only the line numbers are now a little further down the road ;-) NOTE: Seems like the version from the author's website (http://jimbojw.com/wiki/index.php?title=WikiArticleFeeds) already includes this modifications and is thus more up to date than the snapshot you get from here. --Nakohdo 15:26, 11 May 2010 (UTC)

Blank page
Hi After installing the extension, I added the code in the test page and when I click on save the page I get is a black page. I'm using the lateste version of mediawiki. --Brunoscunha 12:59, 27 October 2009 (UTC)


 * Hi,
 * I have the same Issue, only a blank page after using the - tag. And it is really blank, as a white DinA 4 paper. I'm using the latest Version of Mediawiki and WikiArticleFeeds
 * --Werwfdsfdsfsdf 11:44, 28 January 2010 (UTC)


 * You have to edit the WikiArticleFeeds.php and find:

$out->getTitle->getDBkey
 * Replace it with

$wgTitle->getDBkey
 * In the rule above it replace

global $wgServer, $wgScript;
 * with

global $wgServer, $wgScript, $wgTitle;
 * Litso 11:11, 11 May 2010 (UTC)

Patch: Remove signature from entries
By default, when there is a Wiki signature in an entry it is included in the RSS feed. To remove the signature, I use the following patch.

Thanks for WikiArticleFeeds. --Ashawley 14:56, 22 February 2010 (UTC)

Template feeds don't work
I'm using a news template on my website (main page, template) and I want to provide an rss feed for the template. Unfortunately, when I click the rss icon provided by the extension it load the feed for News and not Template:News. Apparently the script ignores namespaces. Of course you could circumvent this by redirecting the News page to Template:News but not everybody will be able to do so (if both pages have a different meaning). Just wanted to let you know!

Possible fix: replace rule 139 to 141 with: global $wgServer, $wgScript, $wgTitle; $baseUrl = $wgServer. $wgScript. '?title='. $wgTitle->getPrefixedText. '&action=feed&feed='; This takes care of the above problems with blank pages as well because it uses $wgTitle in stead of $out->getTitle

Apart from that, thanks a lot for this plugin, it's most useful. Litso 12:11, 11 May 2010 (UTC)