Maybe there is a problem with a plugin. You want to use it but need to disable it for some reason. To disable it you need to rename or move the plugin folder so Kirby can not use it.
I have another idea…
Disable plugins by config
One
c::set('kirby.disable.plugins', 'splitview');
Or many
c::set('kirby.disable.plugins', [
'splitview',
'seo',
'pre-controller'
]);
In the long run it would be nice to disable things like fields and tags etc as well.
I simply disable them (during development, to avoid any artefact) by changing the folders-name;
myplugin\myplugin.php -> works
x myplugin\myplugin.php -> doesn’t work
when done, I remove the x and it’s working again 
- edit - Hmm… I can also create a simple widget on the dashboard that shows all plug-ins.
And you can disable / re-enable them from the widget on the same maner.
Will first work out my image preview plugin and than create this widget.
If I understand you correctly the widget would list the plugins and by choice deactivate it by renaming the folder to some prefix? Maybe add a . as prefix before the folder name. That should not collide with active plugins.
If that is what you mean, I think it’s an interesting idea. A good workaround.
I still think this suggestion is still relevant, because it can be done in a simple way even without a UI.
Yeah - adding a single dot . is a better solution.
Or something like -1_foldername.
And I want to keep it simple, a bit like WordPress does - but without all the options.
Just toggle a plugin from active to inactive, and vice versa.
I think this can be done by plain .php and some ajax-functions.
Yes, it would be nice to have a panel widget for that.
Even if they implement my config suggestion you could still have your widget. It would still work and it would probably be easy to change it to the new syntax if you would want that.
This might work, but I think plugins for Kirby are way different than plugins for Wordpress. There are a lot of plugins which are, once installed, not as easy to remove as just renaming the folder, because different parts of the site are totally dependent on them. When you are using for example the relative date plugin (http://getkirby-plugins.com/relative-date), using the function which is never defined would cause the site or certain pages to break. So one have to be really aware of what he or she is doing if deactivating plugins. For others, like auto publish or the MinifyHTML plugin, it would work of course.
Agree! That’s why I think my config suggestion is good for the core and the widget is good for a plugin. It would then be optional to add the widget, as it’s not a built in thing.
I wouldn’t want to have a widget for this. As @jakobploens wrote, that’s just not compatible with how Kirby plugins work.
Jens, what is your use-case? Why do you need to disable plugins? Maybe we can find a better and simpler solution for that.
To be honest, I don’t really see the use case for a widget; it just adds stuff to the panel that is not really helpful there (Wordpress, Joomla etc. way of adding bloat).
As regards the config setting, I’m not really sure that is needed either. Ok, the advantage to moving the plugin would be to keep it in place. But I don’t know if that use case is so important to have yet another setting in the config file.
Let’s say you have a problem with the site. You have 20 plugins and want to know which one that make the problems. Then it could be nice to, by code deactivate them instead of rename 20 folders.
I agree that the widget is not the Kirby way. For a plugin yes, but not for the core. I’m always very open minded about plugins because they never do any harm. I mean, you are never forced to install them. If you don’t like them, don’t use them.
Maybe my solution is not the best one, but I think the problem is real.
I just throw the folder out. Much quicker than a config setting.
That’s the way I do it as well
…or rename it temporary, in order to check for the results.
But when you’ve a plug-in that installs several folders, in several locations - throwing / renaming the “main” folder also causes issues (when the plug-in itself is not checking for it’s own integrity).
So the best way - for now - is a manual solution… and not installing too many plug-ins.
I only use minifier and cache-buster as default.
When I see that some plugin is making problems, I move out all plugins and move them back in one by one. So that’s a similar strategy as @texnixe’s.
I understand your point of view, but personally I work faster in the code editor than moving around folders.
That’s why… tadaaa, a new plugin!
I want to wake this up old topic again. I still vote for a config to disable plugins of choice.
A new take on why it can be beneficial is that different environments may have different needs.
config.localhost.phpc::set('kirby.disable.plugins', ['kirby-html-minifier', 'kirby-ga']);
config.yourdomain.com.phpc::set('kirby.disable.plugins', ['kirby-panel-brand']);
Benefits
config.php, It’s much simpler to have one option to control all the plugins, than having a unique config for every plugin that supports disabling.Sources:
fwiw, this is pretty much the use case I’m looking to solve too - there are several plugins that I do not want to run in local dev, but do want in production
Hi @jenstornell, where can I find your KirbyPlugin Kirby Unset Plugins?
The Github link will not work actually.
https://github.com/jenstornell/kirby-plugins/issues/245
Note that the alternative is no longer developed, either.
This plugin can also be used to deactivate plugins (I personally think it’s not such a good idea to deactivate plugins via the Panel as it might easily break your site, but obviously, other people think differently about this).
Thank you @texnixe.
I personally think it’s not such a good idea to deactivate plugins via the Panel as it might easily break your site, but obviously, other people think differently about this
I can comprehend this but I have some Plugins like SASS which I need only on my development environment. And if you restrict a function like this to an admin it should be okay, as I think.
Yes, this makes sense. But if you use field plugins or anything that is used in your templates or controllers, the Panel or your site will break if you don’t remove the fields/code from your blueprints/templates/controllers/plugins…