Kirby Unset Plugins

We had a discussion about a way to deactivate/unset plugins by a config value. It was not a very popular topic, as not that many agreed with me.

But I’m quite stubborn so I made it possible anyway.

Kirby Unset Plugins

https://github.com/jenstornell/kirby-unset-plugins

As string:

c::set('plugin.unset.plugins', 'splitview');

As array:

c::set('plugin.unset.plugins', [
  'pre-controller',
  'revisions',
  'splitview'
]);

Maybe a strange option key, but at least it will probably not collide with the core or other plugins.

2 Likes

Well, at least we have lots of examples once we get round to writing an intro to plugin creation :joy: So keep going …

As @jakobploens already pointed out in another thread, disabling a plugin usually involves more than just renaming it. Depending on the type of plugin, you also have to remove code from your templates, controllers etc. to make your site work without the plugin.

I have ideas for at least two more plugins. :smiley:

Depending on the type of plugin, you also have to remove code from your templates, controllers etc. to make your site work without the plugin.

That is why I agree that it should not be built into the panel. I will try to explain a simple as possible how I see it from my point of view.

Look at this:

As a developer you need to fix something that does not work, or at least find it.

require 'class/page.php';
require 'class/pages.php';
require 'class/models.php';
require 'class/templates.php';
require 'class/snippets.php';

Maybe a wierd example. In this case you need to see what will happend if you don’t run class/snippets.php.

What do you do?

  1. Comment out the line?
  2. Rename or move the file?

In this case I think most people would just comment out the line.

That’s how I see it with the unset plugin option. As a debug tool, where you can comment or uncomment plugins.

Yeah, at least until I have to comment out the unset plugin… :stuck_out_tongue_winking_eye:

Edit:

My point of view: It’s very likely that most of all these plugins will stop working at one point or the other because their authors have moved on to other playgrounds. So, the more plugins I install, the more likely my site will break with the next update. Or I stop updating for fear of breaking my site. That’s probably the reason why so many Wordpress, Joomla etc. sites with all their installed plugins do not get updated and therefore hacked after a while.

:wink: I actually thought about a protection against that by unset that key from the array, but then I felt it’s more the Kirby way to leave it.

It’s very likely that most of all these plugins will stop working at one point or the other because their authors have moved on to other playgrounds.

Oh so negative! Then we could just skip the plugins, skip Kirby, skip life…

As I said, keep on going … it’s good practice and it’s good for Kirby if there are many plugins, because ready-made solutions will most likely attract more potential users. I only meant to say that there’s always a certain danger in using too many plugins.

1 Like

I only meant to say that there’s always a certain danger in using too many plugins.

Thirst thing for all CMS’es (or sites / apps)… don’t rely on plug-ins :slight_smile:

Maybe only for the real huge things (e-commerce, security, analytics, etc…) - but the less plug-ins, the more native (own) code, the better… :stuck_out_tongue:

I personally prefer the small plugins that is made to only solved one task. I don’t like the all-in-one solutions. When chosing an all-in-one solution it often lock you in.

thank you for sharing plugins

1 Like