WordPress Installation Error 500 | Howtoforge


I ran into the same error, here is a possible solution (also copied from multiple blog posts etc. together).
Installed: ISPconfig 3.2.4 according to the “Perfect Server Automated” instructions under Ubuntu 20.04.2 LTS on a VM at Netcup, Nginx should be used as web server, PHP versions 7.4 and 8.0.
So far everything has been fine, moving static websites, mail etc. worked wonderfully, only WordPress didn’t want to work at all, ie those 500 pages were also displayed that ISPconfig had created in the “error” directory by default.
It was a matter of moving a WordPress site, database was created, data imported, I had adjusted the parameters in wp-config.php accordingly (I thought, more on that in a moment :) ).
The whole thing was installed as a vhost subdomain, but these 500 pages were now displayed.

My first guess was in the direction of the WordPress cache plugin, so I deleted them all from the wp-plugin directory using the command line. Still error 500.

Problem #1: Where are the (PHP error) logs?

I’m still looking for it somehow. I would have expected them in the vhost’s logs directory, so /var/www/subdomain.example.com/log/subdomain/error.log, just like the access.log. They are also there, but there are no PHP error outputs to be found, or even when the 500 error is displayed, nothing is recorded there. The 500 is dutifully recorded in the access.log, but since the HTML page error/500.html is called up immediately, does Nginx not generate any further log output?
Strangely enough, an error message from PHP only appeared once in the error.log, all other requests did not appear here.

However, I didn’t want to fiddle around with the php.ini files, after all I want to use ISPconfig to save me from manually creating them.
In the wp-config.php I initially set WP_DEBUG to true, but this also did not lead to the error being displayed.

Solution: Deactivate the “Own error pages” setting in the ISPconfig website configuration, i.e. deselect the checkbox and save.

After that, WordPress (thanks to WP_DEBUG) at least displayed the error.

It was a simple typo in the database name in wp-config.php, so easy to fix.

(Set WP_DEBUG back to false afterwards!)

The admin UI of WordPress was thus already accessible.

However, visiting an article led to:

Problem #2: Page not found

WordPress was configured to display “nice” URLs, i.e. /2021/04/bla-blubb-artikel , ie via the appropriate setting in the “Permalinks” section.
An Apache web server was previously in operation, the setting was made using a .htaccess file. Of course it couldn’t be done with Nginx, so directives had to be changed, but see above, with little or no manual intervention to avoid breaking the ISPconfig concept.

Ultimately I did the following:

As an admin in ISPconfig under “System -> Directive snippets” created a snippet. Name: WordPress configuration, type nginx, “visible to customers” -> yes (checked), active yes, Updates sites using this snippet yes.
Content (shamelessly copied from https://ww1.4hf.de/2014/06/ispconfig-nginx-webserver-wordpress-startschwierigung.html ):


location / {
try_files $uri $uri/ /index.php?$args;

# Add trailing slash to */wp-admin requests.
rewrite /wp-admin$ $scheme://$host$uri/ permanent;

location ~*  .(jpg|jpeg|png|gif|css|js|ico)$ {
expires max;
log_not_found off;

Advantage of this code compared to other hints: It’s quite small and it doesn’t change the actual PHP directive. PHP-FPM runs here using a socket, while other posts refer to an IP address and then only a special port, or to a single socket, which is then only valid for one website.
The snippet should also be universally usable for all websites set up via ISPconfig (this would probably also be possible via variable, but ultimately not necessary in this case).

The customer must then be enabled to use the snippet, set as admin for this: Select customer -> “Limits” tab -> “Web server configuration selection visible”: yes (checked).

Logged in as a customer, I then have the option under Websites -> Selection of the respective site -> “Web server configuration” to select the previously configured directive snippet using the select box (but as a customer only select, not change).

That’s how it worked for me, and so you could also offer the opportunity to an actual customer if you’re not all in personal union yourself.

Best regards,

hp I’ve only been using ISPconfig for a few days, so far I really like it, at least everything has been solved so far. 😀