Please add the ability to disable plugins

  • Perhaps making a new rule for plugin authors and style authors before submitting to the plugin store, that their styles and plugins have a module (enable/disable switch) included. All current plugins within plugin store should update their plugins to include as well, then users could just update all their plugins in ACP at once, and all currently used plugins have a module there available. I agree with hybrid, there should be a module or on/off switch for each plugin specifically, to easily pinpoint issues without uninstalling all your plugins, possibly losing data, etc, then have to re-install them again. Having a global option would also help as well of course. I'm not sure if making new rule for plugin store is possible though?

  • Agree 1000% with the above post.
    On/Off switch is a Must have for all plugins.
    In the Past, many times I had to Unistall a Plugin - Loosing all data and Reinstall again when the Author Fixed the issue.

    Rule NR.1 for all Developers and Woltlab.
    Include on/off Switch for all Plugins.

  • There already is such a rule but not as you desire: Only plugins, which may create content should have a module to not overload the module page and the software itself. Otherwise everytime the software normally tries to interact with a plugin it has to test wether the plugin is enabled or not. That would be an overkill after some time…

  • Otherwise everytime the software normally tries to interact with a plugin it has to test wether the plugin is enabled or not

    I thought the software would be interacting constantly with the plugin once installed. If instead that happens only when the plugin "is called" by the software to perform its task (through user interaction with forum's features), how come that a simple test to check if it's on or off would cause overload?

  • So a core enable/disable option for example below in screen shot is out of the question too? It would work similar to categories or menu items. Then plugin authors wouldn't have to include module switch for it. Core system would handle the brunt of the work so to speak, but have core system only disable/enable when needed, not all the time. Disabling and enabling would only need to be used when testing possible plugin issues. Sorry for poor photoshop job. :P

    Einmal editiert, zuletzt von Smooey (2. Februar 2015 um 21:53)

  • There are enough plugins, which cannot be modified to have module switches and there are enough plugins where module switches don't make much sense. And some plugins can be safely uninstalled instead.

    This is not about if an on/off switch will make sense to you or not. Some plugins, for whatever reason, might cause problems, as we all know. The ability to disable them would simplify troubleshooting. Actually, not only will a disable feature allow not to lose custom settings and edits while investigating the cause of a problem, but it will also simplify the ruling out one suspect plugin among others. Once established the culprit, it'll be quick and easy to re-activate one and uninstall another.

    2 Mal editiert, zuletzt von rafix73 (2. Februar 2015 um 21:59)

  • 100% sign.

    Something, anything... That would allow me to turn off ALL add-ons in 1 shot would be idea. I know Woltlab doesn't like file edits, but this is one thing I think adding to the config file would be useful... Something to disable all hooks.

  • Even if to be included for "Debug" mode, would be sensible, because plugins aren't "Core" anyway. When user needs to debug issues, just enabling debug mode should disable plugins themselves to pinpoint issues.

  • I'm curious if a free plugin could be made as a temporary solution, because this is probably too big to include in core at this stage of development/RC phases. A plugin that could some how create a module switch for all or individual plugins to be able to turn them on or off when need be. I know all plugins don't require a module switch, but maybe a plugin that could possibly give all known installed plugins a temporary module switch when you need it.

    Perhaps even a plugin that doesn't need to be installed all of the time, but only when needed. A user installs the plugin, does enabling or disabling of plugins, finds the culprit, and then uninstalls the "plugin module switch adapter". It wouldn't be required to keep installed forever. Then at least if the user finds the culprit plugin, he or she can make a choice / decision to remove the culprit plugin or not, back up data, etc. Otherwise, the user is almost "forced" without a choice to remove them ALL, losing all data, etc, and have to build all the data back up again (after reinstallation of plugin) that shouldn't have been lost to begin with.

    Example plugins: UZ Absence, Who Read Thread, Who Wrote in Thread, Who's Visited/Viewed forum today, jCoins related plugins, UZ invitation, UZ Welcome, Donation System, etc. This is why I'm hesitant to launch forum on one version, then to update to another version later and possibly lose data and etc during update. Hence all the waiting for another version to come out (not bothering to launch site), and just install the "latest" and launch site using the latest version. If something were to break between updating, data lost, etc. Or even if running into issues like Rasty has, and possibly lose data, etc that way, because you're "forced" to remove plugins to pinpoint the culprit.

    Plugin could possibly check for those plugins that include a module, ignore those, and only creates a module switch for plugins that don't currently have one. Unless all that plugin data remains in the database even after uninstalling them, which could potentially be a good thing, but possibly not, because it means that extra data is left behind and not removed after uninstalling a plugin, which isn't really a good thing either. It's a good thing to save the data in a sense, but yet not, because removing plugins should also remove database bloat/un-needed data.

    Sorry for bad photoshop skills on this one lol.

    4 Mal editiert, zuletzt von Smooey (19. Februar 2015 um 23:32)

    • Offizieller Beitrag

    Hi

    I'm curious if a free plugin could be made as a temporary solution,

    this is not possible in (almost) every case. The plugin itself has to have support for the module and disable itself. Some plugins provide essential functions to other plugins as well, disabling these could possibly break your administrators control panel, these plugins kind cannot be removed for the same reason until all the plugins requiring it are removed.

    In general it is recommended to try out any major changes in a test installation (accessible for the licensee only) or a copy of your production board.

  • In general it is recommended to try out any major changes in a test installation (accessible for the licensee only) or a copy of your production board.

    This is what several people do already (at least I hope most do), but it isn't an optimal way to proceed. You also need to consider that not everybody may be able to copy their forum on a local installation or under a sub-domain. Having the ability to disable plugins in ACP would expedite and simplify troubleshooting to a great degree.

    Einmal editiert, zuletzt von rafix73 (19. Februar 2015 um 23:52)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!