Default API endpoint for fields

[ovenum]

Description

Requesting a Page Field endpoint from within the panel results in a 404 error.

window.panel.app.$api.get(`/pages/${pageId}/fields/${fieldName}`);

Where pageId is a page path like parent-page+child-page and fieldName is a field registered with the requested page.

Expected behavior

Get the correct field response.

To reproduce

1. Log into the Kirby panel
2. Make sure a page with fields exists.
3. Take note of a field name and the page path.
4. Open the Browser Dev Console
5. Run command from Issue Description from the Browser dev console

   window.panel.app.$api.get(`/pages/${pagePath}/fields/${fieldName}`); 

Your setup

Kirby Version
3.9.0

Console output

{
  "status": "error",
  "message": "No route found for path: \"\" and request method: \"GET\"",
  "code": 404,
  "exception": "Exception",
  "key": null,
  "file": "../kirby/src/Http/Router.php",
  "line": 172,
  "details": [],
  "route": "pages/([a-zA-Z0-9\\.\\-_%= \\+\\@\\(\\)]+)/fields/([a-zA-Z0-9\\.\\-_%= \\+\\@\\(\\)]+)(?:/(.*))?"
}

[lukasbestle]

I can reproduce this. For some reason, $field->api() in this line is null (tested with a simple text field in the Starterkit). This means that there is no route that could be matched.

[rasteiner]

for that to work, the code behind Kirby\Form\Field::api() would suggest that the field needs an api entry in the options configuration array. The text field doesn't do that, neither does the select field the OP is asking for (according to discord).

You'd need to check the endpoint on a field that offers an api, like the pages field or the files field. In fact the endpoint seems to work there as expected

[lukasbestle]

@rasteiner Thanks for the additional information. You explain it very well: So far the field API is only intended for more complex fields that need to provide additional data to the Panel.

What we could do is to have a default route that just returns basic information or even just a simple response with HTTP 200 that just confirms that the field is there. Actually I think this is more of an enhancement.

@ovenum What is your use case for using the API like this?

[rasteiner]

This is the discord thread: https://discord.com/channels/525634039965679616/1069643179881676800

The use case is retrieving the options for a select field of a different page in the panel. So basic info about the field, or even the field value wouldn't be enough.

[ovenum]

@ovenum What is your use case for using the API like this?

Currently this is more a nice-to-have information displayed in a custom block with a pages field. The Block preview should load and display a field value once a page is selected.

A convenient way to fetch Fields from a page can be useful and most of the code is already in place (?). Using the /pages/page-id?selection=content will get the values stored with the pages content-text file. But for Structure or any of the Select fields this is usually not enough when the value is a or uuid/slug which is mapped to Label.

Reading @rasteiner explanation in the Discord thread i understand how the pages/field route is meant to be used a bit better. But maybe we can have a default endpoint for each responding with a Field response as pages/.../sections/ will do?

[rasteiner]

I guess a default route could produce whatever is produced for fiber?

[distantnative]

Updated the title to make it clearer what this is about in the end

[distantnative]

Move to https://kirby.nolt.io/576