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/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-testers@lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-testers
___
wp-testers mailing list
wp-testers@lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-testers
Re: [wp-testers] sorta an off the wall bug
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-testers@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/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-testers@lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-testers
___
wp-testers mailing list
wp-testers@lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-testers
___
wp-testers mailing list
wp-testers@lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-testers
Re: [wp-testers] sorta an off the wall bug
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-testers@lists.automattic.**com wp-testers@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-testers@lists.automattic.**com wp-testers@lists.automattic.com
http://lists.automattic.com/**mailman/listinfo/wp-testershttp://lists.automattic.com/mailman/listinfo/wp-testers
__**_
wp-testers mailing list
wp-testers@lists.automattic.**com wp-testers@lists.automattic.com
http://lists.automattic.com/**mailman/listinfo/wp-testershttp://lists.automattic.com/mailman/listinfo/wp-testers
__**_
wp-testers mailing list
wp-testers@lists.automattic.**com wp-testers@lists.automattic.com
http://lists.automattic.com/**mailman/listinfo/wp-testershttp://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!
___
wp-testers mailing list
wp-testers@lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-testers
Re: [wp-testers] sorta an off the wall bug
On Thu, Jun 21, 2012 at 9:16 AM, Otto o...@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? ___ wp-testers mailing list wp-testers@lists.automattic.com http://lists.automattic.com/mailman/listinfo/wp-testers
Re: [wp-testers] sorta an off the wall bug
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 On 21 Jun 2012, at 16:31, Andrew Nacin w...@andrewnacin.com wrote: On Thu, Jun 21, 2012 at 9:16 AM, Otto o...@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? ___ wp-testers mailing list wp-testers@lists.automattic.com http://lists.automattic.com/mailman/listinfo/wp-testers ___ wp-testers mailing list wp-testers@lists.automattic.com http://lists.automattic.com/mailman/listinfo/wp-testers
Re: [wp-testers] sorta an off the wall bug
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-testers@lists.automattic.com Subject: Re: [wp-testers] sorta an off the wall bug On Thu, Jun 21, 2012 at 9:16 AM, Otto o...@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? ___ wp-testers mailing list wp-testers@lists.automattic.com http://lists.automattic.com/mailman/listinfo/wp-testers ___ wp-testers mailing list wp-testers@lists.automattic.com http://lists.automattic.com/mailman/listinfo/wp-testers
Re: [wp-testers] sorta an off the wall bug
To fix, users who have moved their site (on the same hosting, or with .sql dumps) -Original Message- From: Philip M. Hofer (Frumph) Sent: Thursday, June 21, 2012 11:25 AM To: wp-testers@lists.automattic.com Subject: Re: [wp-testers] sorta an off the wall bug 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-testers@lists.automattic.com Subject: Re: [wp-testers] sorta an off the wall bug On Thu, Jun 21, 2012 at 9:16 AM, Otto o...@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? ___ wp-testers mailing list wp-testers@lists.automattic.com http://lists.automattic.com/mailman/listinfo/wp-testers ___ wp-testers mailing list wp-testers@lists.automattic.com http://lists.automattic.com/mailman/listinfo/wp-testers ___ wp-testers mailing list wp-testers@lists.automattic.com http://lists.automattic.com/mailman/listinfo/wp-testers
Re: [wp-testers] sorta an off the wall bug
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
___
wp-testers mailing list
wp-testers@lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-testers
Re: [wp-testers] sorta an off the wall bug
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 ___ wp-testers mailing list wp-testers@lists.automattic.com http://lists.automattic.com/mailman/listinfo/wp-testers
Re: [wp-testers] sorta an off the wall bug
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-testers@lists.automattic.com
Subject: Re: [wp-testers] sorta an off the wall bug
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
___
wp-testers mailing list
wp-testers@lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-testers
___
wp-testers mailing list
wp-testers@lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-testers
Re: [wp-testers] sorta an off the wall bug
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. -Otto ___ wp-testers mailing list wp-testers@lists.automattic.com http://lists.automattic.com/mailman/listinfo/wp-testers
Re: [wp-testers] sorta an off the wall bug
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)
Sent: Thursday, June 21, 2012 11:32 AM
To: wp-testers@lists.automattic.com
Subject: Re: [wp-testers] sorta an off the wall bug
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-testers@lists.automattic.com
Subject: Re: [wp-testers] sorta an off the wall bug
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
___
wp-testers mailing list
wp-testers@lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-testers
___
wp-testers mailing list
wp-testers@lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-testers
___
wp-testers mailing list
wp-testers@lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-testers
Re: [wp-testers] sorta an off the wall bug
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-testers@lists.automattic.com Subject: Re: [wp-testers] sorta an off the wall bug 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. -Otto ___ wp-testers mailing list wp-testers@lists.automattic.com http://lists.automattic.com/mailman/listinfo/wp-testers ___ wp-testers mailing list wp-testers@lists.automattic.com http://lists.automattic.com/mailman/listinfo/wp-testers
Re: [wp-testers] sorta an off the wall bug
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-testers@lists.automattic.com
Subject: Re: [wp-testers] sorta an off the wall bug
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.
-Otto
___
wp-testers mailing list
wp-testers@lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-testers
___
wp-testers mailing list
wp-testers@lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-testers
