Please add the ability to disable plugins

    Quote from TimWolla

    Hi

    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.

    True, I was thinking that as well. The original thought was the plugin itself would be excluded, but it's not possible. So basically it would almost have to be built-in the core, or is that out of the question too? I'm under the impression that other forum software has this ability built-in their systems. Because not everyone tests every thing ahead of time, they just see a plugin, download and install it, expecting everything to be running smoothly.

    Also, not everyone's hosting configurations & etc are the same either, so testing things might not always be an option for letting them know something isn't quite right. But I surely hope there's something that can be done to help users with this issue? Just to have an option to disable all non-core plugins for debugging purposes, or one by one in core will help, of course not touching woltlab system itself nor any woltlab plugins either.

    Sorry super bad code example here lol.


    Code
    if woltlab products { ignore ; keep enabled = true 
all else if selected "all" or one by one, including plugin dependents(minus woltlab dependents or required): 
disable= true}

    But an idea, all woltlab products go untouched/not disabled, whilst other non-core plugins get turned off, either all at once, or one by one. But, I'm not sure, I didn't develop the software of course lol. Just an idea. Or maybe the trouble is the fact that the plugins are requiring or having dependent plugins, is part of issue? Which makes it harder to do an option like this. I'm wondering how other software handles this built-in core feature.

    Quote from SoftCreatR

    I'm pretty sure, that this isnt't the case.

    Um... Actually... Yes.

    phpBB
    System Machine Forums
    IP.Board
    XenForo
    vBulletin

    Heck, even Word Press has a method of disabling all plugins.

    In vBulletin you add this to the config file
    define('DISABLE_HOOKS', true);

    In xenforo it is this
    $config['enableListeners'] = 0;

    If I recall correctly, in IP.Board it is this
    $CONFIG['plugin_enabled'] = 0;

    And this list goes on and on...

    https://xenforo.com/community/thre…l-addons.34664/ here's one simple one I just found google search. Easy peasy, one line of code to config file lol.


    Quote

    At times, you may run into conflicts caused by add-ons. These conflicts may prevent you from accessing your control panel to disable the offending add-ons.

    To fix this, you can disable add-ons via the library/config.php. Simply add this line of code at the end:

    $config['enableListeners'] = false;

    This will disable all code that is being run by add-ons. You should then go into the admin control panel and disable the offending add-ons from there. The line you added to library/config.php should then be removed.


    https://xenforo.com/help/disable-addons-config-php/

    Edited once, last by Smooey (February 20, 2015 at 6:24 AM).

    Quote from Smooey

    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

    This method should be possible as well. It is standard in vBulletin, xenforo, and IP.Board.

    I do not think it could be added to 4.1, but 4.2 perhaps.

    Quote from SoftCreatR

    Okay, good. This would be a possibility, but that's not the described function in the initial post of this thread.

    I don't think that arguing on the semantics of topic post will get us very far. The request is quite straightforward here: "add the ability to disable plugins." Now that we learned other software already does it to some extent, the user-base here would be grateful to have such ability ;)

    Edited 2 times, last by rafix73 (February 20, 2015 at 9:08 AM).

    I know the one line of code will disable ALL plugins at once, so then you can't really tell which one is culprit after all, unless doing them one by one, like I said about. So a person still wouldn't know the root cause of an issue, and be stuck guessing again at which plugin was the culprit. It's a shame something like this is too big to include in 4.0 and 4.1 with a small "patch", because it would be an awesome feature to have at your finger tips - yesterday.

    Edited 3 times, last by Smooey (February 20, 2015 at 6:43 AM).

    Quote from Smooey

    I know the one line of code will disable ALL plugins at once, so then you can't really tell which one is culprit after all, unless doing them one by one, like I said about. So a person still wouldn't know the root cause of an issue, and be stuck guessing again at which plugin was the culprit. It's a shame something like this is too big to include in 4.0 and 4.1 with a small "patch", because it would be an awesome feature to have at your finger tips - yesterday.

    I'd like both. You idea would indeed be helpful to seek and destroy whatever problem came up. My idea would be the nuclear option should something so bad happen that you couldn't even each your admincp OR at the very least, let you know right away that it is an addon (without going through 1 by 1); thus ruling out any server issues first.

    Quote from Adam Howard

    Um... Actually... Yes.

    Um, actually, no.

    All of those only disable some parts of plugins and do not disable them properly. They give you - to some degree - the illusion that they can truly disable plugins, but thy do not really do it.

    Mostly, only hooks - in case of WCF this would be event listeners and template listeners - get disabled. But that's it.

    XenForo even has this box in their help page, regarding the disabling of plugins:

    Quote

    Depending on how the add-on is integrated, you may find that its pages still work or that there are references to those pages in your templates. You may need to uninstall the add-on or manually remove those.


    It's the same for all of them. They only disable some of the obvious hooks, nothing more. This kind of functionality can be provided by a plugin (don't disable THAT plugin, though). You could also think about disabling items installed via certain PIPs (e.g. page menu, ACP menu, permissions, options and more). In fact, other then event & template listeners and PIPs, there is only one other mechanic by which code of a plugin can be called, and that is the routing system. Disabling controllers beloning to plugins right inside the routing system would also get rid of that. One could use the installation file log to find those controllers and disable them.

    So yeah, it should be possible to truly disable plugins, if done right. Im not sure about standalone applications, though.

    "A life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP" — Leonard Nimoy

    I was speaking to the idea of it, not the fine tuned technical aspect. The idea of it, works 98% of the time for the desired affect... ie.. It's good enough. Of course if you want to be a perfectionist and want to get down to the very fine tuning of it, sure you can push it further.

    And in all the ones I listed

    phpBB
    System Machine Forums (SMF)
    xenforo
    vBulletin
    IP.Board

    ect... Most people are happy with the base concept and the functionality of being able to disable just enough to work with. And in 98% of the time, that is enough.

    Currently in Woltlab there is nothing to fall back on. Zip, zero, na da, nothing.

    Quote from Adam Howard

    The idea of it, works 98% of the time for the desired affect

    So you disable a plugin, for example the legal notice page plugin from WL. I'd naturally expect that this page that the plugin provides is not longer available for users. Yet almost every development you listed fails at this very basic thing (see my quote about XenForo for example).

    "A life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP" — Leonard Nimoy

    Quote from Netzwerg

    So you disable a plugin, for example the legal notice page plugin from WL. I'd naturally expect that this page that the plugin provides is not longer available for users. Yet almost every development you listed fails at this very basic thing (see my quote about XenForo for example).

    I have not experienced what you have described. If I disable X add-on, it stops working just enough so I can access the site and remove it. Or if I disable it in the control panel, X errors go away telling me that is the addon I need to remove (or fix).

    I guess I would be in the 98% as its good enough. This feature works in vBulletin and IP.Board as well. I've used it there and I guess I again hit the 98%.

    To provide administrators with the ability to disable plugins (even if it were something that worked 98% of the cases and "only" temporarily removed some of the hooks) would still help track down issues induced by plugins, and restore access to the site or ACP if compromised. In addition, it would really benefit new users that haven't familiarized themselves with this platform yet. Even a simple disable all addons/enable all addons feature would be an intuitive and easy enough way to start troubleshooting problems.

    Edited once, last by rafix73 (February 20, 2015 at 9:10 PM).

    My site crashed today because of an add-on. The only way to recover was to delete my site and the database, then restore from a backup. Now I make backups fairly regularly, but its easiy to sometimes forget and not everyone has automated backups either.

    Regardless, it shouldn't have required me to restore my whole site to recover from 1 single little addon. IP.Board, XenForo, vBulletin, WordPress, and every other mainstream development offers someway to disable a modification safely within the core.

    I would really need to see this in 4.2

    Quote from Aslan

    I would really need to see this in 4.2

    Yup, it would help us a great deal, and I'm sure, allow many among us who cannot afford downtime caused by breaking the site or ACP (which still happens even after careful addon testing in local installations) to sleep a bit better.

    Quote from Aslan

    Regardless, it shouldn't have required me to restore my whole site to recover from 1 single little addon. IP.Board, XenForo, vBulletin, WordPress, and every other mainstream development offers someway to disable a modification safely within the core.

    You talking about the IP Tools plugin?
    YOu did not have to do such a "Mess"

    1. go to wcf1_package delete the faulty package
    2. empty cache /wcf/cache wcf/templates/compiled
    3. working again ;)

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login