Within specific forums, when we change from Condensed View to Expanded View, the page returns a Http Error 500. We can still access the second page of that forum by manually entering /page/2/ to the URL, and from there changing back to Condensed View to be able to get back access to the first page.

This is happening to all our users, across all devices and themes. Those specific forums can be viewed if the user logs out though, since the forums are in Condensed View by default to guests. If you log back in while within those problematic forums, it takes you to the second page.

Before we go any further on that, could I ask if you have any custom furls? If so, please revert those and try again. Same with any other 3rd party items, but check furls first 

12 minutes ago, Marc Stridgen said:

Before we go any further on that, could I ask if you have any custom furls? If so, please revert those and try again. Same with any other 3rd party items, but check furls first 

From where could I check this? I'm not aware of how to create custom furls so we likely may not have any but if you can let me know how, I can take a look.

Please go to System>Settings>Advanced configuration, and you will see a tab for them on there. 

Check that, also check with all 3rd party items disabled. And check you are using a standard htaccess

Aside from what's already in there, there are no custom furls nor have any been edited.

I disabled all 3rd party plugins and apps, there was no change.

Our htaccess file:

<IfModule mod_rewrite.c>
Options -MultiViews
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !^/[0-9]+\..+\.cpaneldcv$
RewriteCond %{REQUEST_URI} !^/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteCond %{REQUEST_URI} !^/\.well-known/cpanel-dcv/[0-9a-zA-Z_-]+$
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/(?:\ Ballot169)?
RewriteRule \.(jpeg|jpg|gif|png)$ /public/404.php [NC,L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/[0-9]+\..+\.cpaneldcv$
RewriteCond %{REQUEST_URI} !^/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteCond %{REQUEST_URI} !^/\.well-known/cpanel-dcv/[0-9a-zA-Z_-]+$
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/(?:\ Ballot169)?
RewriteRule . /index.php [L]
</IfModule>

Please rename that htaccess, and instead add a standard one from your admin CP. This can be found in System->Search Engine Optimization

Done, still no change I'm afraid.

Are you utilizing mod_security or anything else on the server which may be rejecting this?

Either way, you will want to obtain the 500 Internal Server Error log entry for this issue. A 500 Internal Server Error is very much like a check engine light on your car. It says something is wrong but not exactly what or where. To help narrow this down we would require that log entry.

Nope, not using mod_security.

The first time this problem was reported by a user was March 31st of this year. Just before that, on the 25th, we upgraded IPB to 4.6.11. There was one particular problem we faced after the upgrade. We had changed our Data Storage Method to Redis as was recommended but on the 31st, there was an alert that the Data Storage and Caching was not working properly. I contacted our hosting support that day and they resolved the issue by changing the port and server and allowed the port in the server firewall.

Not sure if any of that could be related but the dates match up. Prior to that upgrade, we hadn't installed any other service or made any changes.

I've attached the error log.

log.txt

I would say disable redis first of all in that case. Given the dates seem to match, it would be a sensible place to start

I tried changing to both MySQL Database and File System, unfortunately it made no difference. 🙁

You have a lot of instances there where the server is denying access to things. I would suggest checking those with your hosting company

Could you elaborate please? I checked the System Log and saw all those connection refused messages for elasticsearch. I spoke to host support and turned out elasticsearch was down due to incorrect swappiness configuration. That's been resolved now, but it hasn't had any effect on our problem. Is there something else we're missing?

1 hour ago, sadface201 said:

Could you elaborate please? I checked the System Log and saw all those connection refused messages for elasticsearch. I spoke to host support and turned out elasticsearch was down due to incorrect swappiness configuration. That's been resolved now, but it hasn't had any effect on our problem. Is there something else we're missing?

My colleague is referring to the error log which you've provided us.

D'oh. Thank you Jim.

I spoke with our host support about it and they discovered our php memory limit was way too low. After increasing it, it resolved the problem.

Thank you for your help @Marc Stridgen!

Thanks for clarifying this with us, @sadface201. I'm happy it has all been sorted out!

Please don't hesitate to get back in touch with us should you encounter any other issues.