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.

Hey guys,

I am sure that I speak for hundreds of users when I say that having a limit on backups per customers and or subscriptions should be an important and available option. The option to also limit backups based on the customers subscription storage size will be even better. Otherwise, customers who overuse the backup option will dramatically increase storage space on the server without realization of the administrator. It wouldn't be ideal for an administrator to enter the dumps folder to delete random customer backups. Really hope you guys can resolve this and add this feature as soon as possible.

Please make possible generating and activating DKIM/DomainKey without having active local DNS server. Consider following situation:

You have a website that use as sender your domain when sending email and you are want to follow best practices in order to reach inbox, but this domain uses another server for DNS (cloudflare for example, godday, etc.). In this case you need to have DKIM/DomainKey signed mails without the need to activate local DNS server. Also mail management could be set off for that domain, but mails still should be able to be signed.

I believe that this scenrario is real and for a lot of people this will be very useful.

Let others correct me or add/edit the request to match best the need.