Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #58202, comment 13


Ignore:
Timestamp:
06/13/2023 06:04:21 PM (3 years ago)
Author:
SergeyBiryukov
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #58202, comment 13

    initial v1  
    11Just wanted to add a comment here to hopefully provide further clarity on the issue.
    22
    3 The reason that the update from [https://core.trac.wordpress.org/changeset/55404] caused this breakage is that the Imagick timeout setting begins counting from its first instantiation within the PHP process. As we know, many server configurations are setup to spawn a few PHP processes and reuse them over many requests, only spawning new processes when needed. So, by forcing the Imagick timeout value to align with the PHP timeout value, after a couple of requests, you're effectively setting the Imagick timeout to a value that has already elapsed, which then times out, causing that PHP process to exit. The server will replace that PHP process with a new one, starting the whole process over again.
     3The reason that the update from [55404] caused this breakage is that the Imagick timeout setting begins counting from its first instantiation within the PHP process. As we know, many server configurations are setup to spawn a few PHP processes and reuse them over many requests, only spawning new processes when needed. So, by forcing the Imagick timeout value to align with the PHP timeout value, after a couple of requests, you're effectively setting the Imagick timeout to a value that has already elapsed, which then times out, causing that PHP process to exit. The server will replace that PHP process with a new one, starting the whole process over again.
    44
    55I hope this information is helpful, and that the issues can be patched very soon. In the meantime the only way to correct this issue on an affected site is to comment out the Imagick::setResourceLimit call in class-wp-image-editor-imagick.php.