Open cybeardjm opened 1 month ago
Just tried this too, and while cropping takes ... long, it eventually did work. At first I thought it had failed, though! But the cropped image got saved and set as my header image.
Seeing this in the logging, however:
[09-Aug-2024 19:46:14 UTC] PHP Warning: Undefined array key "context" in wp-admin/includes/ajax-actions.php on line 4017
[09-Aug-2024 19:46:14 UTC] PHP Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in wp-admin/includes/ajax-actions.php on line 4017
[09-Aug-2024 19:46:14 UTC] PHP Warning: Undefined array key "dst_width" in wp-admin/includes/ajax-actions.php on line 4019
[09-Aug-2024 19:46:14 UTC] PHP Warning: Undefined array key "dst_height" in wp-admin/includes/ajax-actions.php on line 4019
Looks like maybe this is just WordPress core.
is it possible to validate images that already have the proper ratio, without the need to recreate a cropped image?
Not sure, but this could be a "WordPress thing." I remember setting a site icon and WordPress asking me to "crop" it even when it was already square. I think the idea is maybe it still wants to let people crop away some of the image (like the edges or whatever).
Thx @janboddez - checked my errorlog and have nothing... Might mean the error is triggered very early in my blogs (it's "instantaneous") and nothing happens that generates logging (?)... Oh sure, it could be a WP core problem. Just did notice it with AP, because it requires/forces this cropping...
Don't know if it's connected or not, but found 2 bad URLs in the same context:
The ap_extrafields
post type is registered as non-public, so this may have to do with your specific blog setup ...
That said, I don't think I like stuffing all this in the wp_posts
table. Not sure why it was chosen over storing these extra fields as an array in wp_usermeta
instead. Could have just provided a table with 4 key/value rows like Mastodon does it, and store the image URL(s) alongside those fields.
Because we had to serialize it then. User-meta does not support keys and the meta is not limited to only 4 items (that's a mastodon thing). Besides of that: I like the idea of having block-editor support for these extra fields.
The cropping seems to be an issue that came with the latest WordPress version. I will investigate why this happens.
Quick summary
When trying to add an image as "Header Image" for an AP author, cropping fails "There has been an error cropping your image." and no image is added, even if the image already has the proper ratio.
Steps to reproduce
Logged to WordPress as the Author/Editor, declared as the AP author for my blog (not the blog-profile then).
From the User Profile, I can choose an existing image from Media or upload a new one. After selecting the desired image, it forces to crop it, probably to respect Mastodon's ratio (1500*500px), even if image already has the proper ratio (appears fully selected, but have to validate the selection).
When validating the cropping selection, it fails with an error message "There has been an error cropping your image.". Operation has to be aborted, no header image added.
PS: new uploads appear in Media.
Behavior reproduced on 2 different blogs.
What you expected to happen
1 - cropping works if needed 2 - is it possible to validate images that already have the proper ratio, without the need to recreate a cropped image? 3 - add information around the "Header Image" area in profile, to specify the max image size.
What actually happened
No Header Image, process interrupted.
PS : I suppose (hope) roles such as Author or Editor have the WordPress right to crop image...
Impact
Some (< 50%)
Available workarounds?
No but the platform is still usable
Logs or notes
WordPress and plugins up-to-date to latest versions.