4

My settings are,

allow_insecure_derivatives: true
suppress_itok_output: false

Editing the itok token for the image src works at the browser level.

Does anyone know what causes the issue and a fix for it?

Notes :

  1. When I hit CTRL+SHIFT+R in the browser the imagestyle images reappear. So the issues seems to be image is not present for the first time and browser is caching it.
  2. The actual image can be accessed even for the first time without any issues. The issue is only with the image style images.
  3. When I look at the actual image in the files folder, I see that there is an additional image with _0 attached to it. So looks like when the image is uploaded for the first time, it is assuming there is a duplicate and creating a new image. But still not sure why it would cause this issue.
  • your server does not have permission to write to the folder where you're trying to save it. – No Sssweat Jul 25 '16 at 10:12
  • if you're on ubuntu, do this in your console go to your drupal default folder cd /var/www/drupal/sites/default and then sudo chown www-data -R files – No Sssweat Jul 25 '16 at 10:14
  • I ve done this before(gave 777 to styles folder in /var/www/drupal/sites/default/files ) but still it seems broken..the image gets rendered but the browsers shows it as broken. when i remove or alter itok token image appears good. – Sandeep Reddy Jul 25 '16 at 15:15
  • For your files folder, what do you have as owner/group? – No Sssweat Aug 13 '16 at 9:14
  • www-data as owner and group – Sandeep Reddy Aug 13 '16 at 11:52
2

We had similar issue in our project might be same please check this link.

https://www.drupal.org/node/2195311

1
+125

Without access to the environment, it's going to be near impossible to know what's going on.

Something between the upload AJAX request, the image form element render, and the image style request, is causing the upload/render process to break. With that known, you can try debugging through key parts of this process to determine where key assumptions break:

  1. file_managed_file_save_upload(): Is the file being saved correctly at this point? Is there anything in the about the file system/configuration that creates a duplicate file?
  2. ImageStyle::buildUrl(): After the file is saved and the form element is being rendered, is the style URL being generated correctly? Is the token correct? Is the file used the same as the one previously saved?
  3. ImageStyleDownloadController::deliver(): Upon browser update, is the image payload delivery working correctly? Is this code being triggered (e.g. not proxied through some CDN)? Can it access the same file that was previously saved?

You can use Devel functions (e.g. dpm(debug_backtrace())), standard PHP debugging functions (e.g. debug_print_backtrace()), or whatever else your favorite IDE might provide you (e.g. XDebug/DBGp integration) to inspect state during these key functions to get to the bottom of the problem.

0

Are you using File (Field) Paths?

If yes, this is the module which is disturbing the thumbnail generation in the form.

  • Nope I'm not using drupal.org/project/filefield_paths.. – Sandeep Reddy Jul 25 '16 at 15:13
  • are you private or public? – Baud Jul 26 '16 at 0:54
  • I m uploading to public! – Sandeep Reddy Jul 27 '16 at 7:32
  • If it is sure that image is in public:// it is fine (on the other hand you should use Imagecache External). Two questions: is it only with IE? Could you provide the error (is it 404)? And one idea: disable clean URL and check again. – Baud Jul 27 '16 at 14:23
0

Same happened to me while I was on maintenance mode, Images styles was not generated, images not being loaded (404), once I turned maintenance off, it worked fine.

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.