wp_upload_dir() returns wrong value after provider changes disk

[opajaap]

wp_upload_dir() returns wrong value after provider changes disk.

This is because in:

<?php
function _wp_upload_dir( $time = null ) {
    $siteurl = get_option( 'siteurl' );
    $upload_path = trim( get_option( 'upload_path' ) );
 
    if ( empty( $upload_path ) || 'wp-content/uploads' == $upload_path ) {
        $dir = WP_CONTENT_DIR . '/uploads';
    } elseif ( 0 !== strpos( $upload_path, ABSPATH ) ) {
        // $dir is absolute, $upload_path is (maybe) relative to ABSPATH
        $dir = path_join( ABSPATH, $upload_path );
    } else {
        $dir = $upload_path;
    }

the option 'upload_path' is read that holds the value since the website was first set up and the function path_join( ABSPATH, $upload_path ) erroneously returns $upload_path because it is an absolute path: if ( path_is_absolute($path) ), but it is the wrong path, see:

<?php
function path_join( $base, $path ) {
    if ( path_is_absolute($path) )
        return $path;
 
    return rtrim($base, '/') . '/' . ltrim($path, '/');
}

The asumption that 0 !== strpos( $upload_path, ABSPATH ) means that $upload_path is relative, is incorrect.
It would be nice if the option 'upload_path' was updated as soon as a correct test finds the value is no longer valid. If someone wants the upload dir outside ABSPATH, they can use define( 'UPLOADS', '....' );, so it should be safe to verify it against ABSPATH or make it relative to ABSPATH anyway. Clearing the option 'upload_path' at the next update may also help.

It appears that newly created sites have the option blank, but my sites that were created up to 7 years ago exhibit this issue.

This means that plugin authors can not rely on wp_upload_dir(), and that should be fixed.

[markparnell]

Per the comments on #41947 (particularly https://core.trac.wordpress.org/ticket/41947#comment:4) this isn't really a bug as such, but a question of configuration - when the site is moved to a new path the configuration needs to be adjusted accordingly.

Since that ticket has already been closed as invalid after discussion, I'm marking this as a duplicate (even though it's older).