#11136 closed defect (bug) (worksforme)
Media upload tabs broken if not deployed in root
Reported by: | s3000xl | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Upload | Keywords: | reporter-feedback |
Focuses: | Cc: |
Description
If you deploy in a directory other than the root directory (e.g. /blog/) then when you click the tabs in the media-upload.php dialogue it tries to load /wp-admin/media-upload.php?tab=xxx instead of /blog/wp-admin/media-upload.php?tab=xxx
Assuming this needs to use the admin_url() function or similar. Tracked the problem down to the_media_upload_tabs() in wp-admin/include/media.php.
Change History (9)
#2
@
15 years ago
- Milestone Unassigned deleted
- Resolution set to worksforme
- Status changed from new to closed
Unable to reproduce. Please re-open this ticket if you can demonstrate the bug.
#3
@
15 years ago
- Resolution worksforme deleted
- Status changed from closed to reopened
I encountered this problem as well. I performed the following fix to my own codebase, but I am new to PHP and WordPress so I encourage more experienced users/developers to review the change:
On line 81 of wp-admin/includes/media.php, I added admin_url('media-upload.php') as the oldquery_or_uri for add_query_arg. That is, I changed the code from
$href = add_query_arg(array('tab'=>$callback, 's'=>false, 'paged'=>false, 'post_mime_type'=>false, 'm'=>false));
to
$href = add_query_arg(array('tab'=>$callback, 's'=>false, 'paged'=>false, 'post_mime_type'=>false, 'm'=>false), admin_url('media-upload.php'));
From what I gather, the problem occurs when an intermediate server proxies a non-root URL to another server powering WordPress. When add_query_arg() is called without the final arg oldquery_or_uri, $_SERVERREQUEST_URI? is used as the base URL. This won't include the non-root portion of the URL, however, which was stripped by the proxy server before sending the request to the upstream server. (When WordPress is installed as a traditional/real subdirectory of a server there shouldn't be a problem because no portion of the REQUEST_URI gets stripped.)
For example, suppose www.example.com is handled by a proxy server configured to direct requests for /blog to a custom-compiled server:
A client clicks the "Add an Image" button on the "Edit Post" page, issuing a request to www.example.com/blog/wp-admin/media-upload.php?<...>.
The request to www.example.com/blog/wp-admin/media-upload.php?<...> is handled by the proxy server.
The proxy server sends a request for /wp-admin/media-upload.php?<...> to the custom server.
In generating a response, add_query_arg uses the REQUEST_URI to build a link that points to www.example.com/wp-admin/media-upload.php?<...>.
This is *incorrect*; the /blog component of the path is missing. However, if the user has appropriately set the URLs for home and siteurl, admin_url() will include the subdirectory component as desired.
#4
@
14 years ago
Not sure how we should fix this (it would appear in many locations) or whether this is our problem. Shouldn't the setup be correcting server variables?
#6
@
14 years ago
- Milestone Awaiting Review deleted
- Resolution set to worksforme
- Status changed from reopened to closed
Shouldn't the setup be correcting server variables?
Yes.
If the repoters still have this problem, Could you please dump the $_SERVER
vars out? Preferably do this in wp-config.php AND in media-upload.php, This'll allow us to determine if your $_SERVER
vars are set incorrectly, or if WordPress is correcting them incorrectly.
As nacin pointed out, add_query_arg() is used in many places without a specific URL, if the problem exists in one location, it should exist throughout the installation.
For now, I'm re-closing as worksforme until some debug information can be provided, please feel free to re-open it with such information however.
s3000xl, what version is this for?
I was unable to replicate for WP 2.8.6 and WP 2.9-rare.