[wp-trac] [WordPress Trac] #40441: High server resource usage and timeouts during image uploads

WordPress Trac noreply at wordpress.org
Fri Apr 14 14:25:13 UTC 2017


#40441: High server resource usage and timeouts during image uploads
-------------------------+------------------------------
 Reporter:  enshrined    |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Media        |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+------------------------------

Comment (by blobfolio):

 Replying to [comment:4 enshrined]:
 > I see what you mean about the `multi_resize` function but I've
 personally not seen many themes or plugins re-instantiating the
 `WP_Image_Editor_*` classes, do you have any examples of why they may want
 to do this?

 In terms of user space, I'm more concerned with filter hooks and wrapper
 functions than direct calls to the image classes. Their documentation is
 much easier to locate and understand than the image editor classes, so
 developers will use them more often. Here's an example:

   Themes often define their own thumbnail sizes. But when a user changes
 themes, old media isn't going to be resized en masse to match the new
 definitions. On the frontend, `src` calls might return the original (huge)
 source media and `srcset` calls might return nothing at all, both leading
 to imperfect presentation. A theme could work around this by hooking into
 filters like `image_downsize`, `wp_calculate_image_srcset`, etc., to run
 checks to see if the sized file exists, and if not, create it with
 `image_make_intermediate_size()`. Works like a charm, except that
 `image_make_intermediate_size()` will create a new editor object at each
 pass.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/40441#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list