Resolved Nginx + non "plain" Wordpress Permalinks error.

[Hockeychap]

I have an issue - none of my sites with permalinks set to "postname" now work.

Details for the problem report are:

Nginx-only php location does not work for WordPress permalinks when set to anything other than plain.

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Plesk WebAdmin, 18.0.45 Update #2, Ubuntu 18.04.6 LTS, Nginx, PHP-FPM 8.1.8, WordPress 6.0.1

PROBLEM DESCRIPTION

Any wordpress installation (existing or newly created) that has permalinks set to "Post name" or a customer stucture with "/%postname%/" displays a 404 error when accessing any of the posts. The initial home page is always available. If the permalink is set back to "plain" then the site correctly shows the home page and the individual posts. There are no added directives for any of the components (nginx/ apache or php). This appears to have happened in either most recent or previous updates.


STEPS TO REPRODUCE

1) For the domain apache and nginx settings: all Apache settings set to "default". Smart file processing is ticked. No additional nginx directives specified
2) for the domain php settings: VErsion 8.1.8 is selected running as "FPM Application served by nginx". No additional directives specified.
3) For the wordpress settings : Hotlink protection is enabled, search engine indexing is disabled. All plugins / themes are upto date. Security status settings have benen loosened. Only options ticked enabled : Restrict Access to files, Configure SEcurity Keys, Block Directory Browsing, Block unauth access to wp-config, Disable php execution in cache, change default table predix, block access to sensitive files, change admin username.

Redirect from http to https is enabled.

ACTUAL RESULT

Articles and posts are not reachable if anything other than "plain" is selected for permalink. A 404 error is displayed.

EXPECTED RESULT

Articles/posts are displayed when permalink type other than "Plain" is selected.

ANY ADDITIONAL INFORMATION

I have tested this now against an existsing plesk managed site and one created this morning from clean on a new domain. I have then also run a wordpress installation using manual config on another UBuntu server, with the same php / wordpress versions. As the manual installation works, I believe it is a bug somewhere in the plesk installation.


YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

A temporary fix to get me through the problem and a fix for the next plesk release.


Quote Reply
Report

 

[Maarten]

WordPress needs to know how to handle subpages. When you use Apache, the .htaccess file takes care of this routing. When you switch to Nginx, the .htaccess file will no longer work, as Nginx doesn't process the .htaccess file. You need to tell Nginx how it must route the subpages. It's explained in this article:

After switching a website to FPM served by nginx in Plesk, it fails to load with "404 Not Found" on all pages except start page

Applicable to: Plesk for Linux Symptoms After setting PHP for a domain as FPM application served by nginx in Plesk at Domains > example.com > PHP Settings, only start page is loading in a...

support.plesk.com

 

[Hockeychap]

WordPress needs to know how to handle subpages. When you use Apache, the .htaccess file takes care of this routing. When you switch to Nginx, the .htaccess file will no longer work, as Nginx doesn't process the .htaccess file. You need to tell Nginx how it must route the subpages. It's explained in this article:

After switching a website to FPM served by nginx in Plesk, it fails to load with "404 Not Found" on all pages except start page

Applicable to: Plesk for Linux Symptoms After setting PHP for a domain as FPM application served by nginx in Plesk at Domains > example.com > PHP Settings, only start page is loading in a...

support.plesk.com

Thanks for the link - I've added in the specific fix and that's worked.

However , as I haven't changed the setup (i.e. have been using plesk with my nginx settings and a pagename for about 7 or 8 years) this is either a regression or a new error, hence the reason raised the bug.

 

[Hockeychap]

As an addendum - I also host a number of customer websites that have also stopped working - all previously using nginx and all previously working fine. I'll now have to go through each domain and add this in (bit of a pain but hey, at least I have happy customers )

 

[Alejandro Oro Vojacek]

I've duplicated this information from another post because I am sure more than one people will realize they had this dreaded option turned on by default without knowing it.

It should be working out of the box as long as you DO NOT HAVE THE CUSTOM ERROR DOCUMENTS enabled.

I've literally burn my head off trying to make it work until I found out that the "checkbox" for Custom Error Documents was enabled by default.

Be sure to disable Custom Error Documents from your website configuration (Hosting -> Custom Error Documents) (or subscription plans and sync).

They stated this on the update but they somehow neglect to mention the importance of this. If you have Custom Error Documents box enabled nothing will work (permalink wise) and you'll be forced to use custom rules.

They should seriously disable Custom Error Documents option automatically when NGINX ONLY configuration is present. So lame that they leave it like that for anyone to smash their brains trying to make nginx only works out of the box.

Advice to Plesk: State a warning on Custom Error Documents or have that option greyed out when NGINX is the only web server. Why would you want an option there enabled that basically breaks the webserver ?

 

[Alejandro Oro Vojacek]

As an addendum - I also host a number of customer websites that have also stopped working - all previously using nginx and all previously working fine. I'll now have to go through each domain and add this in (bit of a pain but hey, at least I have happy customers )

No, you do not need to add that. Just go site by site and be sure to disable (uncheck) Custom Error Documents and everything will start working again.

 

[Alejandro Oro Vojacek]

WordPress needs to know how to handle subpages. When you use Apache, the .htaccess file takes care of this routing. When you switch to Nginx, the .htaccess file will no longer work, as Nginx doesn't process the .htaccess file. You need to tell Nginx how it must route the subpages. It's explained in this article:

After switching a website to FPM served by nginx in Plesk, it fails to load with "404 Not Found" on all pages except start page

Applicable to: Plesk for Linux Symptoms After setting PHP for a domain as FPM application served by nginx in Plesk at Domains > example.com > PHP Settings, only start page is loading in a...

support.plesk.com

That article is TRULY LAME and poorly written. They only state that "This issue has been addressed in Plesk Obsidian 18.0.34 where new WordPress installations work with PHP-FPM served by nginx".

But they do not state the obvious. Which is:

For the new PHP-FPM served by nginx configuration with permalinks to work properly, you MUST BE SURE TO DISABLE Custom Error Pages. Otherwise the whole thing will just break.

Who is filling this reports?. They need to improve their skills at communicating with people. The option was enabled by default on my server, meaning that if they ever implemented this on a server where people does not realize the option was enabled, it will never work. I've searched the entire forum trying to find an answer until I've read the official updates where a small note is made that it will break with that option enabled.

 

[Achim Drees]

I've duplicated this information from another post because I am sure more than one people will realize they had this dreaded option turned on by default without knowing it.

It should be working out of the box as long as you DO NOT HAVE THE CUSTOM ERROR DOCUMENTS enabled.

I've literally burn my head off trying to make it work until I found out that the "checkbox" for Custom Error Documents was enabled by default.

Be sure to disable Custom Error Documents from your website configuration (Hosting -> Custom Error Documents) (or subscription plans and sync).

They stated this on the update but they somehow neglect to mention the importance of this. If you have Custom Error Documents box enabled nothing will work (permalink wise) and you'll be forced to use custom rules.

They should seriously disable Custom Error Documents option automatically when NGINX ONLY configuration is present. So lame that they leave it like that for anyone to smash their brains trying to make nginx only works out of the box.

Advice to Plesk: State a warning on Custom Error Documents or have that option greyed out when NGINX is the only web server. Why would you want an option there enabled that basically breaks the webserver ?

Unbelievable, but it works again now after disabling. You are great!

 

[Alejandro Oro Vojacek]

Yes. It's freaking unbelievable. We are actually paying for a license of a software that should be friendly with us. This information must be stated not only within Plesk control panel but also on their official documentation.

For starters, any person searching for this on their Issues here:

After switching a website to FPM served by nginx in Plesk, it fails to load with "404 Not Found" on all pages except start page

Applicable to: Plesk for Linux Symptoms After setting PHP for a domain as FPM application served by nginx in Plesk at Domains > example.com > PHP Settings, only start page is loading in a...

support.plesk.com

Should read that information prior to doing anything else. But they neglect to put it there and are causing massive problems. Now people is going to start adding custom code to their nginx configuration thinking this is not working, just because nobody thought it would be a good idea to put this out in the open.

At least they should immediately add a text in the "Custom Error Documents" stating to disable the option with NGINX Only configuration. It should help a lot of people. Maybe a warning on the dashboard will probably help too.

 

[gerson58]

WordPress has to know how to deal with subpages. When you use Apache, the .htaccess record deals with this steering. When you change to Nginx, the .htaccess record will never again work, as Nginx doesn't process the .htaccess document. You want to let Nginx know how it should course the subpages.

 

[Maarten]

WordPress has to know how to deal with subpages. When you use Apache, the .htaccess record deals with this steering. When you change to Nginx, the .htaccess record will never again work, as Nginx doesn't process the .htaccess document. You want to let Nginx know how it should course the subpages.

The WordPress Toolkit seems to generate an Nginx configuration file containing those directives. You don't have to add extra Nginx rules anymore.

 

[Hockeychap]

Just thought I'd post to say a big thanks to Alejandro Oro Vojacek. The solution of turning off the custom error pages worked, and maartenv, you are quite right, the Wordpress toolkit adds in:

set $sef_entry_point /;
if ($uri ~* "^/") {
set $sef_entry_point "/index.php?$args";
}
location @wpt_permalinks_fallback {
try_files $uri $sef_entry_point;
}
error_page 404 = @wpt_permalinks_fallback;
error_page 405 = @wpt_permalinks_fallback;

The overwriting of the "error_page 404" line with the custom error handler is what causes the problem.

Thanks again all, much appreciated.

 

[Maarten]

It works great; I wish I had known this before. I must have overlooked the changelog, I guess.

However, I get errors in proxy_error_log when I use just Nginx for WP sites. I'm not sure why it still wants to use an index.html file:

2022/08/10 11:01:52 [error] 4984#0: *1008771 "/var/www/vhosts/domain.com/httpdocs/subpage/index.html" is not found (2: No such file or directory), client:... , server: domain.com, request: "GET /slug/ HTTP/2.0", host: "domain.com", referrer: "https://domain.com/subpage/"

 

[Hockeychap]

Would now like to mark this as resolved - can;t find how to do that . Any suggestions?

 

[Maarten]

Would now like to mark this as resolved - can;t find how to do that . Any suggestions?

Only users with that permission can mark it as resolved. Just did it for this thread.

 

[Alejandro Oro Vojacek]

This is not resolved. The option for Custom Error Documents is enabling by itself every time a plan is unsynced and it is re-enabling custom error documents. We need a permanent solution to this.

 

[Alejandro Oro Vojacek]

This is a note from our Engineer at our company on how we fixed this issue.

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.Note, in implementing the above I copied the default Plesk virtual host configuration template into a custom directory as an override. I assumed this would be okay under our Plesk license, but I am not sure if there are any licensing requirements or issues associated with copying, re-using, and modifying their default templates, etc.

 

[Alejandro Oro Vojacek]

If we could do it, I'm sure Plesk could a little more than just putting this as a Bug and not doing anything for well over a month now.

 

[Nygård]

THANK YOU

If we could do it, I'm sure Plesk could a little more than just putting this as a Bug and not doing anything for well over a month now.

I've duplicated this information from another post because I am sure more than one people will realize they had this dreaded option turned on by default without knowing it.

It should be working out of the box as long as you DO NOT HAVE THE CUSTOM ERROR DOCUMENTS enabled.

I've literally burn my head off trying to make it work until I found out that the "checkbox" for Custom Error Documents was enabled by default.

Be sure to disable Custom Error Documents from your website configuration (Hosting -> Custom Error Documents) (or subscription plans and sync).

They stated this on the update but they somehow neglect to mention the importance of this. If you have Custom Error Documents box enabled nothing will work (permalink wise) and you'll be forced to use custom rules.

They should seriously disable Custom Error Documents option automatically when NGINX ONLY configuration is present. So lame that they leave it like that for anyone to smash their brains trying to make nginx only works out of the box.

Advice to Plesk: State a warning on Custom Error Documents or have that option greyed out when NGINX is the only web server. Why would you want an option there enabled that basically breaks the webserver ?

THANK YOU!
Sorry for shouting in my first post. But something so simple should, as you say, really be implemented somehow with a huge arrow to deselect when really needed, or auto-deselected upon activating nginx-only server with wordpress installed. Would have saved me hours of "work".

Again... Thank you!

 

[Alejandro Oro Vojacek]

You can check my post were I uploaded the fix. It was tested 100% and will just skip custom error documents altogether so even if it auto enable itself it won't break your sites.

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

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...

talk.plesk.com