[wp-testers] sorta an off the wall bug

[Philip M. Hofer (Frumph)]

When installing wordpress and running it. It is setting the upload_path
to be the path structure of where the upload directory is hardcoded with
/path/to/wp-content/uploads/ so what is happening is that the wp_upload_dir
is taking that information.

So when someone moves their site path, it's retaining the hard location, a
user could move their system from a subdirectory to a root of it or even to
another location altogether and do sql dumps to restore their site the
upload_path doesn't reset for the new location



wp_upload_dir() reports this as it's error:

["error"]=> string(142) "Unable to create directory
/home1/tkdanimc/public_html/nikkisprite/wp-content/uploads/2012/06. Is its
parent directory writable by the server?"

^ this is because the upload_path is set to
/home1/tkdanimc/public_html/nikkisprite/wp-content/uploads

get_stylesheet_directory() returns this:

string(71)
"/home/tdoherty/public_html/nikkisprite.com/wp-content/themes/comicpress"

^ which is correct because that is the new location on the new server

changing the upload_path to just wp-content/uploads of course works just
fine





the problem actually comes from wp-admin/includes/schema.php line 931-935

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




What I am saying the problem is. function wp_upload_dir() is not
properly stripping out the information in line 1445-1448 because the ABSPATH
is different then it actually is hardcoded in the upload_path



Does this make sense?







_______________________________________________
wp-testers mailing list
wp-te...@lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-testers

[Otto]

There's nothing wrong with that. The upload_path *should* get set to
the full hard-path when the wp-content directory isn't in the ABSPATH.

When you move the site from one place to another, yes, that
upload_path will break if it's a hard path. But so will many other
things, generally speaking. The upload_path is a user-changable
variable for a reason.

-Otto

[Philip M. Hofer (Frumph)]

Okie dokie. I am storing it in my memory to remember to have people check
that as a possible reason why the wp_upload_dir() is failing.

- Phil

[Bimal Rekhadiya]

I am fully agree with Philip. The path should not absolute path. The upload
process is working with "wp-content/uploads" path. So changing this will
not make any effect. And this will help us when we move host.

I am a web developer.The Media upload is broken whenever I move Wordpress
site to client's host. Sometimes I forget to change the path and client
would little worry when he/she see the error. So I recommend to change the
path to "wp-content/uploads" and not the full absolute path.

On Thu, Jun 21, 2012 at 6:50 PM, Philip M. Hofer (Frumph) <phi...@frumph.net
> wrote:

> Okie dokie. I am storing it in my memory to remember to have people
> check that as a possible reason why the wp_upload_dir() is failing.
>
> - Phil
>
>
>
> -----Original Message----- From: Otto
> Sent: Thursday, June 21, 2012 6:16 AM

> To: wp-te...@lists.automattic.**com <wp-te...@lists.automattic.com>

> Subject: Re: [wp-testers] sorta an off the wall bug
>
>
> There's nothing wrong with that. The upload_path *should* get set to
> the full hard-path when the wp-content directory isn't in the ABSPATH.
>
> When you move the site from one place to another, yes, that
> upload_path will break if it's a hard path. But so will many other
> things, generally speaking. The upload_path is a user-changable
> variable for a reason.
>
> -Otto
>
>
> On Wed, Jun 20, 2012 at 7:56 PM, Philip M. Hofer (Frumph)
> <phi...@frumph.net> wrote:
>
>> When installing wordpress and running it. It is setting the upload_path
>> to be the path structure of where the upload directory is hardcoded with
>> /path/to/wp-content/uploads/ so what is happening is that the
>> wp_upload_dir
>> is taking that information.
>>
>> So when someone moves their site path, it's retaining the hard location, a
>> user could move their system from a subdirectory to a root of it or even
>> to
>> another location altogether and do sql dumps to restore their site the
>> upload_path doesn't reset for the new location
>>
>>
>>
>> wp_upload_dir() reports this as it's error:
>>
>> ["error"]=> string(142) "Unable to create directory

>> /home1/tkdanimc/public_html/**nikkisprite/wp-content/**uploads/2012/06.

>> Is its
>> parent directory writable by the server?"
>>
>> ^ this is because the upload_path is set to

>> /home1/tkdanimc/public_html/**nikkisprite/wp-content/uploads
>>
>> get_stylesheet_directory() returns this:
>>
>> string(71)
>> "/home/tdoherty/public_html/ni**kkisprite.com/wp-content/**
>> themes/comicpress <http://nikkisprite.com/wp-content/themes/comicpress>"

>>
>> ^ which is correct because that is the new location on the new server
>>
>> changing the upload_path to just wp-content/uploads of course works just
>> fine
>>
>>
>>
>>
>>
>> the problem actually comes from wp-admin/includes/schema.php line 931-935
>>
>> 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
>>
>>
>>
>>
>> What I am saying the problem is. function wp_upload_dir() is not
>> properly stripping out the information in line 1445-1448 because the
>> ABSPATH
>> is different then it actually is hardcoded in the upload_path
>>
>>
>>
>> Does this make sense?
>>
>>
>>
>>
>>
>>
>>

>> ______________________________**_________________
>> wp-testers mailing list
>> wp-te...@lists.automattic.**com <wp-te...@lists.automattic.com>
>> http://lists.automattic.com/**mailman/listinfo/wp-testers<http://lists.automattic.com/mailman/listinfo/wp-testers>
>>
> ______________________________**_________________
> wp-testers mailing list
> wp-te...@lists.automattic.**com <wp-te...@lists.automattic.com>
> http://lists.automattic.com/**mailman/listinfo/wp-testers<http://lists.automattic.com/mailman/listinfo/wp-testers>
> ______________________________**_________________
> wp-testers mailing list
> wp-te...@lists.automattic.**com <wp-te...@lists.automattic.com>
> http://lists.automattic.com/**mailman/listinfo/wp-testers<http://lists.automattic.com/mailman/listinfo/wp-testers>
>



--
From Bimal J Rekhadiya

http://www.loyalindia.com
http://www.brcreation.com

Life is not measured by the number of breaths we take...
But by the moments that take our breath away....!

[Andrew Nacin]

On Thu, Jun 21, 2012 at 9:16 AM, Otto <ot...@ottodestruct.com> wrote:

> There's nothing wrong with that. The upload_path *should* get set to
> the full hard-path when the wp-content directory isn't in the ABSPATH.
>

But is that what is occurring here? Doesn't seem like it, based on my read.
Frumph?

[Andrew Macaulay-Brook]

I regularly move sites from development on my MacBook to my live Linux server which have different file paths and I have never had to change anything. I think there must be something else at play here. A.

Please excuse any brevity: Sent from my iPhone

[Philip M. Hofer (Frumph)]

It gets the full hard-path of whatever is set in the upload_path and uses
it.

Users who have moved their sites will have that hard-path still and it will
use it. so wp_upload_dir() fails out with wp_error.

Only fix is to go to wp-admin/options.php and change the upload_path (or use
update_option)

-----Original Message-----
From: Andrew Nacin
Sent: Thursday, June 21, 2012 8:31 AM
To: wp-te...@lists.automattic.com
Subject: Re: [wp-testers] sorta an off the wall bug

[Philip M. Hofer (Frumph)]

To fix, users who have moved their site (on the same hosting, or with .sql
dumps)

[Otto]

On Thu, Jun 21, 2012 at 10:31 AM, Andrew Nacin <w...@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

[Otto]

On Thu, Jun 21, 2012 at 1:25 PM, Philip M. Hofer (Frumph)
<phi...@frumph.net> wrote:
> It gets the full hard-path of whatever is set in the upload_path and uses
> it.
>
> Users who have moved their sites will have that hard-path still and it will
> use it.  so wp_upload_dir() fails out with wp_error.

The real question is why did they have a hard-path there in the first
place? That is certainly not the default.

> Only fix is to go to wp-admin/options.php and change the upload_path (or use
> update_option)

The upload_path is actually a user changeable setting. Just go to
Settings->Media. No need to do drastic measures to change it. See
/wp-admin/options-media.php.


-Otto

[Philip M. Hofer (Frumph)]

upload_path = "/home/funk/wp-content/uploads
SAVED ABSPATH IN upload_path = "/home/funk"
NEW CURRENT ABSPATH = "/home/foo"

echo substr( WP_CONTENT_DIR, strlen( ABSPATH ) ).'uploads';

will produce "/home/funk/wp-content/uploads".

-----Original Message-----
From: Otto
Sent: Thursday, June 21, 2012 11:28 AM
To: wp-te...@lists.automattic.com
Subject: Re: [wp-testers] sorta an off the wall bug

[Otto]

On Thu, Jun 21, 2012 at 1:32 PM, Philip M. Hofer (Frumph)
<phi...@frumph.net> wrote:
> upload_path = "/home/funk/wp-content/uploads
> SAVED ABSPATH IN upload_path = "/home/funk"
> NEW CURRENT ABSPATH  = "/home/foo"
>
> echo substr( WP_CONTENT_DIR, strlen( ABSPATH ) ).'uploads';
>
> will produce "/home/funk/wp-content/uploads".

a) No, it won't.
b) You didn't say what WP_CONTENT_DIR is set to.
c) Doesn't actually matter what that produces, because that code is
only run on new installs. You're in schema.php. That code doesn't run
when moving old installs.

The upload_path is set in the database. It doesn't change when you
move an install somewhere else.

So why was upload_path set to /home/funk/wp-content/uploads in the
first place? On a new install, it is *not* set to an absolute path.
Just tested that myself.

[Philip M. Hofer (Frumph)]

actually no, but it does return with the old /home/funk/wp-content/uploads/

{ ["error"]=> string(142) "Unable to create directory
/home1/tkdanimc/public_html/nikkisprite/wp-content/uploads/2012/06

string(71)
"/home/tdoherty/public_html/nikkisprite.com/wp-content/themes/comicpress"

tkdanimc = old site
tdoherty = new site

the /home1/tkdanimc/public_html/nikkisprite/wp-content/uploads is what was
found in the upload_path


so somewhere I cannot read where it doesn't strip out the old ABSPATH
portion properly

-----Original Message-----
From: Philip M. Hofer (Frumph)

[Philip M. Hofer (Frumph)]

It did for a very long time, it might not now, just tested it as well and
mines completely blank.

-----Original Message-----
From: Otto
Sent: Thursday, June 21, 2012 11:35 AM
To: wp-te...@lists.automattic.com
Subject: Re: [wp-testers] sorta an off the wall bug

[Otto]

On Thu, Jun 21, 2012 at 1:41 PM, Philip M. Hofer (Frumph)
<phi...@frumph.net> wrote:
> actually no, but it does return with the old  /home/funk/wp-content/uploads/
>
> { ["error"]=> string(142) "Unable to create directory
> /home1/tkdanimc/public_html/nikkisprite/wp-content/uploads/2012/06
>
> string(71)
> "/home/tdoherty/public_html/nikkisprite.com/wp-content/themes/comicpress"
>
> tkdanimc = old site
> tdoherty = new site
>
> the /home1/tkdanimc/public_html/nikkisprite/wp-content/uploads  is what was
> found in the upload_path
>
>
> so somewhere I cannot read where it doesn't strip out the old ABSPATH
> portion properly

No, it doesn't strip out the old ABSPATH portion *at all*, because it
has no way to know what the old ABSPATH portion is. It can't do what
you're thinking it can do.

Look, you're looking at this all wrong and backwards here.

1. The upload_path setting is an option in the database.
2. If you have it set to an absolute path, then yes, it will attempt
to use that absolute path, hell or high-water. This is desired
behavior, because maybe I want my uploads to go somewhere special on
my server.
3. If you have it set to a relative path, then it's assumed to be
relative to the ABSPATH, whatever that is currently.

This is all correct behavior. There's no code errors there.

The question you're asking is the wrong one. What you need to find is
this: "Why was the upload_path set to an absolute path?"

At some point in the past, something happened somewhere that caused
that upload_path to be set to an absolute path. When you moved the
system, that bit you, and yes, it bit you correctly. The setting was
wrong and should not have been absolute.

But, the setting does not *default* to an absolute path, and WordPress
does not try to convert it from an absolute path to a relative one if
you have explicitly changed it to be absolute. When you put in
/foo/bar/whatever on that Settings-Media page, it assumes you know
what you're doing and takes your setting at face value.

[Philip M. Hofer (Frumph)]

Yeah, I got you, and understand. I was reiterating for Nacin who wanted
more information.

It is happening to some people, no idea why - or with what version of
WordPress it was happening with - or even if it was a plugin or theme that
might have had set it.

Which is why I have no problem referring that as a possibility to why
wp_upload_dir() fails as a thing to check when debugging those instances.

-----Original Message-----
From: Otto
Sent: Thursday, June 21, 2012 11:50 AM
To: wp-te...@lists.automattic.com
Subject: Re: [wp-testers] sorta an off the wall bug