Support for "blocks" function of Kirby Editor

[renestalder]

Describe the bug
I can't clearly tell whether this is a kql plugin issue or a editor plugin issue.

When querying an editor field via kql plugin, the page.field.blocks only returns the block ids.

To Reproduce
Steps to reproduce the behavior:

1. Install the kql plugin
2. Install editor plugin
3. Create a blueprint using the editor field, e.g. on the site.yml, named my_editor_field
4. Query the API with an editor block
5. You get the JSON result
6. Now query the API but use the blocks function as described in the editor plugin wiki
7. API responds with an array of block ids.

Here's a random example. The my_editor_field_1 would output json. The my_editor_field_2 would output an array of block ideas.

Example query

{
  "query": "site",
  "select": {
    "my_editor_field_1": "page.my_editor_field",
    "my_editor_field_2": "page.my_editor_field.blocks"
  }
}

Expected behavior
When using the blocks function in the field query of kql, I would expect it to return the editors content as HTML the same way this function works outside of KQL.

[bastianallgeier]

KQL uses an allow-list for objects and methods that can be queried and executed. Blocks are not included. We will very likely not support the editor blocks, but the blocks of our upcoming blocks field. The editor is going to be replace by that eventually.

[renestalder]

Ah, I see. I was of the impression the editor plugin might be moved to the core as is. Thanks for the hint.

But for clarification, when I understand you correctly, even when I go and install 3.5's release candidate and use the those included block fields, I might still not be able to get those via kql in HTML; this is not implemented yet in kql, is this correct?

So, just for your understanding: Now I'm probably going to build 2 or 3 websites per month on Kirby, all decoupled (headless), which currently is only reliably possible thanks to the kql plugin (the only solution dealing with KirbyText built-in) without additional effort of writing a client-side KirbyText parser. For me, it's still a bit to figure out which headless features or plugins in Kirby are the most robust in the long term.

[igregson]

This sounds similar to what I described in #15. The underlying question seems to be whether KQL should return serialized HTML or raw JSON. I can see valid reasons to want either (even both). Perhaps having the option to return either/both is the preferable approach here?

[renestalder]

That kind of seems out of question to me, as there is parsing logic for blocks in the PHP library. And as kql basically seems to make use of that existing logic in other cases (either directly or by "faking it", I don't know, I didn't look at the code) for every query, it's only logical that this behaviour of the blocks will be available in kql. It would also be inconsistent to have those functions for parsing KirbyText, Arrays, YAML, JSON, Structure fields and so on, but then not for blocks.

For me, the remaining question is rather: When is it going to be available?

(btw. speaking of the editor plugin, you're able to return the JSON by now. But as said, using the blocks function in the kql query seems to return the ids only instead of parsing the whole JSON object)

[renestalder]

Closing in favour of #20 which addresses the question for the new 3.5.0 blocks and layouts, where I referenced this possibility for the earlier Editor plugin.