Hello, I'm using Plesk Onyx and I've also bumped into problems with not being able to set correct NGINX Directives.

Regarding nginx and nginx configuration for various CMS, Web Apps etc, I see that a lot of directives need to be set and there are a lot of scattered issues around in the web.
For example most CMS will require a
location / { ... }
or for google's pagespeed test we need to add expire headers e.g.
location ~* \.*.(jpg|jpeg|png|gif|ico|css|js)$ {
expires 14d;
}

I think the Model to building the final vhost conf file should be revised instead of focusing on specific use cases like "Duplicate Location / {} directives".

If we simplify it, the current model works like that:
The Plesk vhost template for NGINX reads some database values and then appends specific directives using variables regarding the domain.
Afterwards it includes the custom vhost_nginx.conf file at each server {...} directive declaration.

So since some records are already defined, the originals match before our own directives so our directives are ignored or our directives turn out as duplicates.

I can think of 3 different suggestions instead in this case.
1. Add the ability to set a custom base vhost template for each vhost separately
In this case:
- The vhost is created by PLESK using the default template.
- The user would then be able to clone the original template and modify to their needs
- The modified template would be saved either to the db or to a separate file
- If a modified template exists -> the system would use that one instead of the PLESK default one to build the final last_nginx.conf file.

2. Keep only minimal required vhost configuration information in the base template and add the rest to db so that people can then easily override for their custom vhost configuration.
In this case:
- Separate Location / {} directives from the rest, including
location / {
proxy_pass https://{IP}:{PORT};
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
access_log off;
}
etc ...
- The vhost is created by PLESK using the default template which does not include any location directives.
- When the user chooses to use nginx the additional nginx directives field is populated by what would be generated by the template on save with some comment that removing this could result in his site not working.
- Add a reset button to reset to initial configuration if the user messes up.

3. Similar to 2 but use 2 fields to store the information.
- One field is a checkbox to enable or disable plesk's directives with a warning that the site might not load correctly.
- A field to add custom directives so that the user can input his own configuration.
- There should be a box or button to display the recommended configuration for the vhost
- A reset button to the recommended configuration would be nice.

Let me know if you think something like this is achievable or why it can't be done. Thanks in advance for your efforts.

When switching from Apache to FastCGI the Service Provider needs to change the permissions for the customer from apache:apache to <user>:psacln

This can be fixed by having a button in Plesk which does:

find $PLESK_DOMAIN_HTTPDOCS -not -user $PLESK_DOMAIN_OWNER -not -name "plesk-stat" -print0 | xargs -0 chown $PLESK_DOMAIN_OWNER:psacln
find $PLESK_DOMAIN_HTTPDOCS -type d -not -name "plesk-stat" -print0 | xargs -0 chmod 0755
find $PLESK_DOMAIN_HTTPDOCS -type f -not -name "*.pl" -not -name "*.cgi" -not -name "*.sh" -print0 | xargs -0 chmod 0644
find $PLESK_DOMAIN_HTTPDOCS -type f -name "*.cgi" -print0 -o -name "*.pl" -print0 -o -name "*.sh" -print0 | xargs -0 chmod 0755

I have this entirely written in bash already (where I get all needed variables from the DB with domainname as input).

Currently when a user uses SSH to execute PHP cli commands, it does not reflect the settings chosen in Plesk panel (it seems to be the default OS vendor PHP). While other PHP versions are available in "/opt/plesk/php/..." the current solution is neither ideal nor transparent to the user (most of them don't even know this path).

I suggest that the default chrooted PHP command
-) should use the same version as chosen as in plesk panel
-) and should use ini settings (memory_limit, max_execution_time) as chosen in plesk panel

Ideally this should even be possible on domain level, but at least on subscription level.

Sharing a PHP-FPM process with separate pools per websites is a security issue and a problem for performance when some clients may deploy bad scripts to the server.

A huge reason for why sharing the same PHP-FPM process between subscriptions is that the OPCACHE (Xcache, APC and Opcache) share the same memory and it is accessible between clients. Disabling access to stats and controlling api of them is available, but it's not a great solution for some critical cases. Still, this is not suitable when isolation between apps is critical.

Another reason is with php scripts that clients deploy. In some occasions a bad written script can make all Pools dead so all websites become not accessible and 502 error comes continuous (Nginx/Apache gets timeout from the PHP-FPM manager).

Third reason is CGROUPS, to force limitation on CPU and RAM usage, which works great based on services. It's far more easier to implement CGROUPS on separate PHP-FPM managers (check RHEL/CENTOS as they have this implemented in systemd and it's just to apply a custom template to work).

Current implementation of PHP-FPM is great for agencies that just host their clients websites, but it's not great at all for companies that sell hosting.