Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Job files won't be created after changing the crop area, if image for requested size is already processed #30

Open
tpinne opened this issue Nov 22, 2022 · 1 comment
Assignees
Labels
question Further information is requested

Comments

@tpinne
Copy link

tpinne commented Nov 22, 2022

Kirby: 3.7
Plugin: 3.2

I have several image clip fields in several blueprints. The problem exists everywhere, so I'm picking one example.

And I see now that this corresponds to my previous issue #23 which is based on the same problem. But noticed and described in another context.

The following field blueprint for example.

heroImage:
  label: Bild
  type: image-clip
  required: true
  min: 1
  max: 1
  multiple: false
  layout: cards
  accept: image/jpeg, image/png
  clip:
    minwidth: 1920
    minheight: 942
    ratio: fixed

When I first set the crop area for a given image, then there will be generated several files inside the .jobs directory. At default directly for the panel preview in 352x, 864x and 1408x.

At my screen resolution the 1408x is directly generated as preview. Therefore the according job file gets deleted.

If I view my content in the frontend where I request several versions with different widths for every requested width there will be a job file. Except for the one resolving for the current viewport. Which gets directly generated, therefore deleting the according job file. If I change my viewport the according image gets rendered and the job file deleted. And so on.

Here an example twig snippet.

<picture>
    <source srcset="{{ block.content.heroImage.toImage.clip(2560).url }}" media="(min-width: 1921px)">
    <source srcset="{{ block.content.heroImage.toImage.clip(1920).url }}" media="(min-width: 1536px)">
    ...
    <img src="..." alt="">
</picture>

So far, so good.

If I now change the crop area for that given image all currently existing job files for unrendered images get updated with the new crop information. But there will be no new job files for all image widths which already have a rendered image.

So that results at first, that I don't get an updated preview image for the new crop area in the panel. And in the frontend I also don't get updated images for every image width, which already has been previously requested. But for every not requested image I will get rendered images with the new crop area.

But as soon as all image widths are being generated and there are no job files left, there never will be new image versions with new crop areas. Only if I delete the corresponding image-folder, everything gets of course newly and correctly generated.

I'm still fairly new to Kirby so I'm still hoping I'm missing some basic Kirby concept here regarding media handling.

@mullema
Copy link
Owner

mullema commented Dec 30, 2022

Hi @tpinne, thanks for the detail description. I am still unable to reproduce your issue.

The plugin does consider the image size, clip area size and clip area position for the created filename. An image bird.jpg will be in your media folder like bird-2000x-clip318x635-0x299.jpg (2000px width, clip area size 318x635px at position top 0px and left 299px)

  • When you change the crop area in the panel, are there any errors in your browser console?
  • What are the filenames of the images in your media folder?
  • What is your dev setup? (webserver,...)
  • If you are using other plugins, please remove all and add them one by one to see whether a conflict causes your issues

@mullema mullema self-assigned this Dec 30, 2022
@mullema mullema added the question Further information is requested label Jan 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants