I’m a noob who’s trying to learn the ropes of Kirby—I blame @kevq for this—and am not understanding a couple of points: panel security, and the use of a staging server. The panel information states it cannot be installed by default on a public server, but how does one go about setting up a staging environment (installing the panel on only this) and then syncing it with the live web-facing server? Bastian’s post below had sparked this question for me:
My follow up question would be in terms of panel security, is this setup even recommended or necessary for a single-user blog site?
Necessary: Definitely not. Does it make sense in that context: Probably not, but that does depend very much on your requirements, particularly, since Kirby doesn’t have a preview for unsaved changes yet. If that is a requirement, then a staging setup makes sense.
Keep in mind that such a setup usually mean a more complex workflow for deploying, to keep your local, your staging and your production environment in sync.
Security: In general, Kirby isn’t that much affected by attacks as particularly WordPress is (much lower number of installations). And you can do a lot to protect your site, see our Security Guide: Secure your project | Kirby CMS
Thanks, Sonja, that was a helpful explanation. The fact that the panel has 2FA available—fantastic feature, BTW—would pretty much nullify attacks in combination with its built in protection. If I can figure Kirby out enough to be confident and decide to switch to it, I’m also considering leaving the panel disabled permanently. I’d opt instead to work directly with files and content on the backend via git, even though I’m not a huge fan of git for publishing blog posts—I think it’s overkill.
That’s exactly what we do when working with the getkirby.com repo for our website. We create and modify content directly in the content folder. There’s pros and cons to working like this, of course, but it’s worked fine for more than 10 years for us now.
How does this approach (editing content directly in files and using a git repo) work when using Blocks and Layouts in the Panel (because the client wants a GUI, and we assume that’s what the GUI exists for…), which saves content as raw JSON blobs in the the text files?
Perhaps I missed something here?
My starting point is similar to the OP, except I have already built the whole site using Layouts and Blocks extensively, because using git to manage the content was a non-starter for the client.
I guess the question becomes how does one architect a setup that includes a staging environment where the client can stage content using the panel (which uses Layouts and Blocks extensively) and I can stage design/dev changes (both of which can then get deployed to production)?
