There was an error uploading the avatar: Specified file failed upload test.

@alx359, does uploading a custom default icon work? (After removing the wp_unslash call there, too.)

This is very odd to me, Pepe.

THIS piece of code works, but I don’t understand why, and what the issue with wp_handle_upload is:

$file = $_FILES[ self::FILE_UPLOAD ];
$avatar = $this->upload($file);
$avatar['file'] = \wp_normalize_path( $avatar['file'] );

Before calling wp_handle_upload via upload($file):

$file = array (
  'name' => 'redcross.jpg',
  'type' => 'image/jpeg',
  'tmp_name' => 'C:\\wamp\\tmp\\php9BB9.tmp',
  'error' => 0,
  'size' => 1796,
)

After fixing $avatar, and before calling assign_new_user_avatar

$avatar = array (
  'file' => 'D:/domains/www.mydomain.com/wp-content/uploads/admin_avatar.jpg',
  'url' => 'https://mydomain.com/wp-content/uploads/admin_avatar.jpg',
  'type' => 'image/jpeg',
)

If I try to do $file['tmp_name'] = \wp_normalize_path( $file['tmp_name'] ) BEFORE upload($file) — as we did so many times with you — I just get this wp_handle_upload error:

Specified file failed upload test.

Why?

I know this is UGLY, and is just patching the symptoms and not the underlying cause. But it works for me for now. Hope you’d come up with some real fix when getting the chance to look after us Windows folks.

// In Windows, handle uploads "Win-style"
if( strtoupper(substr(PHP_OS, 0, 3)) === 'WIN' ) {
    
    // take backlash paths "raw" w/o further normalization  
    $file = $_FILES[ self::FILE_UPLOAD ];
    
    // Upload to our custom directory
    $avatar = $this->upload( $file );
    
    // normalize path to forward slashes AFTER upload, 
    // because of wp_handle_upload issue in Windows 
    $avatar['file'] = \wp_normalize_path( $avatar['file'] );

} else { //Unix-style upload is the default

    // Upload to our custom directory.
    $avatar = $this->upload(
        \wp_unslash( $_FILES[ self::FILE_UPLOAD ] )
    );
}

What does $avatar['file'] look like before normalization?

'file' => 'D:\\domains\\www.mydomain.com/wp-content/uploads/admin_avatar.jpg',

According my tests, skipping normalization before upload ensures the avatar gets copied to the uploads folder (and the wp_handle_upload error being suppressed). Adding the normalization after upload ensures the cache picking it up.

As I suspected, because the resulting path is mixed (half Windows, half POSIX) and therefore invalid.

I’ve added an issue for tackling this on GitHub. I’m now convinced that the use of wp_unslash is indeed erroneous (see this WPCS issue for details). However, to properly fix this, I’ll have to set up a Windows VM first.

Good news, thank you. I’m still not convinced though how a core WP function wouldn’t work as expected for such a basic thing like normalizing paths, but I’m out of ideas of what might be so peculiar with my WAMP config. Think have switched off all potential plugins that could have any effect during my tests.

Fixed in 2.2.1. The culprit was an implicit call to wp_unslash in update_metadata.

Appears to be properly fixed now. Thank you!

Great! Once you’ve had time to evaluate the plugin, I’d be grateful if you could write a review.

Of course, it’s done. Thank you again!