Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#13880 closed defect (bug) (fixed)

Custom Header Image Upload Bug

Reported by: CAMWebDesign Owned by: ocean90
Milestone: 3.0 Priority: high
Severity: normal Version: 3.0
Component: Upload Keywords: has-patch
Focuses: Cc:


Using WordPress 3.0-RC3-15241 getting a bug that appears after you upload a custom header image that is exactly 940 × 198 pixels. Since no cropping is necessary the image is used as-is, but the edit crop box feature appears over the Browse file input in the Upload Image portion.
Using Firefox 3.6.3, but also replicates with IE6-8.

Attachments (2)

custom_header_bug.jpeg (96.0 KB) - added by CAMWebDesign 4 years ago.
Custom Header Upload Bug
13880.patch (784 bytes) - added by ocean90 4 years ago.

Download all attachments as: .zip

Change History (11)

CAMWebDesign4 years ago

Custom Header Upload Bug

comment:1 Eriksrocks4 years ago

  • Keywords upload form cropper controls added

I can confirm this. Firefox 3.6.3, Windows 7 x64. I also uploaded a header image that was exactly 940 x 198. Using the default theme, obviously.

comment:2 nacin4 years ago

  • Keywords needs-patch added; Custom Header Image upload form cropper controls removed
  • Owner set to ocean90
  • Priority changed from low to high
  • Status changed from new to assigned

comment:3 Eriksrocks4 years ago

I did a little investigation on this issue and have come up with what may be a solution. At the very least it will help whoever this is assigned to in patching this issue. What's happening here is that the upload form on step 1 of the page has the same id ("upload") as the uploaded image that is displayed on step 2 for cropping.

If the uploaded image already is already the size of the current header, the script displays the contents of the original "upload an image" page. However, because step 2 technically executed, the JavaScript for Step 2 is also output to the page (including the JavaScript for putting the cropping controls on the uploaded image with an ID of "upload"). This is where the conflict occurs - the JavaScript places the cropping controls on the upload form, because it has an ID of upload.

The simple fix is to change the jQuery selectors so they only match an image with an ID of "upload", and thus no cropping controls appear over the upload box.

These lines need to be changed in /wp-admin/custom-header.php:

Line 374

var ximg = jQuery('#upload').width();


var ximg = jQuery('img#upload').width();

Line 375

var yimg = jQuery('#upload').height();


var yimg = jQuery('img#upload').height();

Line 387




I've casually tested this. Upon uploading an image of the exact size, the cropping controls no longer appear over the file upload field, and normal cropping with non-perfectly-sized images still works as expected, so I don't think I've broken anything.

I would patch to SVN but I don't have any experience in doing so and I'm not sure whether this is the proper fix, so I thought I would just post it here for review.

comment:4 nacin4 years ago

I think part of the problem here is that we're doing processing in ::admin_page() instead of before anything has been sent, which would be a lot easier in terms of processing data then deciding what should be rendered, which would allow for a redirect, a proper wp_die(), or conditionally printing javascript, etc.

Your fix seems fine for 3.0, and we can improve the architecture in a future release. If you want to learn how to create a patch, take a look at http://core.trac.wordpress.org/#HowtoSubmitPatches.

comment:5 Eriksrocks4 years ago

I will submit a patch in the morning if it has not already been submitted. :)

ocean904 years ago

comment:6 ocean904 years ago

  • Keywords has-patch added; needs-patch removed
  • Status changed from assigned to accepted

CAMWebDesign, good catch. I'm fine with your 'patch'. Props goes to you.

comment:7 nacin4 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

comment:8 nacin4 years ago

Sorry eriksrocks, I got confused due to ocean90's comment and grabbed the wrong name for props. Thank you for your contribution :-)

comment:9 ocean904 years ago

Sorry. :)

Thanks eriksrocks!

Note: See TracTickets for help on using tickets.