on same page
http://wiki.maemo.org/index.php?title=N900_Hardware_USB&action=history
clicking the name (speedevil here) opens
http://wiki.maemo.org/index.php?title=User:speedevil&action=edit
while it should open
http://wiki.maemo.org/index.php?title=User:speedevil

Thanks for reporting this.

Not sure if this "expected" behavior, but I can confirm this bug.

Comment 3 Dave Neary 2010-06-08 16:54:27 UTC

The query that *should* be running is:

SELECT page_namespace, page_title, page_is_new, page_latest, rev_id, rev_page,
rev_text_id, rev_timestamp, rev_comment, rev_minor_edit, rev_user,
rev_user_text, rev_deleted from mw_page,mw_revision where
rev_user_text='dneary' and page_id=rev_page;

What is (apparently) running - and without a general mysql database log, I
can't be sure - is

SELECT page_namespace, page_title, page_is_new, page_latest, rev_id, rev_page,
rev_text_id, rev_timestamp, rev_comment, rev_minor_edit, rev_user,
rev_user_text, rev_deleted from mw_page,mw_revision where
rev_user_text='dneary' and page_id=rev_page USE INDEX (usertext_timestamp);

which, for the wiki server's mysqlserver, gives me an sql error.

Checking it out further.

Comment 4 Dave Neary 2010-06-08 19:05:51 UTC

From looking at SQL logs on a different mediawiki instance, here's the query in
full that's being run there (with a MySQL 5.1 server):

SELECT /* IndexPager::reallyDoQuery (ContribsPager) Dneary */ 
page_namespace,page_title,page_is_new,page_latest,page_is_redirect,page_len,rev_id,rev_page,rev_text_id,rev_timestamp,rev_comment,rev_minor_edit,rev_user,rev_user_text,rev_parent_id,rev_deleted,ts_tags
 FROM `mw_revision` FORCE INDEX (usertext_timestamp) INNER JOIN `mw_page` ON
((page_id=rev_page)) LEFT JOIN `mw_tag_summary` ON ((ts_rev_id=rev_id))  WHERE
rev_user_text = 'Dneary' AND (rev_deleted & 4 = 0)  ORDER BY rev_timestamp DESC
LIMIT 51;

The query would obviously be different on the Maemo mediawiki (no tags in that
version) - running this query yields the expected empty set:

SELECT /* IndexPager::reallyDoQuery (ContribsPager) Dneary */ 
page_namespace,page_title,page_is_new,page_latest,page_is_redirect,page_len,rev_id,rev_page,rev_text_id,rev_timestamp,rev_comment,rev_minor_edit,rev_user,rev_user_text,rev_parent_id,rev_deleted
 FROM `mw_revision` FORCE INDEX (usertext_timestamp) INNER JOIN `mw_page` ON
((page_id=rev_page)) WHERE rev_user_text = 'Dneary' AND (rev_deleted & 4 = 0) 
ORDER BY rev_timestamp DESC LIMIT 51;

Note the 'Dneary', not 'dneary'. When I set the username we're filtering on to
'dneary', I see my history. This looks like one more repeat of the
tolower/ucFirst issue we have been seeing with other services.

Will work up a patch for deployment.

Dave.

Comment 5 Dave Neary 2010-06-08 19:44:29 UTC

Nope, it doesn't seem to be that... stumped. Really need to enable a general
query log to see what's getting queried & why it's returning no hits.

Dave.

(In reply to comment #4)
> From looking at SQL logs on a different mediawiki instance, here's the query in
> full that's being run there (with a MySQL 5.1 server):
> 
> SELECT /* IndexPager::reallyDoQuery (ContribsPager) Dneary */ 
> page_namespace,page_title,page_is_new,page_latest,page_is_redirect,page_len,rev_id,rev_page,rev_text_id,rev_timestamp,rev_comment,rev_minor_edit,rev_user,rev_user_text,rev_parent_id,rev_deleted,ts_tags
>  FROM `mw_revision` FORCE INDEX (usertext_timestamp) INNER JOIN `mw_page` ON
> ((page_id=rev_page)) LEFT JOIN `mw_tag_summary` ON ((ts_rev_id=rev_id))  WHERE
> rev_user_text = 'Dneary' AND (rev_deleted & 4 = 0)  ORDER BY rev_timestamp DESC
> LIMIT 51;
> 
> The query would obviously be different on the Maemo mediawiki (no tags in that
> version) - running this query yields the expected empty set:
> 
> SELECT /* IndexPager::reallyDoQuery (ContribsPager) Dneary */ 
> page_namespace,page_title,page_is_new,page_latest,page_is_redirect,page_len,rev_id,rev_page,rev_text_id,rev_timestamp,rev_comment,rev_minor_edit,rev_user,rev_user_text,rev_parent_id,rev_deleted
>  FROM `mw_revision` FORCE INDEX (usertext_timestamp) INNER JOIN `mw_page` ON
> ((page_id=rev_page)) WHERE rev_user_text = 'Dneary' AND (rev_deleted & 4 = 0) 
> ORDER BY rev_timestamp DESC LIMIT 51;
> 
> Note the 'Dneary', not 'dneary'. When I set the username we're filtering on to
> 'dneary', I see my history. This looks like one more repeat of the
> tolower/ucFirst issue we have been seeing with other services.
> 
> Will work up a patch for deployment.
> 
> Dave.
> 

well, that seems to be easily solved by 
 WHERE tolower(rev_user_text) = tolower('Dneary')

Dunno if that particular flavour of SQL supports this
/j

Comment 7 Dave Neary 2010-06-10 15:55:40 UTC

I've debugged it, but I'm not sure if the fix is appropriate.

1. SpecialContributions::wfSpecialContributions() (in
includes/SpecialContributions.php) gets called to display the page and its
results, and it gets the target text from the query box.
2. The target is converted to a namespace-safe title with 
   $nt = Title::makeTitleSafe( NS_USER, $target );
3. Title::makeTitleSafe (in includes/Title.php) calls Title::secureAndSplit()
to ensure that the page name is legal
4. Title::secureAndSplit has the following couplet:

   2071                 /**
   2072                  * Normally, all wiki links are forced to have
   2073                  * an initial capital letter so [[foo]] and [[Foo]]
   2074                  * point to the same place.
   2075                  *
   2076                  * Don't force it for interwikis, since the other
   2077                  * site might be case-sensitive.
   2078                  */
   2079                 $this->mUserCaseDBKey = $dbkey;
   2080                 if( $wgCapitalLinks && $this->mInterwiki == '') {
   2081                         $dbkey = $wgContLang->ucfirst( $dbkey );
   2082                 }
   2083 

So the user name stored in $nt is "User:Dneary" (capitalised).

In SpecialContributions.php::wfSpecialContributions():
    237         $id = User::idFromName( $nt->getText() );
    238
    239         if ( $target != 'newbies' ) {
    240                 $target = $nt->getText();
    241                 $wgOut->setSubtitle( contributionsSub( $nt, $id ) );
    242         } else {
    243                 $wgOut->setSubtitle( wfMsgHtml(
'sp-contributions-newbies-sub') );
    244         }

which gets a userid for the user, which (I think) only gets used to set the
"For Dneary (Log, Talk...)" title header. And then (importantly) it replaces
our target text with the upper-cased username.

Then, with the inputs from the form, we create a new pager object, call the
function getNumRows to see how many rows are returned by it, which calls
doQuery, which calls reallyDoQuery (all in Pager.php), which calls getQueryInfo
(virtual in Pager, defined in ContribPager):

    286         $pager = new ContribsPager( $target, $options['namespace'],
$options['year'], $options['month'] );
    287         if ( !$pager->getNumRows() ) {
    288                 $wgOut->addWikiMsg( 'nocontribs' );
    289                 return;
    290         }

And at this stage, $target is 'Dneary', and doesn't match anything.

I've dropped the $target = $nt->getText() but with bytecode caching it's not
visible and deployed yet.

Comment 8 Dave Neary 2010-06-10 19:31:44 UTC

The reason the change wasn't seen straighht away was because of some hairy
issues with sym links and real copies resulting in 2 versions of includes which
weren't in sync, and the wrong one was getting used. Fixed now, and this should
work as detailed above.

Dave.

fix confirmed