Issue rewrite Wordpress issues - 403

[Coopsy]

Hi - im having a right nightmare all day and cant for the life of me know what this issue is.

I have several wordpress domains which have another wordpress directry
so for example.
www.website.co.uk - this has wordpress on it
www.website.co.uk/wordpress - this has another wordpress install after the / to show another website etc. Ive had this for years - no problem until today!

The issue now is the new wordpress home page loads (/wordpress) but clicking on any link (/wordpress/link) takes me to a 404 page for the first install (website.co.uk) - yet the pages exist. the .htaccess file is fine yet if i change the permalinks to PLAIN (on the new wordpress) - the pages load fine, switching it back to POST TYPE i get the 404. Really need some help on this is possible.

Plesk Obsidian
Version 18.0.40.1
PHP 7.4.26 FPM Application served by Apache

 

[Bitpalast]

This can probably be solved with the help of this article or articles linked in it:

Site shows 404 not found on Plesk server: nginx error: index.html is not found (2: No such file or directory)

Applicable to: Plesk for Linux Symptoms Domain is inaccessible with 404 error.Rewrite rules specified in /var/www/vhosts/example.com/httpdocs/.htaccess file do not work. FPM application served...

support.plesk.com

 

[Coopsy]

This can probably be solved with the help of this article or articles linked in it:

Site shows 404 not found on Plesk server: nginx error: index.html is not found (2: No such file or directory)

Applicable to: Plesk for Linux Symptoms Domain is inaccessible with 404 error.Rewrite rules specified in /var/www/vhosts/example.com/httpdocs/.htaccess file do not work. FPM application served...

support.plesk.com

Thanks Peter however i dont think this is right for me. The .htaccess file IS being used. If i change the wordpress Permalinks to PLAIN - the pages load fine, if then switched to POST TYPE - this is when i get the 404 error and the .htaccess fils is updated.
My server is FPM application served by Apache and not FPM application served by nginx

 

[Bitpalast]

In that case I can only recommend to query Google with "wordpress posttype 404". There are plenty of articles that discuss the issue. If it is not webserver related, it can only be caused by a setting in Wordpress.

 

[Coopsy]

Plesk have advised this is a bug with the WPTOOLKIT. Here’s what they say for anyone that has the same issue….:

Our development team has investigated the issue and confirmed that it was caused by a product defect. A bug has been created: EXTWPTOOLK-8578: "WordPress installed to sub-directory doesn't work as expected after enabling "Block author scans" and "Enable bot protection" measurements". Thank you for bringing this to our attention!

We will do our best to fix the issue in one of the next Plesk updates. You may track our release notes to see when the issue will be fixed:

Change Log for Plesk Obsidian

Find out about changes, additions and updates to Plesk Obsidian on an iteration to iteration basis.

docs.plesk.com

Until a fix becomes available, we suggest using one of the following workarounds:

Workaround 1:

Disable by reverting the Security Measures "Block author scans" and "Enable bot protection" on the main WordPress instance, the one installed on /httpdocs, and all other Wordpress instances installed to subdirectories e.g.: /httpdocs/some_directory, as is described below:

1. Log in to Plesk
2. Go to Domains > example.com > WordPress > select a WordPress instance in question > Security Status.
3. Select "Block author scans" and "Enable bot protection", if both are found applied ( with the green check-mark ), otherwise select the one of these found and click Revert.

Workaround 2:

This will be the one you already found, which is to use "Plain" permalink in the WordPress instances.

 

[MARS_NETWORKS]

Plesk have advised this is a bug with the WPTOOLKIT. Here’s what they say for anyone that has the same issue….:

Our development team has investigated the issue and confirmed that it was caused by a product defect. A bug has been created: EXTWPTOOLK-8578: "WordPress installed to sub-directory doesn't work as expected after enabling "Block author scans" and "Enable bot protection" measurements". Thank you for bringing this to our attention!

We will do our best to fix the issue in one of the next Plesk updates. You may track our release notes to see when the issue will be fixed:

Change Log for Plesk Obsidian

Find out about changes, additions and updates to Plesk Obsidian on an iteration to iteration basis.

docs.plesk.com

Until a fix becomes available, we suggest using one of the following workarounds:

Workaround 1:

Disable by reverting the Security Measures "Block author scans" and "Enable bot protection" on the main WordPress instance, the one installed on /httpdocs, and all other Wordpress instances installed to subdirectories e.g.: /httpdocs/some_directory, as is described below:

1. Log in to Plesk
2. Go to Domains > example.com > WordPress > select a WordPress instance in question > Security Status.
3. Select "Block author scans" and "Enable bot protection", if both are found applied ( with the green check-mark ), otherwise select the one of these found and click Revert.

Workaround 2:

This will be the one you already found, which is to use "Plain" permalink in the WordPress instances.

For my part:
- in WP toolkit unset "Block author scans" and "Enable bot protection"
- deactivate wordpress toolkit
- unset "Smart static files processing" in "Apache & nginx settings"
- set "Smart static files processing" in "Apache & nginx settings"
- reactivate wordpress toolkit

You can reactivate "Block author scans" and "Enable bot protection" but then it will crash again :-(
Just repeat the same operations