How about an approved addon that simply disables all addons, it could also have an exception list for addons, that way when bonks occur, tracking them down could be sped up greatly.
You can disable all plugins by deleting all lines from the config.php that start with $Configuration['Garden']['EnabledPlugins'].
Adding an option the Dashboard seems folly because you're just as likely to have the Bonk happen in the Dashboard. And if you have access to the Dashboard, you could just click the 'Disable' buttons.
But if you get a bonk, sometimes you cannot get access to the dashboard aswell, so FTP is the only way in. Perhaps I am missing something. Like yesterday we did a complete fresh install of .18 version, and initiated the voting plugin, which crashed our systems. But I didn't have access to FTP, until two hours later.
I also find the dashboard interface of plugins quite tedious. Ther eis not batch operations. If there was it would be trivial to disable and enable, much like wordpress.
When you have thirty plugins active and for no apparent reason your forum starts bonking then being able to disable all plugins so you can go back through one by one to find the problem would be helpful.
The Dashboard bonking is a good point though, maybe the ability to call a maintenance page that automatically disables all plugins (after providing admin login and password) would be good too, although the config.php lines could be deleted Vanilla is supposed to be user friendly and lets face it the last file you want to make an accidental mistake in is the config.php.
@x00 The interface can be like the permissions and have a check box 1. enable 2. disable .... and at the top a check all/uncheck option at each column. To make life easier. But that will be only available in the dashboard.
for emergencies you could disable or rename the plug-in folder yes????
Another way Vanilla will be easier to check for bugs when a problem arises is to do a day/date stamp when the plug-in was installed and updated. This way you are able to track back your add-ons without keeping a log yourself.
If the add-on section is part of the core then it's better to recommend this as an upgrade to the next version. Better to improve the system then add fixes everywhere.
Add-ons should mainly be for non core issues... of course the add-on can be used to test theory first.
Comments
Was great for development bug work.
There was an error rendering this rich post.
grep is your friend.
Adding an option the Dashboard seems folly because you're just as likely to have the Bonk happen in the Dashboard. And if you have access to the Dashboard, you could just click the 'Disable' buttons.
There was an error rendering this rich post.
I also don't like the idea of deleting and pasting all those plugins back in. It would be easier if there was just a safemode option in config.
grep is your friend.
grep is your friend.
When you have thirty plugins active and for no apparent reason your forum starts bonking then being able to disable all plugins so you can go back through one by one to find the problem would be helpful.
The Dashboard bonking is a good point though, maybe the ability to call a maintenance page that automatically disables all plugins (after providing admin login and password) would be good too, although the config.php lines could be deleted Vanilla is supposed to be user friendly and lets face it the last file you want to make an accidental mistake in is the config.php.
@x00 The interface can be like the permissions and have a check box 1. enable 2. disable .... and at the top a check all/uncheck option at each column. To make life easier. But that will be only available in the dashboard.
for emergencies you could disable or rename the plug-in folder yes????
Another way Vanilla will be easier to check for bugs when a problem arises is to do a day/date stamp when the plug-in was installed and updated. This way you are able to track back your add-ons without keeping a log yourself.
Good points, last one is great and true.
Who knows, I might write a plugin that disables plugins lol
If the add-on section is part of the core then it's better to recommend this as an upgrade to the next version. Better to improve the system then add fixes everywhere.
Add-ons should mainly be for non core issues... of course the add-on can be used to test theory first.