Add global path for logs

[SorinGFS]

Feature request

Feature description

Allow user to customize the global path for logs:

[MattIPv4]

Please can you specify details on how you expect this to interact with the user-customisable per-domain log paths we now have?

How would this work in a way which isn't confusing UX for the user? If they edit the per-domain path, and then edit this new setting, what happens? If they leave the per-domain path as the default, and then edit this new setting, what happens in the per-domain UI? etc.

[SorinGFS]

If they edit the per-domain path, and then edit this new setting, what happens? If they leave the per-domain path as the default, and then edit this new setting, what happens in the per-domain UI? etc.

This new global variable should be used to construct the default path (the one that appears in logging tab): ${nginx_logs_base_path} + access.log and ${nginx_logs_base_path} + error.log. This is usefull because user doesn't need to cusomize every domain in case he uses another base path then default. If the user chooses to further customize the path per domain this would be his starting value,

If we have this new modification in place, then we would be able to inject ${server_name} variable into the path without problem. Let's not talk about this for the moment, I think the feature I propose is useful on its own.

[MattIPv4]

If the user chooses to further customize the path per domain this would be his starting value,

Right, but once the user has further customized the path, what is the expected UX of this global setting? Does it become disabled permanently because there is a custom path being used? Or does it remain active? And if it does remain active, what happens if it is changed again, does it reset the customised value?

[SorinGFS]

Does it become disabled permanently because there is a custom path being used? Or does it remain active? And if it does remain active, what happens if it is changed again, does it reset the customised value?

It should remain active for the rest of the non cusomized domains. If you concern what happens if user cusomizes the per domain value then goes back and cusomizes the global value... the solution can be a check if the customized path is still equal with global value. In this case changing the global value should not affect the customized value.

[MattIPv4]

I am still of the belief that this will be very confusing UX for the user, with two settings in two very different parts of the app that influence each other and the output config.

As such, I don't think this is something that should be worked on for now, but will leave this issue open so others in the community can express their support if they feel this change would be useful and outweigh the potential confusion caused by the UX.

[SorinGFS]

I am still of the belief that this will be very confusing UX for the user, with two settings in two very different parts of the app that influence each other and the output config.

As an nginx user I use to think in blocks. There is main block with some vars, http block with some vars, so are server, location of if blocks. Nginx documentation tells us in which block can be used a specific directive or variable, and this is a common thing that the same setting has a value on lets say http block, and another value on the server block which wins. For example error_log can be ovverwritten in main, http, mail, stream, server, location contexts. See docs.

So IMHO it shouldn't be confusing at all.

I leave the issue open as you wish, let's see what others think about that.

[SorinGFS]

@MattIPv4

How about having the path in the logging tab with the first part (base path) taken from nginx global path and greyed out, and allowing the user to customize only the rest of the path? I think no one uses different base paths for different domains...