[wp-trac] [WordPress Trac] #21785: Add header image uploads with cropping to the customizer
WordPress Trac
noreply at wordpress.org
Mon Mar 24 19:13:30 UTC 2014
#21785: Add header image uploads with cropping to the customizer
----------------------------+-----------------------------------------
Reporter: nacin | Owner:
Type: task (blessed) | Status: new
Priority: normal | Milestone: 3.9
Component: Appearance | Version: 3.4
Severity: normal | Resolution:
Keywords: has-patch | Focuses: javascript, administration
----------------------------+-----------------------------------------
Comment (by nacin):
Replying to [comment:38 ehg]:
> Placing the suggested dimensions in the Attachment Details sidebar feels
a bit wrong, as the suggested dimensions aren’t particular to a specific
image (see https://cloudup.com/iTMNezhnAI6). The idea behind putting them
in the Media Manager’s title was to show the dimensions no matter what
context you’re in - the suggested dimensions can be seen when you’re
uploading *and* selecting an image (see https://cloudup.com/iDXX9n9Busq).
An alternative would be to just not show the dimensions in the Media
Manager at all, and rely on them being noticed in the Header section.
I get why you'd want them to be shown during upload — at that point,
perhaps it would be appropriate to include it actually in the uploader
instructions. As in, near "Maximum upload file size:", where allowed file
types would be listed, etc.
My point was that the suggested dimensions should appear *above* the
Attachment Details sidebar, such as how gallery settings are rendered.
Likewise, we don't want/need captions or other fields here.
----
> We’d like to make the case for a better, broader solution to error
handling that would go beyond this ticket: adding a Customizer error
handler that would display error messages by binding to customize(‘error’)
events - see https://cloudup.com/ihRG2lmDTkC . We could also use the
proposed error handling in the Customizer to show ‘crop failed’ events
from the Media Manager.
Yeah, I think that makes sense. For the moment, we just need to make sure
that if/when an XHR fails, things don't go completely haywire. (No JS
failures, etc.)
----
> was there any reason why the unit tests weren’t committed? Do they need
more work?
Omitting them wasn't intentional. I'll get them in. Was there a decision
on sinon?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/21785#comment:41>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list