• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Question wordpressPermalinkHandlingFeature

pleskuser67553

Basic Pleskian
Server operating system version
CentOS Linux 7.9
Plesk version and microupdate number
18.0.54
Please could someone elaborate on the importance of this rule, and/or the context in which it is important, in /etc/nginx/plesk.conf.d/vhosts/example.com.conf. I've Googled and searched this forum to no avail.

NGINX:
    # WordPress permalink
    # To remove this rule, add "wordpressPermalinkHandlingFeature = false" in the [ext-wp-toolkit] section of panel.ini
    # then reconfigure the current domain
    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;

I'm trying to add some nginx directives via the Plesk UI additional directives screen, but they get included in the conf below this rule, so I assume this rule is taking precendence over most of the rules I try to add for example, 404 handling, redirections etc. I've set wordpressPermalinkHandlingFeature to false in panel.ini as described and it does not appear to have any adverse effect on my WordPress site with WP Toolkit enabled, permalinks appear to continue to work okay...

WordPress site is on PHP-FPM served by Apache, with nginx proxy mode enabled.
 
[...] I'm trying to add some nginx directives via the Plesk UI additional directives screen [...]

WordPress site is on PHP-FPM served by Apache, with nginx proxy mode enabled.

I am not 100% sure, but I don't think additional nginx directives do much if you're using nginx in proxy mode. I am not mistaken the proxy request is send to apache before any of the other directives take effect. But I might be wrong.
 
The nginx directives fire before Apache in my tests on a non-Wordpress site with PHP-FPM served by Apache and nginx proxy mode enabled.
 
If you have Apache for request processing, this rule has no sense because WordPress creates .htaccess file for such URLs and they can be processed by Apache.
If you don't have Apache and enable permalinks in WordPress, none can process these links and all requests lead to 404 error.

If you want to disable this rule in Nginx you need to add that config option and launch domains reconfiguration to recreate nginx configs.
 
To expand a little on my original post. After I disabled wordpressPermalinkHandlingFeature in panel.ini and reloaded nginx, the directive is gone and thereafter my nginx directives I added via the Plesk UI additional directives screen are now functional, triggered before Apache sees the request, according to the logs and what my browser displays (e.g. '404 nginx' - which is what I intended for certain requests).

Basically, I'm trying to reduce the junk requests that get processed by Apache, PHP and DB.

A bit more context. I have a cloned version of the WordPress site in question. Again, PHP-FPM served by Apache and nginx proxy mode enabled (also Smart static files processing in both cases). The cloned WP site is not connected to WP Toolkit and so this and any other wp-toolkit directives do not exist in its /etc/nginx/plesk.conf.d/vhosts/staging.example.com.conf. Both sites appear to behave the same way on a number of test requests. So yes, I take your point @Evgeny about WordPress's .htaccess taking care of such URLs.

It would be good to get a response from the Plesk devs since they hid this directive in the WP Toolkit nginx template without any documentation.

My guess is, this directive is for sites served by nginx only. If that is the case, would be nice if it was a switch on the WP Toolkit UI, or more intelligently WP Toolkit looked at the server config before deciding whether to add this directive. Not ideal that wordpressPermalinkHandlingFeature in panel.ini has a global effect.

I found a slightly related post which talks about the same directive to give some clues, but the other user's setup is different Resolved - Nginx + non "plain" Wordpress Permalinks error.

Also I believe that sef_ means Search Engine Friendly, which ties in with the Permalinks aspect of this directive.
 
Please could someone elaborate on the importance of this rule, and/or the context in which it is important, in /etc/nginx/plesk.conf.d/vhosts/example.com.conf. I've Googled and searched this forum to no avail.

NGINX:
    # WordPress permalink
    # To remove this rule, add "wordpressPermalinkHandlingFeature = false" in the [ext-wp-toolkit] section of panel.ini
    # then reconfigure the current domain
    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;

I'm trying to add some nginx directives via the Plesk UI additional directives screen, but they get included in the conf below this rule, so I assume this rule is taking precendence over most of the rules I try to add for example, 404 handling, redirections etc. I've set wordpressPermalinkHandlingFeature to false in panel.ini as described and it does not appear to have any adverse effect on my WordPress site with WP Toolkit enabled, permalinks appear to continue to work okay...

WordPress site is on PHP-FPM served by Apache, with nginx proxy mode enabled.
I have same Question
 
Back
Top