Plugin Assets via Git Submodules

If I am creating a plugin that has assets that are from a Git submodule (such as .js assets), what would be the recommended approach to handle this?

In Kirby 2, I would just have the Git submodule live directly within the plugin and the asset URLs would be straightforward.

In Kirby 3, I suppose I could stick the entire Git submodule within the assets/ folder, but the strikes me as somewhat counterintuitive. It should make the .js files I need accessible, but also makes some other, unwanted files accessible (which, is certainly no worse than the K2 way).

I’m curious if there’s a different/recommended approach to handle this scenario that I’m neglecting?

1 Like

I’m guessing you’ve already had a look at the official docs on how to structure your plugin folder? The plugin architecture in K3 is much more extensive than in K2. You can include templates, snippets, and have an actual assets/ foder inside your plugin folder, and it will be detected automatically. The assets/ folder is where you’d keep CSS and JS files, so if your submodules are CSS/JS assets, that’s where they should be. You may get some extra built-in Kirby functionality, like auto-timestamping of the assets for cache-busting.

Is that what you were asking?

1 Like

Sort of. My “concern” is that all of the submodule files that have these extensions css|gif|js|jpg|png|svg|webp|woff2|woff are now publicly accessible.

Again, this is no worse than before, but I would prefer to “whitelist” which files I actually intend to use.

Also, in terms of the “auto-timestamping”: I still cannot figure how to actually get this to occur. Sample code for this would be great. See https://github.com/getkirby/getkirby.com/issues/148

Why not using npm to manage these dependencies?

If you want to secure your Kirby installation better, and restrict the access that visitors have to certain folders - or all of them - then you should have a look at the custom folder setup instructions. This would allow you, for instance, to put the entire site/ folder outside the public directory, where it would not be directly reachable. The docs show you how to completely secure your installation by leaving just the index.php file in the public folder, and therefore restricting the visitor to only ever accessing what you allow them to see.

1 Like

In all honestly, using npm seems like overkill.

I do have the custom folder setup, but that doesn’t really “help” if I’m sticking an entire git submodule in the assets folder of a plugin. By design, a plugin asset’s folder is supposed to expose [most] of the contents publicly.

Considering this is no worse than K2 (actually, it’s a little better since it’s restricted to certain filetypes), I guess I’m not gonna worry about this too much.