Hi,
It's not the same problem at all.
What you need to understand is that as long as there is a problem with the AJAX request asking for the new content of the filter module area, the module won't be refreshed. It can come from anything on the server side.
The code modification in the view file just deactivate the AJAX so of course, for such problems that solution will work.
But that doesn't mean that it's the same cause, and it's not since the patchs we've added for that other thread are still in there.
Also, on that other thread, the issue was not caused by a 500 HTTP error but something where we did get back an error message in the response so it was easy to identify.
Here, the only information returned is that there is a 500 error. Normally, in such case, the cause of the issue is written in the logs of the server.
So in order to fix the issue, we first need to get some error message to be able to understand why this is happening.
Let's go back to one of your previous message:
a) errors.log file doesn’t contain any error information
errors.log is the apache error log, not the PHP error log.
b) they checked that only in Google Chrome in the Console is information indicated error 500 but for example on Firefox there is no information regarding error 500 (however filters doesn’t reset also in Firefox)
Your hosting provider is completely wrong here. I get the exact same error in Firefox:
monosnap.com/file/lvCEP4pqxJEt0MdfNyaeHEIoupgsBB
It's not int he console that there is the error but in the "network" tab, where you can check the AJAX requests responses...
This leads me to believe that the person you got didn't understand what they were looking for.
c) based on above in their opinion problem is generated between application and browsers and is not related with the server
And I'm not denying this. It's probably a bug in the application. However, to understand what is the problem, we need some kind of error message. A 500 server error indicates that it's the web server which returned a 500 error instead of displaying a blank page with the PHP error message, and so in such case, the PHP error message should be logged in the PHP error log. Or that error doesn't come from the PHP but from the server, and in that case, it should be logged in the apache error log (and the issue is probably linked to the way the server is configured (for example, the URL is too big and thus the request was refused or something))
The best would be to configure the server to display the fatal error instead of a 500 server error page:
stackoverflow.com/questions/22170864/500...r-error-how-to-debug