Make WordPress Core

Opened 14 years ago

Closed 13 years ago

Last modified 11 years ago

#11136 closed defect (bug) (worksforme)

Media upload tabs broken if not deployed in root

Reported by: s3000xl's profile 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)

#1 @demetris
14 years ago

  • Keywords reporter-feedback added

s3000xl, what version is this for?

I was unable to replicate for WP 2.8.6 and WP 2.9-rare.

#2 @miqrogroove
14 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 @jclarkcutler
14 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 @nacin
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?

#5 @nacin
14 years ago

  • Milestone set to Unassigned

#6 @dd32
13 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.

#7 @hakre
13 years ago

Related: #16932

That ticket also has a hotfix patch.

#8 @SergeyBiryukov
11 years ago

#22427 was marked as a duplicate.

#9 @SergeyBiryukov
11 years ago

#17669 was marked as a duplicate.

Note: See TracTickets for help on using tickets.