0

Can I get some clarification as to why images aren't being generated for a certain image style in a view?

Here's my setup; I have an Article content type which allows for a main image to be uploaded. An Article Images image style is applied which crops to the focal point (Module that's installed) and generates the image for the Article node.

I also have a view block that I use on my homepage that displays the 2 most recent articles. What this does is display the title of the article, date and tag over the main image.

In my view settings for this block, I have the Image Style set to Article Homepage - 1075x400 with the Formatter set to URL to image. With a custom template, the block is displayed and what it's supposed to do is set the main image as the background image. If I leave the Image Style set to Article Images in the view, this works perfectly, however, changing it to the above mentioned Article Homepage - 1075x400 ends up generating an error as it says the image doesn't exist.

In one way, this makes sense to me since when I uploaded that image to the article node, it was uploaded only in that certain style so it wouldn't make it available in any other style, would it? Or maybe I'm not seeing this the right way or something in my template is wrong.

Any clarification as to why changing the style for my homepage view ends up displaying nothing would be great.

Below is the template for that homepage block in case my issue is coming from this. Maybe there's something I need to put in here so that any style can take effect?

  {% set bg_url = fields.field_image.content|render|striptags|trim %}
  {% if bg_url %}
  <div class="news-home-item--image d-flex align-items-center justify-content-center" style="background-image: url({{ bg_url }})">
  {% else %}
  <div class="news-home-item--image d-flex align-items-center justify-content-center">
  {% endif %}
  </div>
  <div class="news-home-item--info">
    <h5>{{ fields.title.content }}</h5>
    <div class="news-home-item--info__meta">
      <div class="news-home-item--info__meta-date float-lg-left">{{ fields.created.content }}</div>
      {% if fields.field_tags.content|render %}
      <div class="news-home-item--info__meta-tags float-lg-right">{{ fields.field_tags.content}}</div>
      {% endif %}
    </div>
  </div>

Update 1:

So, I think I might be onto what's happening here. I think it comes down to me using the twig filters in my theme file. If I remove |striptags|trim it generates the image style, however, it won't actually show up in my dev site, in which I'm developing all this, due to the fact that without those other two filters, this is what ends up printing out in the style class:

style="background-image: url(
<!-- THEME DEBUG -->
<!-- THEME HOOK: 'views_view_field' -->
<!-- BEGIN OUTPUT from 'themes/custom/scc/templates/views/views-view-field.html.twig' -->
/sites/default/files/styles/articles_homepage_1075x400/public/articles/2019-05/image.jpg?h=287a81f3&amp;itok=aMmcvNDO
<!-- END OUTPUT from 'themes/custom/scc/templates/views/views-view-field.html.twig' -->
)"

After removing those filters in the file, letting it generate the style, then putting the other two filters back, the image does show up. I'm assuming those filters are hindering the creation for some reason. It may end up not being a problem if I leave those filters out. Sure it won't show up properly on my dev site but I'm going to assume it'll work properly on dev.

Update 2:

Removing |render|striptags|trim from my field_image ended up making this work as intended on my production website. It still remains broken on my dev site though due to it spitting out that extra code.

  • it was uploaded only in that certain style so it wouldn't make it available in any other style, would it? The original is always uploaded - styles (derivatives) are generated on-the-fly, when a predictable URL is requested for the first time – Clive Sep 25 at 18:26
  • @Clive So I thought that too but my issue made me sway away from that conclusion. So, do you have any idea as to why when I change the Image Style for the block view to anything other than Article Images, that the background image isn't being generated then? – ACanadianCoder Sep 25 at 18:32
  • @ACanadianCoder Are you sure the original image still exists and is accessible? It sounds like the image can't be accessed and processed. – enzipher Sep 26 at 4:12
  • @enzipher yup, it's still easily accessed. All permissions to files/directories are as should be too. – ACanadianCoder Sep 26 at 13:46
  • Check above to see an update as to what I think may be happening. – ACanadianCoder Sep 26 at 14:17
0

Are you sure that image style still exists? Views doesn't like when you delete/change image styles that it is already using. A remedy might be to delete that field from your view, and reset it (with the confirmed good image style?)

Maybe your image style was formed improperly?

(Are your view blocks restricted to not show on the home page (block admin?)

  • Yes, the style exists. I ended up deleting the field from the view and then brought it back in while also creating a new image style to make sure it wasn't that either. When I save, the same issue arises. It ends up linking to a file that doesn't exist: /sites/default/files/styles/articles_homepage_1075x400/public/articles/2019-05/name-of-file.jpg?h=287a81f3&amp;itok=aMmcvNDO. It doesn't make sense to me? The original style that's applied, does however, have the proper image /sites/default/files/styles/article_images/public/articles/2019-05/name-of-file.jpg?h=287a81f3&amp;itok=aMmcvNDO – ACanadianCoder Sep 25 at 19:28
  • You may want to check the Drupal watchdog logs or server's php logs. Sometimes, an image style derivative can't be generated because of memory allocation issues, especially when the original image is a large filesize. – Anson W Han Sep 26 at 2:25
  • @AnsonWHan I'm seeing no issues at all in the logs. This is quite a frustrating situation, however, I've added an update to the main post as to what I think may be happening. – ACanadianCoder Sep 26 at 14:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.