Forwarded to devs NGINX only not working when Custom Error Documents is enabled on a WordPress installation

[Alejandro Oro Vojacek]

Username:

TITLE

NGINX only not working when Custom Error Documents is enabled on a WordPress installation

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Version 18.0.45 Update #2
CentOS Linux 7.9.2009 (Core)

PROBLEM DESCRIPTION

When the option Custom Error Documents is enabled, permalinks rewrites won't work natively on NGINX and sites running WordPress are going to throw error 404

Since this option is ENABLED by default, it is creating all kind of issues to people that use their servers only with NGINX.

2 possible fixes to this issue:

1. Make this option DISABLED by default, which will limit exposure, every new site created is having that option ON and it's a nightmare.
2. Have a toogle somewhere to DISABLE Custom Error Documents server-wide so we can get rid of this issue for good.

An immediate fix for this is needed as we are getting calls from our customers in the middle of the night because their sites start showing 404 errors.
The option seems to be re-enabling all by itself.

STEPS TO REPRODUCE

Go into Apache & NGINX settings -> disable NGINX Proxy.

This will put the server into the nginx-only operation.

Wordpress site under that account will display 404 errors on every page except the homepage.

Go into Hosting Settings -> Untick Custom Error Documents

NGINX will start working properly as the WP Toolkit rewrites will take over.

ACTUAL RESULT

All websites that are switch to nginx native (proxy mode off) will have 404 errors on all pages.

EXPECTED RESULT

As soon as any site PROXY MODE is set to disabled (nginx only), the default behavior should be to make Custom Error Documents disabled to guarantee that nginx rewrites will work.

ANY ADDITIONAL INFORMATION

Make a global option to disable Custom Error Documents server-wide.

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Help with sorting out

 

[SteveM]

Looks like you can can disable 'Custom Error Documents' by default by changing service plan in
Service Plans > plan_name > Hosting Settings > disable 'Custom error documents'.

Also, note that server wide 'custom error pages' configuration not implemented yet

 

[Alejandro Oro Vojacek]

I would not be posting this if I didn't tried that before.
No, disabling CUSTOM ERROR DOCUMENTS on the Service Plan does not fix the issue.
If the customer creates a new site or I have to "tweak" the Service plan and unhooks from the service plan, that option will turn on again by itself, since you guys had it as ENABLED by default, which will contradict normal operation on nginx only webservers.

You need to make a global custom error pages toogle or make that option OFF by default or you'll get bombarded with tons of support request like mine, complaining of 404 errors.

 

[Alejandro Oro Vojacek]

Also confirming that "disabling" that option on Service Plans does not disable it on any of my customers. If someone has that option on, even when I'm synching the service plan, the Custom Error Documents remain ON until I manually disable it.

 

[Alejandro Oro Vojacek]

Our Engineer at our company found a fix for this issue. I will past the information here for your devs.

The problem is that WordPress Toolkit is using error_page directives in the config file to handle the permalinks - if the site visitor requests a non-existent file and nginx generates a 404 error or similar, with WordPress Toolkit enabled it passes that 404 request to WordPress for handling. WordPress then either resolves the permalink or returns the WordPress 404 page, instead of nginx returning the default web server 404 page. However, the custom 404 error pages setting also uses error_page directives to implement custom error pages.

Currently in Plesk config, these error_page directives come before the WordPress ones, so they override them - when nginx encounters a 404 error, it reaches the first error_page directive and returns the custom error page specified there. It never reaches the error_page directive set by WordPress Toolkit. Note that the above also currently applies to 405 errors. All other errors (e.g. 500, etc.) do not currently appear to be forwarded to WordPress.The solution is to rearrange the config file so that the WordPress Toolkit configuration (if enabled for the site) appears first in the config file, before the custom error docs configuration.

That way, if there is a 404 or 405 error, it is passed to WordPress for processing, and those custom error pages (set by Plesk) will never be used. Other error codes would still be handled by Plesk custom error pages.In the virtual host configuration template, I moved the block that handles the error docs configuration (nginxErrordocs.php template include, including the surrounding if statement) to below the block that inserts extension configs (including WordPress Toolkit - look for the single line that references nginxExtensionsConfigs).

I would not recommend doing it the other way around since some extension configs may be sensitive to config file order.

 

[Alejandro Oro Vojacek]

The fix is here. Just add this file into:

/usr/local/psa/admin/conf/templates/custom/domain/nginxDomainVirtualHost.php

Then do:

plesk repair web

And Custom Error Pages will no longer present a problem to NGINX native servers as the option is going to be ignored.

 

[Bitpalast]

Is this the official Plesk fix??? Elsewise applying it could break future updates or hinder migration.

 

[Alejandro Oro Vojacek]

No. It is not official. It is what our Engineer did to fix the issue on our servers. This should NOT break any update or the server itself or any migration. What the file does is just change the order in which the rules are loaded, giving priority to the "404" rules for the WP Toolkit instead of Plesk 404 custom rules.

This will fix the issue with the option enabling it at random as it will simply ignore the Custom Error documents option altogether. Since no other thing has been changed on the file, it should not affect any other system.

This is loaded as a custom template and should still be active even after upgrades.

We also tested this against NGINX as proxy and with Apache and no issues are present as those options will simply not load this template. This is 100% safe to use. If you want to revert this, simply remove this file from the server and do plesk repair web. That's all there is to it.

Since Plesk is not providing any updates on this nor are they issuing any statement, we were forced to fix it ourselves.

 

[TheBuschKopf]

here is the official plesk fix when the wordpress permalinks (subpages) return into error 404 pages, worked like a charm for me after researching for hours:

https://support.plesk.com/hc/en-us/articles/12377889048855