I just installed it in a fresh kit and have no error.
Do you get more information in the console? Does the error persist if you replace image-clip with files in your blueprint, to make it a normal files field?
Normal files field works just fine.
Checking console … one sec … nothing …
This is my blueprint:
tab_book:
icon: page
label:
de: Bibliographie
en: Bibliography
columns:
left:
width: 3/4
sections:
left_fields:
type: fields
fields:
book: fields/groups/book
right:
width: 1/4
sections:
right_fields:
type: fields
fields:
cover:
label: Cover
type: image-clip
query: page.images
layout: cards
multiple: false
info: "{{ file.dimensions }} ({{ file.niceSize }})"
image:
ratio: 3/4
right_images: sections/images
1 Like
There’s nothing special here, what do you think @texnixe?
What could be causing this specific error?
// Edit: When choosing another name for my field, it works as expected. I’m not fond of changing my field name, as cover is exactly what it is … I’ll tell the plugin author over at Github and maybe we can sort this out … thanks for your effort, as always!
Ok, I tested it in page where the cover field already existed and got the same error.
Have you made sure that your text files do not contain a cover field with content already?
This is not an error in the image-clip field.
Will check that. Most content files were there from the beginning of K2 - any method to clean them, and only keep what’s actually defined in the corresponding blueprint file?
// Edit:
Well, my problem persists, and it might be even harder to debug:
Now, I enter an image, save the page, visit another page, and everytime I come back, the field has the error shown above. When I change the field name once more, reload the page: I can select an image again! But, when saving, leaving the page, coming back: again, Illegal offset error …
Can you reproduce the issue in a fresh starterkit?
Should be possible by updating the pages and setting non-existing field to null.
I made the necessary adjustments, and got this:
Now, I got it to work and no such error occurs, but the field doesn’t to what it’s supposed to …
Well, unless the plugin author or someone else comes up with a brilliant idea, I can’t see where my setup is going in the wrong / weird direction, …
// Edit:
@texnixe, maybe that’s something: the plugins seems to save content like this (content/somepage/template.txt):
Front:
-
id: >
lesetipps/die-muskeltiere-einer-fuer-alle-alle-fuer-einen/die-muskeltiere-einer-fuer-alle-alle-fuer-einen_ute-krause.jpg
… whereas this leads to the error:
Front: die-muskeltiere-einer-fuer-alle-alle-fuer-einen_ute-krause.jpg
// as well as this:
Front:
- die-muskeltiere-einer-fuer-alle-alle-fuer-einen_ute-krause.jpg
YEs, that is correct. That’s why I said if you have already stored content in the wrong format, then the error is thrown.
Cover:
-
id: >
photography/animals/abba.jpg
clip:
width: 800
height: 599
left: 425
top: 469
-
id: photography/animals/bird-reynolds.jpg
clip:
width: 800
height: 598
left: 128
top: 171
This is what it look like with the clip data
1 Like
Sadly, this would mean that it’s not possible to just replace / dropin this plugin, and I would have to change about 100+ entries by hand?! It’s not as compatible as swapping toFile() with toImage() …
So you WERE right, as always - I get it now … woof, thanks for hanging in there with me …
You are welcome. You would have to write a little script that stores your current content in the target format, you don’t have to do this manually.
So, how would this work? Update Page, but of Field does bot exist, how can it be set to null?
That was supposed to say: if it doesn’t exist in the blueprint but does exist in the content file.
However, in the current case, the field should not be removed because it contains content that has to be converted into another format.
I think he she (pardon me) wanted to know how you would go about ‘cleaning’ a content file (actual code example, etc), maybe that would be a good idea for a plugin?
Ok, here’s a recipe how to clean up your site:
Don’t forget to make a backup before running this code. Also, you might not want to run through the complete index if you have thousands of pages.
1 Like
@S1SYPHOS thank you for finding this. I haven’t considered that fields are just swaped out, but it is a valid use case. I will look into it and see whether the plugin can or should handle it. Changing the content file structure automatically could be a problem if you decide to go back to the core images field…
I would use your Field all the time, since Many Clients expect such functionality, but for me it has to be a dropin-replacement for the files Field (changing toFile to toImage would be okay I guess)
@moeli As a first step, you could at least put a note into your readme that you can’t simply replace one field for the other.
Making this an automatic process is not without issues I think, and there should be a way back. Maybe rather provide two scripts to handle this manually after having made a backup?