XF 2.3 Optimizing attachments leads to Oops! We ran into some problems

[Num7]

Hi,

I enabled WebP support in the board's options and it works fine. Then I went to the Rebuild Caches page in the adminCP and attempted to optimize the attachments. It ran for a little while, then Oops, error. If I run it again, it fails right away with the same Oops error.

I have to assume that the first time, it did process a certain number of images, then got stuck on one that it couldn't handle.

It doesn't leave a trace in the server log in the adminCP. Nothing interesting in the Chrome console either. Any idea where I could find more info? Or perhaps, pinpoint the attachment that won't cooperate?

Thanks!

 

[Chris D]

“Page could not be found” is definitely an unexpected error here. This leads me to believe that it might actually be something on the server that’s blocking the request.

This is just not an error we would display here.

The chrome console could be interesting however. It should log specifically what URL it is trying to access and also clarify the http status code. Given the text it is probably 404 but would be interesting to know the URL nonetheless.

Looking at the failed request in the network log may also present some clues as to where the error is coming from. Sometimes these things set response headers with other clues as to what generated the error.

I don’t think we’ll get any clues specifically on which image is the problem, although we do track in the database which have been optimized so far. The first one that isn’t is probably the culprit but I still think whatever is causing the request to fail should be the focus rather than the attachment itself.

 

[Num7]

Hi @Chris D , thanks for the reply!

It's not much, but here's what I could find in the Chrome console.



Also, I went ahead and found the attachment at which it stopped processing. It's a 1.6MB GIF... Here it is.



I'll continue searching. Thanks!

 

[Chris D]

Yeah it was mostly as I thought, although the "Response headers" are collapsed in the screenshot which may (or may not) contain other clues.

But, either way, there's nothing we do at that URL which returns a 404 so I'm pretty certain at this point that something in the server itself is sniping the request.

 

[Num7]

Yeah it was mostly as I thought, although the "Response headers" are collapsed in the screenshot which may (or may not) contain other clues.

But, either way, there's nothing we do at that URL which returns a 404 so I'm pretty certain at this point that something in the server itself is sniping the request.

Here's the header:

 

[Chris D]

No particular clues there, but given that you're running behind Cloudflare, it's possible that could be doing something. That'll be worth looking into.

 

[Num7]

No particular clues there, but given that you're running behind Cloudflare, it's possible that could be doing something. That'll be worth looking into.

Good idea. I modified my nameservers so that CloudFlare is no longer in the equation. Still the same behavior.

Here's the Chrome console:



I'm not sure what to do next. Do you think my hosting provider's support may be able to spot something in the server logs, on their side?

 

[Chris D]

Yeah that would be my next step.

They may (will) blame the software. But nothing in our code would return a 404 here so keep pushing them.

 

[Num7]

@Chris D My hosting provider is still investigating the issue.

In the meantime, I deleted the 1.5MB GIF that I spotted earlier. Then I ran the optimization job again, and it was able to process more images. Then I got the error again. I was able to locate the next image it was supposed to process. It's a 5.25MB JPG. What do you think, could it have to do with the file size?

 

[Num7]

Okay, it was the PHP configuration and upload max size limits, max memory, etc. My hosting provider increased them all to higher values, it did the trick.

Thank man!