Feature: Add "Troubleshooting Mode"

[Gykes]

This PR adds a new toggle to Settings -> Interface(Image Below) which allows users to toggle Disable Customization in the new troubleshooting section. I don't have a reason for where I placed it on the page it was just kind of random. If someone has a better idea for where to place it then it's an easy change to make. I felt like adding in the new section was a good idea for future proofing but I can simplify it if needed.

This disables all plugins and custom css, JS, and localization. To keep in line with other settings this will require a manual page reload by the user once enabled.

Tests: Enabled the Stash Notes plugin -> enable and refresh -> plugin gone from nav bar Enabled custom css to change background -> enable and refresh -> background back to normal Enabled custom JS to add a popup alert on reload -> enable and refresh -> popup no longer appears. Enabled custom localization to change "Scenes" to "blah" -> enabled and refresh -> goes back to scenes

Fixes: #4508

UI:

[sleetx]

A few thoughts:

• Is this necessary? or will it end up causing more confusion during troubleshooting? We could simply add a paragraph to the In-App Manual or the Stash Docs for troubleshooting tips like this.

• Assuming we move forward, the "Interface" settings category is probably not the best spot to place it, since it involves both scripting and plugin deactivation. Maybe under Tools, Logs, or Security?

• I'd suggest branding it as "Disable Customizations" rather than "Troubleshooting". And a button rather than a toggle switch. After clicking the button, it could force the page to automatically reload. And then the alternative button appears as "Re-Enable Customizations".

• Are you storing exactly which options affected? It looks like you added a boolean. Stash instances will have various things turned on or off already. For example, users may already have inactive plugins that shouldn't be re-activated. Or they may have CSS enabled but not JS, etc.

[Gykes]

A few thoughts:

* Is this necessary? or will it end up causing more confusion during troubleshooting? We could simply add a paragraph to the In-App Manual or the Stash Docs for troubleshooting tips like this.

* Assuming we move forward, the "Interface" settings category is probably not the best spot to place it, since it involves both scripting and plugin deactivation. Maybe under Tools, Logs, or Security?

* I'd suggest branding it as "Disable Customizations" rather than "Troubleshooting". And a button rather than a toggle switch. After clicking the button, it could force the page to automatically reload. And then the alternative button appears as "Re-Enable Customizations".

* Are you storing exactly which options affected? It looks like you added a boolean. Stash instances will have various things turned on or off already. For example, users may already have inactive plugins that shouldn't be re-activated. Or they may have CSS enabled but not JS, etc.

• No, it was brought up and requested in discord as quite a few users have issues and the first step told to them is to disbale plugins as it seems like a plugin issue rather than a Stash issue. This is a quick and easy way to help users troubleshoot their problems.

• I put it there just due to the fact of it is dealing with interface stuff. Disabling CSS, JS, etc. I'm not married to where it is currently it was just a location that I figured might work, can be moved simply.

• I created it as "Troubleshooting" as the category as we could potentially add new things there in the future but the actual toggle is labled as "Disable Customizations" within that category.

• So the actual toggle itself is a toggle and a bool, yes. How I have it currently is it does not modify your current settings at all. It doesn't toggle individual plugins on or off it either enables or disables the entire block. Imagine it like a breaker box. My implementation is flipping the main breaker to each section. If you have a breaker of it will continue to stay off regardless of if I flip the main breaker.

Edit: I specifically kept it so that it did not reload to page to keep it inline with other custom implementations. When you enable CSS you need to refresh the page to have it take effect. If I have it refresh the page on toggle then if someone is modifying settings, and clicks it by accident, it would refresh and they would lose their other settings. Just a small bad UX experience but if the consensus is to make it reload then i'm fine with that.

[echo6ix]

@Gykes Thanks!

Suggestion:

1. You labeled the toggle Disable customizations. For utmost clarity I suggest renaming it to Disable plugins and customizations. Since it affects both, there’s no reason to omit "plugins" when calling out "customizations". And many people probably won't read the fine print😏
2. Customizations are in the Interface section, and plugins in Plugins section, but this toggle affects both items. Placing it in either section would exclude the other. It might be the most intuitive as a core toggle in the System section, located as the last entry.

[feederbox826]

I think the concept itself is a great idea, I don't have much of an opinion on where it should go or what the naming should be. We've had multiple issues come up where it was so difficult to replicate and ended up being solved by "oh I had custom CSS" or "oh I had x y z theme and plugin conflict".

I would additionally add some sort of overlay to act as a notice, since the user would probably not want to run in this mode for extended periods of time

something akin to the "This copy if windows is not activated" overlay and additionally clickable to quickly turn it off

Troubleshooting Mode
stash v0.29.3 aaaaaa

Debug mode in logs would also be great but persistence would be difficult

[Gykes]

@Gykes Thanks!

Suggestion:

1. You labeled the toggle `Disable customizations`. For utmost clarity I suggest renaming it to `Disable plugins and customizations`. Since it affects both, there’s no reason to omit "plugins" when calling out "customizations". And many people probably won't read the fine print😏

2. Customizations are in the `Interface` section, and plugins in `Plugins` section, but this toggle affects both items. Placing it in either section would exclude the other. It might be the most intuitive as a core toggle in the `System` section, located as the last entry.

1. I kind of consider plugins to be part of customization for the most part and didn't want to make the toggle too lengthy but noted none the less.

2. I think you just mean from a UI perspective that it would exclude the other as at code level neither are. I'm okay with moving it to system, shouldn't be a problem

[echo6ix]

I'm sure @WithoutPants would have a good idea of where this should be located in the settings.

But at the same time, I wouldn't waste much effort looking for an optimal location. Because it looks like the entire Settings hierarchy needs reorganized eventually, with more conventional user-friendly node headings. I've been using it since the first version and sometimes I'm still searching where settings are situated. 😅

[WithoutPants]

My proposal is to have a button, probably in the left panel of the settings screen, to activate this mode. It will bring up a dialog explaining what it will do, and if the user confirms, the system will apply the mode and reload the UI. Having an overlay as feederbox mentioned is a great idea and also provides a quick and easy way to switch back to normal mode. Having it override the log level to at least debug would also be beneficial if we can easily do it in the backend.

[Gykes]

Deferring till after .30 release. Keeping open in the meantime.

[Gykes]

@WithoutPants

My proposal is to have a button, probably in the left panel of the settings screen, to activate this mode

Do you mean on the main page underneath Advanced Mode and have the same style toggle?

[echo6ix]

My proposal is to have a button, probably in the left panel of the settings screen, to activate this mode. It will bring up a dialog explaining what it will do, and if the user confirms, the system will apply the mode and reload the UI. Having an overlay as feederbox mentioned is a great idea and also provides a quick and easy way to switch back to normal mode. Having it override the log level to at least debug would also be beneficial if we can easily do it in the backend.

Good idea.

Before this gets finalized, it might be a good idea to revisit the optimal name for the toggle.

• Troubleshoot Mode is a clear-ish but long.
• Debug Mode is a concise, but a bit technical.
• Safe Mode is both concise and clear. I believe this term is commonly used to describe a minimal fallback environment when booting into devices or operating systems for troubleshooting - exactly the intent here - perhaps best for a general audience. The only disadvantage is you just implemented a SFW Content Mode elsewhere - could these cause confusion with another? Maybe any confusion is not an issue with the confirmation dialog you mentioned.

[sleetx]

I would not use "Safe Mode" as that could be confused with "SFW mode".

I like the idea of the logs being more easily accessible. Perhaps showing the most recent lines at the bottom of each screen, rather than needing to browse to Settings > Logs.

I also like @feederbox826 idea of a permanent overlay indicating this mode is turned on (and an easily accessible link to turn it off). Something like this:

[feederbox826]

maybe also add a default css blur to images (studio/ performer/ cover/ gallery), saves a lot of steps for censoring

both can be added via css, just add a root variable that activates it

[Gykes]

maybe also add a default css blur to images (studio/ performer/ cover/ gallery), saves a lot of steps for censoring

both can be added via css, just add a root variable that activates it

10 minutes, eh?