Page MenuHomePhabricator

PHP "undefined offset" errors in Recentchanges feeds
Closed, ResolvedPublic

Description

Author: steph3n

Description:
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.


Version: 1.9.x
Severity: normal

Details

Reference
bz7785

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:27 PM
bzimport set Reference to bz7785.
bzimport added a subscriber: Unknown Object (MLST).

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.

steph3n wrote:

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

nickpj wrote:

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.

steph3n wrote:

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.

Attached:

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).