Opened 15 years ago
Closed 15 years ago
#13720 closed defect (bug) (fixed)
Custom header UX improvements
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 3.0 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Administration | Keywords: | commit i18n-change has-patch |
Focuses: | Cc: |
Description
- nonce isn't kicking in after upload/crop. When you come back to the screen, a refresh that resubmits the POST data will crop your cropped image further.
- I believe the Crop button should be blue.
- We need to validate that an image is actually getting uploaded. It took an HTML file for me and after having me crop an image of a broken image, it then threw errors. We can probably extend the 3.0 commits in #11946.
- Clicking "Upload" without choosing a file calls wp_die() but after admin-header is already generated. We should either move that to wp_die() or redirect back with an error message if possible.
We should check custom background for some of these as well.
needs-patch(es). I will work on this a bit but if someone else wants to run with it, be my guest.
Attachments (3)
Change History (15)
#3
@
15 years ago
jane, that's a good point. This could also fix the problem with the reload (point 1).
- upload an image
- crop it (if you want)
- change button "Crop image" to "Crop image and return back", maybe add also a button "Cancel"
- positiv: it's not directly live
- when we redirect back we post the path to the cropped image and fill a hidden input field with the path
- Save the header settings and the path when you click "Save Changes"
What do you think?
#4
@
15 years ago
I think that when we change the behavior, the button should still say crop, because that's what it's meant to do. If we wanted to differentiate, we should have made it say 'crop & publish' for 3.0 (and we really should have, to set up the proper user expectation and avoid unintentional publishing of headers), but i believe we are in string freeze now.
#5
@
15 years ago
I would say, because we are in string freeze, already in RC2 and it's not a regression we should only change the button color and the rest in early 3.1.
#6
@
15 years ago
Going live immediately with the crop is something I am always forgetting, but it's quite important I feel. Since it seems we're leaving the 3.0 behavior -- which I did not bother to address here -- I would be unopposed to changing the string to "Crop and Publish" and letting the translators know.
#8
@
15 years ago
- Keywords has-patch added
After a discussion with nacin we want only the blue (with the i18n-change?) in 3.0 and the other points in 3.1, because it needs a bigger change to handle better the error messages and redirects.
Yes, the crop button should be blue, since it doesn't take you back to the screen to save changes, but just publishes the cropped image, making it a primary submit button.
In the future, I'd prefer for clicking crop to return you to the previous screen so you can see the cropped image in the previewer and then click on update or choose to discard it rather than going immediately live.