`image` info (e.g. files field) gets stored in localStorage, doesn't pick up blueprint changes

[fvsch]

Description

It looks like the files field type caches the config used to render image cards in a way that makes it near impossible to modify a page or section blueprint and see the results of changes in the panel.

When trying to modify field options like info, image.ratio or image.back, changes are not picked up, even when restarting the development server.

Changes are picked up when:

1. Renaming the field (e.g. from my_image to my_image2).
2. Removing the selected image and adding a new one.

Changes to other field options such as label or layout are picked up with a page refresh.

Expected behavior

It should be possible to work on blueprints and see the results in the panel, especially during development. Ideally that should happen automatically, without specific config tricks.

To reproduce

1. Create a new plainkit project with composer create-project getkirby/plainkit

2. Start a development server with composer start

3. Create a site/blueprints/pages/test.yml blueprint with:

title: Test page
fields:
  my_image:
    label: My Image
    type: files
    layout: cards
    max: 1
    image:
      ratio: 3/2
      back: green

4. In the panel, create a page of type “Test page”, and upload an image for the “My Image” field.

5. Change the blueprint to:

title: Test page
fields:
  my_image:
    label: Very Cool Image
    type: files
    layout: cards
    max: 1
    info: "{{ file.dimensions }}"
    image:
      ratio: 1/1
      back: orange

6. In the panel, refresh the page. What I'm seeing is:
   • The label updates
   • The info footer doesn't appear
   • The image ratio and background don't change

Your setup

Kirby Version
3.9.2

Console output
None

Your system (please complete the following information)

• Device: Mac Air M1
• OS: macOS 13.2.1
• PHP: 8.2.3 (via Homebrew)
• Browser: Chrome (stable)

[bastianallgeier]

It's quite possible that this is related to the built in PHP server or your opcache settings. Normally this is not necessary at all.

[afbora]

@fvsch I can reproduce but I don't think this is a bug. I assume you updated the blueprint file without saving the page after making changes to the page, is that correct?

[fvsch]

@afbora Good catch: this only happens if the image is uploaded but the page is not saved.

This still feels like a bug though? Why would it behave differently when the page is not saved yet?

When I reload the page (still unsaved), the DevTools Network panel shows that the panel is requesting the resolved blueprint data for the page:

But there is a saved change in localStorage that contains the old config for the image, and that gets applied on top I suppose:

Feels a bit strange that data like the image ratio or background color would be part of the change data. But stuff like the info text is tricky because you need backend access to the file to update it.

Still a bug IMHO, but maybe it's too much of a stretch to solve it with the current design.

Maybe the only possible fix is adding a warning to the docs, e.g. on https://getkirby.com/docs/guide/blueprints/introduction, that when working on blueprints you should make sure that all page content is saved or there might be conflicts between unsaved content and the updated blueprint?

[afbora]

I don't think it is a right logic and possible case to change the page structure without saving the page.

[distantnative]

This will need a while - we need to move in quite a few places from storing those meta info alongside the content values, but separately.