Changes between Initial Version and Version 1 of Ticket #6814, comment 26
- Timestamp:
- 06/13/2022 07:22:36 PM (4 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #6814, comment 26
initial v1 12 12 The negative effect from point 1 can probably be fixes to a large extend by creating just two sub-sizes on uploading an image, the `large` and `thumbnail` sizes. That will cover most use cases. In the rest of the cases WP will fall back on using one of these sub-sizes until the rest are created (that functionality already exists). As a side-note this won't work well for custom sub-sizes that crop the image. 13 13 14 For point 2 there are several options. The above approach can be changed a bit so only one or two su p-sizes are created on each request. That may become a problem after uploading a lot of images (making a big gallery) on a site that sees a little traffic, but would be better than "locking down" the site for seconds.14 For point 2 there are several options. The above approach can be changed a bit so only one or two sub-sizes are created on each request. That may become a problem after uploading a lot of images (making a big gallery) on a site that sees a little traffic, but would be better than "locking down" the site for seconds. 15 15 16 16 Another approach may be to try to implement the "selective sub-size creation method". Then only image sub-sizes that are requested will be created. Good part of it is that it will reduce disk use for sub-sizes, bad part is it would slow-down front-end image load times when the needed sub-size(s) do not exist yet. That slow-down may be quite significant when loading a gallery. Also thinking this may be affected by HTTP/2 and may result in PHP running out of memory or timing out when a lot of sub-sizes have to be created.