Wikimedia Bugzilla is closed!

Maybe caused by r84475 - not 100% sure.

Owltom: Happy-melon might have fixed this r88664 (if my theory about what is causing this is correct, however it might be unrelated), can you check if this is still present on latest trunk?

Bug still present.

It is (and was) possible to check Edits from "pure" IPs (IPs not used by user accounts).

When I check IPs from user accounts, I get

"Tried to load block with invalid type" (like in Description above)


While checking edits of different IPs, I also ran into "There is no user by the name "xxx.xxx.xxx.xxx". Check your spelling." (Checkuser interpreted a correct IP as an user name, but I cannot reproduce how to trigger this).

Just noticed Brions r88702 ...

I'll test again ...

That's indifferent. I broke that earlier tonight

With trunk r88704 in so other stuff doesn't break ;) I seem to be ok on user->IP lookups, I still get the bug reported here when I do IP->edit lookups:

Tried to load block with invalid type

Backtrace:

#0 /var/www/trunk/includes/Block.php(988): Block->newLoad('')
#1 /var/www/trunk/extensions/CheckUser/CheckUser_body.php(1086): Block::newFromTarget(Object(User), '', false)
#2 /var/www/trunk/extensions/CheckUser/CheckUser_body.php(1161): CheckUser->userBlockFlags('', '1', Object(User))
#3 /var/www/trunk/extensions/CheckUser/CheckUser_body.php(678): CheckUser->CUChangesLine(Object(stdClass), '')
#4 /var/www/trunk/extensions/CheckUser/CheckUser_body.php(103): CheckUser->doIPEditsRequest('192.168.38.113', false, '', 0)
#5 /var/www/trunk/includes/SpecialPageFactory.php(459): CheckUser->execute(NULL)
#6 /var/www/trunk/includes/Wiki.php(217): SpecialPageFactory::executePath(Object(Title), Object(RequestContext))
#7 /var/www/trunk/includes/Wiki.php(62): MediaWiki->handleSpecialCases()
#8 /var/www/trunk/index.php(141): MediaWiki->performRequestForTitle(NULL)
#9 /var/www/trunk/index.php(69): wfIndexMain()
#10 {main}

(In reply to comment #6)
> With trunk r88704 in so other stuff doesn't break ;) I seem to be ok on
> user->IP lookups

That's what I meant in my first description, "Get IP addresses" was ok all the time ...

So this seems to fail because r84475 makes new assumptions about input data: the $vagueTarget parameter given to Block::newLoad is '', which is !== null and therefore gets divided up for further processing.

This expands through self::parseTarget() to a ($target, $type) of (null, null), which results in the exception being thrown.


$vagueTarget here is... the second parameter passed to Block::newFromTarget(). Callers expect to pass empty strings as empty here, but the code now requires null:


CheckUser_body.php:

    # Check if this user or IP is blocked. If so, give a link to the block log...
    $ip = IP::isIPAddress( $name ) ? $name : '';
    $flags = $this->userBlockFlags( $ip, $users_ids[$name], $user );
...
    $block = Block::newFromTarget( $user, $ip, false );
...

Block.php:
    if( $block->newLoad( $vagueTarget ) ){
...
    if( $vagueTarget !== null ){
        list( $target, $type ) = self::parseTarget( $vagueTarget );
        switch( $type ) {
...
        default:
            throw new MWException( "Tried to load block with invalid type" );
    
Block::newLoad and friends should probably be fixed to accept empty string values as empty, as existing callers expect.

Done on trunk in r88750:

* (bug 29116) Fix regression breaking CheckUser extension

Fixes regression from r84475 and friends which made Block->load() and its new front-end Block::newFromTarget() fail when an empty string was passed in as the IP / $vagueTarget parameter to indicate skipping IP-based lookups.
Added phpunit test cases to confirm that both Block->load() and Block::newFromTarget() work when given null (already ok), '' (as done from CheckUser), or false (not seen, but perfectly legit sounding).
Adjusted comparisons to work as expected.

Presumably needs merge to 1.18.