Maybe we could add some kind of check for the redirect...

if ( strstr( $page, '#REDIRECT' ) ) {

$pattern = '/#REDIRECT\s*\[\[(.*)\]\]/i';
$tester = preg_match( $pattern, $page, $matches );
$talkPageTitle = $matches[1];

}

(might need to be in javascript though depending on if we're doing it client-side or server-side)

(In reply to comment #1)

Maybe we could add some kind of check for the redirect...

if ( strstr( $page, '#REDIRECT' ) ) {

$pattern = '/#REDIRECT\s*\[\[(.*)\]\]/i';
$tester = preg_match( $pattern, $page, $matches );
$talkPageTitle = $matches[1];

}

Nooooo! There are better ways to check for this, don't reinvent the wheel. There's Article::getRedirectTarget() (technically in the WikiPage class in trunk) on the PHP side, and an API call for this on the JS side.

Actually it looks like this is not a good idea for 2 reasons. First it can lead to an endless loop:

1. User talk:John redirects to User:John
2. WikiLove retrieves the user page for User:John which is User talk:John
3. Goto 1

1. User talk:John redirects to User talk:John/subpage
2. WikiLove retrieves the base page title for User talk:John/subpage which is User talk:John
3. Goto 1

Secondly, I think it would be confusing for someone on User:John to be redirected to User talk:Willy after they submit their WikiLove on User:John. I imagine they would think that an error had occurred.

I've worked around this problem in r92344. The WikiLove tab is now only displayed on User pages that have real talk pages (not redirects). This means the user has to follow the redirect on their own, which should eliminate any confusion.

Marking WONTFIX.