UPDATE: After investigting this I have concluded that the problem concerns ALL new image styles, but "old" ones are still working. Old ones are the built-in (e.g. thumbnail) and one image style of my own.

Also: I use the patch to create the in core/modules/image/image.module, if it is a factor.

I have run a really strange problem: New image styles I have created don't work on one server (of course the production). I have tried to re-create the image styles, flush the caches etc ad nauseaum, but still the same thing. I have an exactly similar (apart the dimensions) image style that works just fine. The file permissions and owners are the replica of the working one...

The effect is Focal Point Scale and Crop (working dimensions 550 x 250, non working 1290 x 400). And in the development it's working just fine.

Any ideas, anyone?

wbr hank

  • This is a very wild guess, but maybe it is blocked by an ad blocker? I've once wasted hours debugging an image style just because of an overly broad filename blacklist from an ad blocker.
    – Hudri
    Feb 9, 2018 at 7:59
  • I'd say not, because the image style isn't even generated on the server. And I have used it with different browsers with equal sucess (or loss of it)
    – hank
    Feb 9, 2018 at 8:02

2 Answers 2


How large is the original image? It could be your production server php memory limit is being reached. Have you checked the error logs on the server?

Drupal needs to put the original image into memory to create the styled version so if this image is quite large it can cause memory to run out. Especially if you're on a cheap hosting

  • Thanks for the comment. The memory limits were 256M and 128 MB (dev and prod) which seem big enough to me. Just to be sure, I increased the memory limit to 256MB also on prod, no change. One of the images is 4.3MB (byte size), so there should be plenty of reserve. Also, shouldn't that also affect thumbnail image style which is generated without problems. And no, we do pay quite a lot for the hosting :P
    – hank
    Feb 9, 2018 at 9:29
  • And regarding the server logs: nothing that would strike me (nginx: missing image messages (the images are on the slide show, so it generates those quite a lot). php-fpm log is clean in this regard (some of my own programming bugs every now and then, but otherwise nothing). Drupal log also clean
    – hank
    Feb 9, 2018 at 9:34
  • My next guess would be file permissions maybe? Are your images stored in a folder within /sites/default/files? that folder might not have the correct permissions. Or its not got the permissions to create new folder within sites/default/files/styles/stlyename folder
    – Leigh
    Feb 9, 2018 at 10:20
  • That was my first assumption. But, it has 100% same owner (php-fpm) and same permissions (775). I have even tried with 777 but no change. If I flush the image type it generates the publi directory plus core-directory below, but no month directory. With another image style created by me things work right. Really intimidating
    – hank
    Feb 9, 2018 at 10:39
  • And yes, the files live in /sites/default/files/public/YYYY-MM directory
    – hank
    Feb 9, 2018 at 10:40

I finally got it. The problem lied in site nginx conf file. The following block was

 location ~* \.(?:ico|css|js|gif|jpe?g|png)$ {
     expires max;
     # add_header Pragma public;
     # add_header Cache-Control "public, must-revalidate, proxy-revalidate";

too early in my nginx file. After moving it to the end of the file (last entry in the server block), the problem vanished into thin air. Damn, one whole working day spent in vain :/ But at least, now the problem has gone away.



Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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