Kirby 3 as Headless CMS for Vue/Nuxt

@mattlenz I have been putting things in place for the same, you sound further ahead, want to work together on this?

Without having read all the replies, heres a website using Kirby 3 as headless CMS with a Nuxt.js Frontend:


Itā€™s definitely takes a bit of effort to setup, but works great!

3 Likes

Do you serve your local server with a https certificate?

Somewhat solved this with a custom endpoint: https://github.com/robinscholz/CYMB_Backend/blob/master/site/config/config.php

I am looking through the code, but cant see if you are. How you handle kirbytext?

The custom endpoint converts kirbytags:

function kt($array) {
  foreach ($array as $key => $value) {
    if (is_array($value)) {
      $array[$key] = kt($value);
    } else {
      $array[$key] = kirbytags($value);
    }
 }
  return $array;
}

You could probably do the same for kirbytext, though with some more sophisticated code.
Somehow youā€™d need to figure out which fields to convert and which to leave untouched. Otherwise every field might get wrapped in <p> tags.

That would mean sending HTML over the API response?

Sure, if you parse it server side, you will have to.

Thats a big red line for me, I started putting together client side Kirbytext parse, sounds like @mattlenz has made better progress than me.

Could you explain why? Not sure whatā€™s the downside here.

While it will make the implementation simpler, anything that renders raw html received from external source is not great practice from a security point of view. The source could be ā€˜spoofedā€™. While parsing the kirbytext does not fully mitigate this, its controlled and only the relevant tags are parsed.

Fair enough, but I would argue that for alot of kirby based projects this risk could be considered acceptable. Nevertheless Iā€™d definitely welcome a client side Kirbytext parser!

1 Like

really enjoying the evolution of the conversation!

re: parsing text. for now iā€™ve just been using markdown instead of kirbytext. this canā€™t work for all projects of course, but unless you use specific plugins in the panel that introduce their own tags, itā€™s fine.

definitely up to help out if needed on the kirbytext client side parser :slight_smile:

Just spent the last 10 mins writing a regex for the kirbytext tags

([a-z]*):\s[a-z\s]*(?![a-z]*:)

This is what I have so far ā€¦ anyone wanna have a go improving? I have listed 2 known issues with it. My parser already extracts the tags them selves, so its just the content parsing required, once these 2 are nailed that basis is done.

Edit, Yes I know it only works with lower case etc, its easier to debug this way.

I think I wrote this on Slack already, but maybe you have missed it: Kirby also uses RegEx for parsing, so why donā€™t you use ours?

1 Like

Ah wasnā€™t sure who and where messaged me that, I will look at it now.

Handling kirbytext on the server-side as @rbnschlz has shown would be much simpler than to rewrite kirbytext in js.

Doing it on the client/js side means you lose all internal kirby context. You have to manually re-implement every tag and lose any custom tags youā€™ve written. Plus creating proper image tags requires looking up the image file from the page object to retrieve the URL.

@DanielRivers hereā€™s where I got to (warning; messy) if you want to pick up where I left off https://gist.github.com/mattlenz/78154ed23c9318df587126dc7fed1293

2 Likes

I totally understand the hurdles, but I feel that they are all solvable.

  1. tag -> HTML I donā€™t believe is a massive challenge, with the handful of ā€˜officialā€™ tags its not awful.
  2. With this approach, custom tags would be written solely in JS and not extended in Kirby
  3. Context aware image is solvable using windows.location.

I will fork your gist and make some changes I had in mind.

I got the API to work with both types of authentification. But as far as I understand and tested the API can not be used as a backend for public websites so far. This is why authentification is always required and defining a ā€œGuest-Userā€ with no access to the panel doesnā€™t help.

Another drawback is ā€“ correct me if Iā€™m wrong - that kirbytext-fields can not be delivered as parsed HTML. That would mean that the frontend would have to do that which is unnecessary overhead.

(Another point that would be nice is if the API would deliver blueprintā€™s field-information along with the data. I didnā€™t find any option for that.)

2 Likes

TBH, thatā€™s necessary overhead in my case. Delivering HTML from external source and rendering straight into your page is really bad practice. Though mentioned above, many of sites that run kirby, this may not be a concern for some. I am working on a client side parser, though been distracted with my K2->k3 conversion