Unable To Save An Image Or File - PW Websites hosted on Dreamhost [Solved]

[cstevensjr]

Good Day,

I'm having an issue with a client's PW websites that are hosted on a shared hosting package on Dreamhost.  Everything works fine, with the exception that recently you cannot save an image or file on the websites.  Files (images or pdfs) will load and the spinner never stops spinning, however the file shows 100 percent loaded. I honestly believe this is strictly a hosting related issue.

Troubleshooting So Far

These client websites (3) have been upgraded to PHP 7.3, 7.4 and 8.0.2 and the problem persists.  PW versions tested are versions 165, 172, 173 and 174.  Previously never had any issues with PW version 165 running on PHP 7.4

I run my own websites on Dreamhost (on VPS) and don't have this issue.  My PHP versions on the multiple VPS are 7.3 and 7.4.  PW versions 165, 172, 173 and 174 work with no problems noted.  No current issues with saving an image or file on the VPS hosted websites.

I have additional clients that are on PHP 7.3 and running PW Version 165 and 174 with no image or file issues.  These client websites are on Dreamhost shared hosting.

Conclusion

It seems odd that I am having this issue with one client and not others on shared hosting. I also haven't seen any recent reports in the. PW Forum of issues anyone is having with saving images or files.

If anyone has any specific idea of what's going on, I would greatly appreciate your comments and suggestions before I bring this up to the web hosting service.  Thanks.

[rick]

15 minutes ago, cstevensjr said:

cannot save an image or file ... the spinner never stops spinning ... shows 100 percent loaded

Howdy @cstevensjr

This sounds familiar in that I seem to recall similar symptoms mentioned in the forum (but cannot locate it) which I believe turned out to be related to permissions. I think it was due to the host running a script that inadvertently changed the permissions. I'll post the topic if I can locate it. In the meantime, can you verify if set_time_limit has been disabled on that account?

[Macrura]

@cstevensjr,

this started on Wednesday of this week when Dreamhost made some bizarre unilateral ModSecurity setting that broke every ProcessWire site's ability to upload images or files.

You have to open a support ticket and tell them to change the ModSec setting for every domain on your account to allow the CMS to work. They should be able to check their logs and know what to change, but you also might have to go back and forth with them and test it. I exchanged probably 10 emails with them on Wednesday while they repeatedly tweaked the ruleset until i was able to upload again.

Last night i had to send them a list of ~20 sites that they had to adjust the ruleset for and they replied today that it is now done, but only time will tell if I start to receive complaints from site owners that they can't upload.

This is certainly disappointing behavior from Dreamhost, and they should make amends. Hopefully they are going to learn a hard lesson once they get an avalanche of support complaints about this.

By the way, you can easily tell what the problem is, if you upload while viewing the network panel. You'll see probably a 418 error and when you view the response you'll see Internal Server Error. 418 is the DH response for anything related to ModSec. In addition you can go into the server logs and open the log file (which may be pretty huge by now) and see the mod sec errors.

[cstevensjr]

2 hours ago, Macrura said:

@cstevensjr,

this started on Wednesday of this week when Dreamhost made some bizarre unilateral ModSecurity setting that broke every ProcessWire site's ability to upload images or files.

You have to open a support ticket and tell them to change the ModSec setting for every domain on your account to allow the CMS to work. They should be able to check their logs and know what to change, but you also might have to go back and forth with them and test it. I exchanged probably 10 emails with them on Wednesday while they repeatedly tweaked the ruleset until i was able to upload again.

Last night i had to send them a list of ~20 sites that they had to adjust the ruleset for and they replied today that it is now done, but only time will tell if I start to receive complaints from site owners that they can't upload.

This is certainly disappointing behavior from Dreamhost, and they should make amends. Hopefully they are going to learn a hard lesson once they get an avalanche of support complaints about this.

By the way, you can easily tell what the problem is, if you upload while viewing the network panel. You'll see probably a 418 error and when you view the response you'll see Internal Server Error. 418 is the DH response for anything related to ModSec. In addition you can go into the server logs and open the log file (which may be pretty huge by now) and see the mod sec errors.

Thanks!

[cstevensjr]

@Macrura,

Thanks again for your detailed and to-the-point report on what happened at Dreamhost.  I was able to get Dreamhost to adjust the ModSec ruleset and things are working again.

[Hani]

A bunch of my old clients started having this issue on Dreamhost as well.  Like @cstevensjr, I noticed that any domains on a VPS weren't affected. However, some domains on shared hosting plans were affected while other ones were not.  Probably a difference between servers, but not certain why shared servers would have different ModSec settings.

Anyway, I was lucky to chat with a tech that was patient and knew his stuff.  (Shout out to John B!)  We worked through one of the affected domains and he figured out what ModSec rules were being tripped by the uploads. So he had to add exceptions to those rules until the uploads worked - even with the Extra Web Security option still enabled for the domain.  After we got one domain working, he replicated the same exceptions to the other domains and we tested each one as we went.

He kindly shared the list of rules that were causing the problem after I asked for them (in case this issue popped up again or if I had to speak to another agent about another domain).

The rules being tripped were:

• application-multi
• language-multi
• platform-multi
• event-correlation
• attack-generic

If you have to talk to a Dreamhost tech to get this problem resolved, it may be helpful to point them to this post or simply pass them the list of rules being tripped that need exceptions added.  Like I mentioned earlier, and unfortunately, these rule exceptions need to be added on a domain-by-domain basis.