Static site generator#24

It would be awesome to be able to simply generate static websites from the Panel. Something a bit like d4l’s plugin https://github.com/d4l-data4life/kirby3-static-site-generator but built-in.

I’d question that this is good to be in the core - just by so many users not needing it. Seems like the perfect use case for a great plugin to me.

You will be creating a loophole in Kirby EULA, in my opinion with this feature. Thus using Kirby for free.

@Jakub Pelák You mean in terms of one Kirby installation with one license could generate 100s of static sites?

@Jakub Pelák I agree that this could be a loophole, but I guess we could fix it. I still wonder if this should be a core feature or a plugin – like @Nico

@Timothée Goguely where do you see the biggest advantages or reasons for a core integration?

@Bastian I think it should be some external utility, not even a plugin. If you start puting everyting into the core it might grow just too huge. And I am of opinion that this is rather an edge use-case.

Perhaps there should be some api that this [cli] utility can communicate with when creating the static site. I see problem that when generating urls within the site and then deploying to another server.

@Nico Loophole meaning that development on your local machine requires no license. You still can buy it, though but it’s not required.

I don’t think this needs to be in core, but having an official plugin would make it definitely more “trustful”, than a third-party plugin. By providing an official plugin, it would clearly communicate the static site generation is something, that we officially promote/recommend and thus sending a strong signal.

It’s still questionable, how much flexibiliy such a plugin should have. IMHO, static site generation should be triggerable from the panel (section in site.yml or dedicated view or both. It’s often more comfortable to have such things on you panel’s “dashboard”). And in addition to that, it should also form from the CLI, which is the harder part, because Kirby does not have a unified way of doing CLI stuff (yet).

Exporting to a specified folder should be sufficient, if the plugin provides hooks for post-processing, such as uploading the static files to a different server or similar.

There are some tricky situations, that I also experienced when developing ImageKit for Kirby 2, e.g. if a page sends a redirect header. I’m still not sure, if such a plugin would need to implement a “smart” way of dealing with such situations, or if the docs should advise you not to use redirects, exit statements etc. in any code that’s needed for generating the static site.

I am all for official. It’s only my opinion, but the way I would use such thing is that I would write a shell script that 1) generates static site 2) deploys the static files to the remote server. I am stressing here that it’s only my opinion.

👋 I provided a very simple solution for the cli use case here: https://github.com/d4l-data4life/kirby3-static-site-generator/issues/26

Regarding the trust aspect it’s the same as with all or at least most of the other plugins: Feel very free to read the source code or fork it and adapt it to your needs. The license is MIT :)

About the loophole issue: Of course I do not endorse using Kirby without a valid license and if this creates a new loophole that wasn’t there before (at least technically, Kirby would also work without a license afaik?) this was never my intention. If there’s a feasible solution to prevent this, I’m very happy to incorporate it into the plugin.

imho giving the official kql a last push (maybe adding unittest and a cache to speed it up) and provide good example how to connect kirby with KQL to other static site generators might open up kirby for even more devs than rolling its own SSG.
so i am upvoting but for KQL.

@Jakub Pelák You can alread do that already with other super quality tools like https://github.com/tj/staticgen it doubt it would be easier any other way.

In my opinion only reason for even making Kirby static gen is for some kind of super high visits websites where you need to put them on CDN and your editors can regenerate/update that automaticaly from kirby. But thats more question of architecture and if you have that site you can and should do this yourself.

Let’s also not forget about Kirby file cache. As i understand it’s pretty close to static website. It still needs to run some php logic but even on small VPS we are talking about insane number of visitors.

You can develop a website with kirby and add the cache option. what’s the difference ?

Even with the cache option you’ll deal with PHP in your production setup. The static site generator creates plain html files, so you don’t need PHP in your tech stack in a production environment and could instead upload the files to a CDN.

i don’t usually use cache so i could be wrong but the kirby cache system generate a whole set of html pages in the cache directory, i think you can copy paste those files with the assets to get a static website

Even if this worked, including media files, translated urls and so on (which it doesn’t): Manually opening every page in every language at least once to update the cache and then manually copying the files is not feasible for any productive setup. But we have a working plugin which takes all of this and more into account.

This is what I was thinking about: https://github.com/getkirby/staticache

Thanks @Bastian, I’m looking forward to test it in production!