Last modified: 2006-11-03 08:55:23 UTC
Mediawiki 1.8.2 on Ubuntu Server 6.10 running Apache/2.0.55 (Ubuntu) with PHP/5.1.6 and PostgreSQL 8.1.4. Feeds generated from index.php/Special:Recentchanges?feed=<feed> contain errors in the output: Notice: Undefined offset: -2 in /var/www/languages/Language.php on line 354 I believe this is due to date incompatibilities between PostgreSQL and MySQL, which the wiki code isn't checking for. This doesn't affect atom and rss feeds as the feed readers ignore the errors, but the custom binary feed output I have written is affected by this. Steps to reproduce: 1. Install mediawiki-1.8.2 on Apache2/PHP5/PostgreSQL8.1. 2. Make changes to some wiki pages to generate diffs in recentchanges. 3. View source of Special:Recentchanges?feed=[atom|rss] This error only occurs when diffs are formatted into feeds. I have tracked the bug down to include/SpecialRecentChanges:408 where "SpecialRecentChanges::rcFormatDiff()" is called. The parameter passed is a row from the database containing a timestamp in the format: "YYYY-MM-DD HH:mm:ssTZ" when the expected format is "YYYYMMDDHHmmss". The date used by a call to Language::dateandtime from SpecialRecentChanges::rcFormatDiffRow, which results in errors being printed to stdout. I have fixed this bug in my own wiki by adding the line: $obj->rc_timestamp = wfTimestamp(TS_MW, $obj->rc_timestamp); to SpecialRecentChanges line 406. This change reformats the timestamp to the format that the Language class expects, and results in clean feed output. I'm not sure that this is the correct place to fix the output, could a developer please verify this bug, and my solution.
You certainly should not change the contents of a loaded database row; instead look for the use of the value and ensure that it uses the correct functions to decode the timestamp.
Thanks for your comment. The erroneous use of this value is in "SpecialRecentChanges::rcFormatDiffRow" line 643, where the function Language::timeanddate() is called. Language::timeanddate() expects the date string passed to be of the form "YYYYMMDDHHmmss", so I guess this is the appropriate place to fix the problem. The fix would then be to change line 643 of SpecialRecentChanges.php from: $wgContLang->timeanddate( $timestamp ) ) ); to: $wgContLang->timeanddate( wfTimestamp( TS_MW, $timestamp ) ) ); Here is a diff showing the changes I have made to my version of mediawiki: --- SpecialRecentchanges.php 2006-10-14 13:06:32.000000000 +1300 +++ SpecialRecentchanges.php 2006-11-02 21:43:19.000000000 +1300 @@ -638,8 +638,10 @@ $diffText = $de->getDiff( wfMsg( 'previousrevision' ), // hack wfMsg( 'revisionasof', - $wgContLang->timeanddate( $timestamp ) ) ); + $wgContLang->timeanddate( + wfTimestamp( TS_MW, $timestamp ) + ) ) ); if ( strlen( $diffText ) > $wgFeedDiffCutoff ) { // Omit large diffs
Very quick note - it's best to attach diffs as files using the "Create a new attachment" link, because bugzilla eats whitespace, which makes patches not apply cleanly.
Created attachment 2623 [details] Fix for includes/SpecialRecentChanges.php date format bug This patch corrects the format of the date parameter passed to Language::timeanddate so that mediawiki installations on PostgreSQL do not print errors into feeds.
Fixed in r17376; I moved the conversion up one function to where it's reading fields directly out of a database row (and should therefore be doing the translation there, as it does for the title).
