WordPress installed in subdomain breaks 404 pages of other subdomains

[Sage Pointer]

I'm not sure if this happened in 4.8 or was earlier (but i noticed only now).
If I add a Wordpress via wp-toolkit, any subsequent updates to Nginx settings produce a bad nginx config in every subdomain belonging to the same domain where there is at least one Wordpress instance added in wp-toolkit.
For example, if i add Wordpress to subdomain1.example.com and subdomain2.example.com, it generates following config:

    #extension wp-toolkit begin

    set $sef_entry_point /;
    if ($uri ~* "^/subdomain1\.example\.com/") {
        set $sef_entry_point "/subdomain1.example.com/index.php?$args";
    }
    if ($uri ~* "^/subdomain2\.example\.com/") {
        set $sef_entry_point "/subdomain2.example.com/index.php?$args";
    }
    error_page 404 = $sef_entry_point;

    #extension wp-toolkit end

And places this code to every subdomain belonging to example.com even where is no Wordpress instance installed.
This breaks other sites, of course.
Expected behavior: the plugin should only generate corresponding lines to subdomains where Wordpress is installed, not adding it to every single config.
Temporary solution: disable wp-toolkit and repair subdomain configs with command:

plesk repair web -domains-only

Please add ability to disable this SEF "optimization" as it makes wp-toolkit destructible if there are multiple subdomains.

 

[AntonM@Parallels]

Issue has been fixed in Wordpress Toolkit 4.8.1, please check and install updates:

[FIXED BUG] mod_rewrite stopped working. All pages on WordPress sites show 404

Applicable to: Plesk Obsidian for Linux Symptoms Simple redirect to index.php does not work inside /var/www/vhosts/example.com/httpdocs/folder/.htaccess: CONFIG_TEXT: RewriteEngine On RewriteC...

bit.ly

 

[JuanjoSC]

Hi,

Our development team aware about situation and working to issue an update for this issue. Meanwhile as a workaround you may want to roll back the below security measures under the Wordpress Toolkit > Security:

• hotlink protection
• block authors scan
• bot protection

Thanks for the temporary "solution" but this has caused me to lose 6h of my life today, and I am very angry with the problem.

 

[Sage Pointer]

Meanwhile as a workaround you may want to roll back the below security measures under the Wordpress Toolkit > Security:

• hotlink protection
• block authors scan
• bot protection

To me it doesn't help. The malicious config lines appear even if no security measures are applied, even if i apply them all and rollback again. They don't belong to security settings, appear even when no security settings enabled at all.
The only two options to get rid of them were either to disable wp-toolkit at all or disconnect every site from it and regenerate Plesk configs.

 

[JuanjoSC]

I have completely disabled it.
As we say in Spain "You don't play with eating things"

 

[Sage Pointer]

The minimal actions to reproduce the bug:
1) Create an empty subdirectory under subscription path (for example, /var/www/vhosts/example.com/test ), even if it's not placed under document_root of any existing subdomains or main domain itself (so, inaccessible from the web in any way).
2) Create empty directories named "wp-content" and "wp-includes" in that empty directory.
3) Create empty wp-config.php file in the directory.
4) Rescan for Wordress installations in WP Toolkit. That directory will appearin the list as "broken installation".
5) Regenerate nginx configuration with "# plesk repair web -domains-only" command.
From that point, every config belonging to that subscription will have malicious lines with faulty "error_page 404 = $sef_entry_point;" from wp toolkit. Even if that "wordpress installation" is marked as broken and is found outside of any document_root.
Luckily it doesn't affect the other subscriptions, so if WP Toolkit is very needed for some reason - create the separate subscription and use it only in that subscription only and don't use any other CMS with different entry point in it.

 

[Sage Pointer]

The other solution is to rename or delete the file /opt/psa/admin/plib/modules/wp-toolkit/hooks/WebServer.php, after doing that it stops shitting into nginx configs, but the other related functions of this plugin (like "security", for instance) will stop working too, so you need to block access to the specific files manually.
I hate proprietary software for not being able to fix it, but cutting off destructive functions from it and leaving constructive functions only sometimes works.

 

[JuanjoSC]

Issue has been fixed in Wordpress Toolkit 4.8.1, please check and install updates:

[FIXED BUG] mod_rewrite stopped working. All pages on WordPress sites show 404

Applicable to: Plesk Obsidian for Linux Symptoms Simple redirect to index.php does not work inside /var/www/vhosts/example.com/httpdocs/folder/.htaccess: CONFIG_TEXT: RewriteEngine On RewriteC...

bit.ly

Now it works worse than before.
Now all redirects from ALL websites on the server stop working.

 

[Hangover2]

Same problem here. After using the WordPress Toolkit "Secure" feature the websites are broken.

 

[custer]

Hi everyone,

We've found out that the hotfix released in WPT 4.8.1 hasn't addressed the issue for all cases, so we're preparing a WPT 4.8.2 hotfix that should conclusively address it. We're planning to release WPT 4.8.2 a bit later today, on 2nd of June.

I'm really disappointed and I feel your pain, it really sucks that we weren't able to catch this issue through our internal testing before publishing WPT 4.8. We're going to discuss internally how we can improve our processes to make sure critical bugs like this aren't released to the general public.

I'll make another post here as soon as WPT 4.8.2 is published -- stay tuned.

 

[Sage Pointer]

I'll make another post here as soon as WPT 4.8.2 is published -- stay tuned.

Please add the check - if there are no Wordpress instances within document_root of given subdomain or domain - DO NOT EVER write to its config anything related to wp toolkit. So if some bug in config generation appears - it should affect ONLY subdomains with Wordpress. Writing to unrelated configs is VERY RUDE, it's something that malware do.

 

[Hangover2]

We did make some extra tests today to have an work-around for our clients. We did see an important config change, that leads to problems.
In the past the config generator by the WordPress Toolkit did use for the Apache config the "<Directory [...]>" directive for e.g. the bot detection. With the new update you did switch to the "<DirectoryMatch [...]>" directive. But this leads to a new behavior of the Apache handling concerning mod_rewrite / RewriteRules in .htaccess files making our WordPress instances not reachable anymore over permalinks / rewrites.

 

[custer]

The issue was fully fixed in WPT 4.8.2, which was published a couple of minutes ago. Let us know if you continue to experience any related issues.

 

[Sage Pointer]

The issue was fully fixed in WPT 4.8.2, which was published a couple of minutes ago. Let us know if you continue to experience any related issues.

Looks good, I regenerated all configs and now see wp-related lines only in the configs that actually have wp installed.

 

[Hangover2]

Looks also good for us. Websites are running smoothly again. "DirectoryMatch" was removed as suggested and other subdomains do not appear anymore in the config files / "VirtualHost"-sections of the target subdomains.