Why is not the panel a plugin

The new Patterns is a plugin. Is there a reason why the panel is not a plugin? It would be possible to add a route to /panel.

Kirby would still be able to run free from the panel. The big benefit would be that as soon as it is a plugin with routes and so on Kirby would know about it. Other plugins that needs the panel url or so would benefit from it.

Or is it a security choice?

The Panel is a plugin, but a different kind of plugin. Simply delete the panel folder and it is gone, boom.

The reason why it is that separate is that it is just a way to edit the site’s content, and that can be independent from the production site. So yes, it is basically a mixture of security and keeping Panel bugs out of the core and the other way around.

1 Like

I like it as it is. Someday we may have panel plugins, and having them separated from the site plugins would be nice.

2 Likes

You have a point, but I think that’s far away.

Now we have fields for example in the site folder which is made for the panel, as well as blueprints. The panel stuff still goes into site. I guess if there will be panel plugins they will go into site/plugins as well, or we need to think about moving blueprints and fields as well.

To be honest, the main reason is, that I created the panel long before the router or other options, which can now be used by plugins. So the first version of the panel could have never been a plugin. But indeed this is different nowadays. It still feels cleaner and more dedicated to have it in a separate folder though.

For me, the site folder is the personal project folder. I actually thought about naming it project in the beginning. So I don’t see why panel stuff shouldn’t be in there. It’s more or less the central connection between the core and the panel.

I’m already working on panel plugins and I’m thinking about calling them apps or modules. That’s not decided yet. I think this is all just about finding good names and not so much about storing them somewhere else.

3 Likes

Because site is seen as the project, it falls natural for blueprints to be in site. I agree on that. Blueprints are in way personal settings for the panel fields.

But what about the panel fields? It’s not personal. It’s addons to the panels. It’s more like plugins. I think fields and panel plugins should be in the panel and blueprints in site.

What do you think?

But the Panel is for the Panel. site is for everything custom, the Panel contains only the core code that gets overwritten on updates.

Then I misunderstood. Now I understand. Everything in site, got it! Sorry about the confusion.

Then I vote for calling them “apps”.