Recently, I've started seeing a lot of Prestashop stores that happened to experience Internal server error issue. In the past, this was explained by Prestashop themselves (link) but that was back in 2013 and many things have changed since than.

More then anytime before, messages like: 

Oops, something went wrong. 
This page isn't working, acme.website is currently unavailable to handle this request. HTTP ERROR 500
The server encountered an internal error or misconfiguration and was unable to complete your request.

 

I'm a developer, so I'm facing this issue all the time, I thought I have it managed, up until Prestashop 1.7 came out and brought new level of error intrigue. With introduction of Symphony, Prestashop core become more complex, errors more buried down and it become increasingly more difficult to locate the problem.

Here are thought few suggestion that could you help you with fixing Internal Server Error (a.k.a. 500 server error). 

Understand why 500 internal server error in Prestashop appears

Purpose of this error is to hide real cause of problem in code - which could expose vulnerability to attacker. So web-server, instead of real error, with filename, path, and details, flushes to browser just this famous message.

Let's look now how to get the Prestashop 1.7 to show actual cause of problem, so that we can resolve it.

1. The most powerful weapon - debug mode

This resolves 95% right away. Just enable debug mode and reload page, if you're lucky enough, detailed error message would be shown.

2. View logs (where are log files located in Prestashop 1.7)

If debug mode is not very helpful, another chance is looking at log files. In Prestashop 1.7, this has changed as well and log files are now in /var/logs directory, either dev.log or prod.log, depending on whether you're running Prestashop in debug mode.

Also make sure to check error_log file, if it's available on your hosting - typically in root folder.

3. .htaccess directives

Sometimes, nothing appears even with debug mode, there's nothing in logs, and that's very difficult situation even for experienced web developers. 

When this happens, major issue is due to wrong directives in .htaccess file. To test this out, simply rename .htaccess in root folder, to something like .htaccess-backup, and reload page. If error is gone, great, you know why; if it's not, we need to dig further. 

4. Database constraint (specialty in Prestashop 1.7.4+)

In past few months, I've observed this multiple times, it's not very common, and it affect only some version, typically when it's update from early PS 1.7 versions to newer PS 1.7 version (1.7.4+). The thing is, Prestashop changed core class from Address to CustomerAddress and should you have DB constraint set to Address object, that would remain in database, but now it's not possible to manage it from Prestashop Backoffice anymore.

That was useless tech talk - how to check this? Go into database and look at table 'ps_required_field' and should it contain any records, delete them.

5. Delete all server caches

To flush server caches, you can simply use the button Advanced Parameters / Performance, but sometimes, you can't even access Backoffice in order to trigger this function, and then it comes handy to know what to do. Caches are stored in /var/cache/dev or /var/cache/prod, depending on whether you're running Prestashop in debug mode.

You can comfortably delete those directories, caches will be recreated. This by it's own does not resolve problem, it only helps you to understand where the problem could be

6. Prestashop 1.7.6 displayError() update

Since PS 1.7.6, now displayError by default goes to Internal server error 500, without exposing real cause. I suggest to comment out following line in classes/Tools.php:

header('HTTP/1.1 500 Internal Server Error', true, 500);

This is especially important if you're using EU VAT module, which uses displayError for standard error reporting, while Prestashop core decided to show error 500 with every displayError calls - hopefully, this will change in EU VAT module in future.

7. Mailchimp module

Recently (beginning of year 2020), I've seen many issues with mailchimp module, so if you're facing erratic behavior, make sure to disable this module and make several tests without it. Mailchimp issue reveals itself especially when used together with (true dynamic/ajaxified) one page checkout.