• Welcome to the Chevereto user community!

    Here users from all over the world gather around to learn the latest about Chevereto and contribute with ideas to improve the software.

    Please keep in mind:

    • 😌 This community is user driven. Be polite with other users.
    • 👉 Is required to purchase a Chevereto license to participate in this community (doesn't apply to Pre-sales).
    • 💸 Purchase a Pro Subscription to get access to active software support and faster ticket response times.
  • Chevereto Support CLST

    Support response

    Support checklist

    • Got a Something went wrong message? Read this guide and provide the actual error. Do not skip this.
    • Confirm that the server meets the System Requirements
    • Check for any available Hotfix - your issue could be already reported/fixed
    • Read documentation - It will be required to Debug and understand Errors for a faster support response

3.20.2 update fails and blocks site due to Imagick WebP support error

Status
Not open for further replies.
P

Pro

Chevereto Member
▶ Reproduction steps
  1. Update from 3.18.0 to 3.20.2
  2. Update is interrupted, whole site is inaccessible
😢 Unexpected result

During the update process, it just stops, and the whole site is replaced with the below error (including the dashboard which is inaccessible)

WebP file uploads in our case are disabled, and obviously since 3.18 is working, it's fine with the Imagick version setup.

I did some googling, and per this SE thread can confirm Imagick is not compiled with WebP support, but according to this cPanel thread for the foreseeable future, it won't be either, except with CloudLinux.

Given the ubiquity of cPanel and that others have experienced this issue (here is an example thread I found in google from this forum about the issue), and that it is working fine in 3.18, I suspect it might be something to look into for compatibility in one of the most standard hosting infrastructures.

For our case, since we do not use/allow WebP uploads, at least for the short term would you say that the solution from the above thread in this forum could be used without negative implication? That is, on line 93, to remote 'WEBP' from the array:

PHP: 
   $mustHaveFormats = ['PNG', 'GIF', 'JPG', 'BMP', 'WEBP'];

I have tested this and it allows us access to the site (at present we had to restore a backup before we got confirmation) but I want to make sure there are no other implications of doing this as long as we don't use WebP.

In addition to (or perhaps instead of) the above workaround, could you let me know if this is worth it for you and something that could be addressed in a hotfix?

Thank you.

📃 Error log message

System error
The system has encountered errors in your server setup that must be fixed to use Chevereto:

Imagick WEBP image type support is not enabled.
Need help? Follow the Troubleshoot.

(screenshot: https://www.dropbox.com/s/177b1lse5ugwl16/2021-06-04_16-30-44.png?dl=0)
 
Solution
P
Thanks. I was unable to change the output location of the logs with any manipulation of settings.php, e.g.

Code: 
'error_log' => '/home/user/chev_error.log',
'error_log' => '/chev_error.log',
'error_log' => '../chev_error.log',
'error_log' => '/home/user/public_html/chev_error.log',
etc.

In the end I found that in my environment, cPanel was by default creating the logs at: /home/user/logs/do.ma.in.php.error.log

Once I got a hold of those I found the source of the above issue: for some reason the update destroyed/corrupted/changed paths/something or in some way wiped out the watermark, so I was getting:

Code: 
>> Intervention\Image\Exception\NotReadableException [0]: Unable to read image from path...
Sort by date Sort by votes
Any chance at help with this or a message from @Rodolfo ?

I understand this is a requirements conflict, but

(a) I am using cPanel, an industry standard of hosting, and thus the default implementation of Imagick without WebP support is going to affect a LOT of people, including people who already posted at I mentioned in the above thread, and​

(b) there seems to be some logical skips that cause the site to be completely blocked when WebP support is not enabled, such as​
(i) not checking before the update and giving a warning, which one could say is best practices,​
(ii) especially web WebP file uploads are not even enabled on Chevereto (i.e. and thus why do we need WebP support for Imagick? perhaps another check there to make it more user-friendly? "you cannot enable this without...")​

Furthermore, in the cPanel thread I linked to above, it is stated that cPanel does not have support for this configuration by default (and my host said they found no feature request - at least with any momentum - for this to be included) except for with CloudLinux, which is an extremely niche situation.

They responded to me saying there is no supported way to do this which is completely compatible with cPanel, and any manual compiling of Imagick they would do could either break things inadvertantly (this has always been a problem with cPanel, naturally when it's meant to manage so much) and even if it didn't, cPanel could overwrite it on any given update/recompilation of its own.

This just seems like a user-hostile implementation all around:

  • Requiring a new dependency on an update
  • Irrespective of whether WebP is even used on the script
  • Not warning the user of it before updating
  • Blocking access to the whole site including the Dashboard if that dependency is not met
  • Thus forcing manual code editing to bypass, complete restoration from backup, or recompilation of software in direct contraindication to literally the biggest retail server management software provider on the planet

At the very least can you confirm @Rodolfo that as long as WebP images are not allowed to be uploaded (via the checkbox being unchecked in Dashboard settings for allowed types), that one can comment out WebP for the compatibility check script as I mentioned in my previous post - if not resolving any one of the above issues to either (a) prevent an update without blocking the site, or (b) not make it a requirement if it's actually not a requirement (i.e. WebP disabled on the script)?

Thank you.
 
Upvote 0 Downvote
Thanks that lifted the site block error, but the uploads stopped working when the site actually came back up:

Dropbox

www.dropbox.com www.dropbox.com

I have debug level set to 3 and there are no error logs being written anywhere we could find. Not in apache, not in public_html, etc.
 
Upvote 0 Downvote
Thanks. I was unable to change the output location of the logs with any manipulation of settings.php, e.g.

Code: 
'error_log' => '/home/user/chev_error.log',
'error_log' => '/chev_error.log',
'error_log' => '../chev_error.log',
'error_log' => '/home/user/public_html/chev_error.log',
etc.

In the end I found that in my environment, cPanel was by default creating the logs at: /home/user/logs/do.ma.in.php.error.log

Once I got a hold of those I found the source of the above issue: for some reason the update destroyed/corrupted/changed paths/something or in some way wiped out the watermark, so I was getting:

Code: 
>> Intervention\Image\Exception\NotReadableException [0]: Unable to read image from path (/home/USER/public_html/content/images/system/watermark_ID.png).
At /app/vendor/intervention/image/src/Intervention/Image/Imagick/Decoder.php:29

>> Intervention\Image\Exception\NotReadableException [425]: improper image header `/home/USER/public_html/content/images/system/watermark_ID.png' @ error/png.c/ReadPNGImage/4104
At /app/vendor/intervention/image/src/Intervention/Image/Imagick/Decoder.php:25

Reuploading the watermark after the update plus disabling WebP via settings.php (even though the latter was already unchecked in the Dashboard) means we can finally use 3.20 and get the watermark fix. Thank you 🙂
 
Upvote 0 Downvote
Solution
Status
Not open for further replies.
Back
Top