[wp-testers] sorta an off the wall bug

[Otto]

On Thu, Jun 21, 2012 at 10:31 AM, Andrew Nacin <wp at andrewnacin.com> wrote:
> But is that what is occurring here? Doesn't seem like it, based on my read.
> Frumph?


Re-reading it, I'm not sure what he's saying, actually.

>> if ( !$upload_path = get_option( 'upload_path' ) ) {
>>  $upload_path = substr( WP_CONTENT_DIR, strlen( ABSPATH ) ) . '/uploads';
>>  update_option( 'upload_path', $upload_path );
>> }
>> update_option( 'fileupload_url', get_option( 'siteurl' ) . '/' .
>> $upload_path );
>>
>> What this is doing, is hardcoding the current abspath and the
>> WP_CONTENT_DIR
>> with /uploads resulting in the absolute hardcoding of that location


See, that's not what that code does.

Lets say:

ABSPATH = "/home/foo/"
WP_CONTENT_DIR = "/home/foo/wp-content/"

In which case this code:
echo substr( WP_CONTENT_DIR, strlen( ABSPATH ) ).'uploads';

will produce "wp-content/uploads".

In other words, it's not producing an absolute path for the
upload_path at all, nor should it.

But this is just the default. Notice that only gets run when
upload_path has not been set.


But yes, if an absolute path has been set in the upload_path field
manually, by whatever means, then that's going to be used in an
absolute manner. It doesn't set the absolute path there by default.
The default for a new installation is the relative
"wp-content/uploads" as per the above code.

-Otto