Image size not set with retina disabled

Could this help?

Hi,
From the post you mention, I understand – and confirm – that everything is fine with Retina enabled.
But I do not wand Retina, and when it is disabled the upload of images fails : image size is not set (no image data).
Since I would like to disable Retina (because of the numerous files), I would appreciate a fix.

This is a bug and nobody’s been able to pin it down yet.

Could I ask why you don’t want retina support? Retina support will deliver sharper images to people who have retina devices—a lot of the latest phones, for example. Without retina support, images will look blurry on those devices.

It’s a genuine question: One way to get rid of the bug that I’ve suggested is to simply make retina-support standard, but I’m interested in knowing why anyone would not want this.

@electricfeet – can’t argue that retina screens are prevalent on new devices but that still leaves a majority of the installed base without retina screens, as well as many entry-level new devices. I don’t know the stats but a chum in the industry reckons retina currently accounts for 20% (and rising) of all screens.

If it is the case that WP loads retina-resolution images whether they are needed or not, then the majority of viewers will suffer an overhead in terms of site loading time for benefits which are seen by a minority. An informed view here.

Arguably too, retina is of questionable value to many phone users, given that the screen is so small and that viewers would need a) 20:20 eyesight and b) the screen unnaturally close to their eye so see the full benefit. Interesting review of current display technologies here.

Ah, thanks Chappie. I hadn’t realised that it loads both.

Re the 20:20. Those with the leading-edge retina devices will demographically be those with the best eyesight ?? (And it’s not so leading edge any more, now that we have cheaper 4K screens coming through.)

Doing some more digging, this seems to be a WordPress bug, not a Customizr bug. On the second page of this post, there’s a WP hack:

I got the same problem after upgrading WP from 3.6.1 to 3.8.1.
It looks like there was a change in wp-includes/media.php function wp_constrain_dimensions(): width and height is set to max(1, $current_<w/h> * $ratio). I have changed:
$w = max ( 1, intval( $current_width * $ratio ) );
$h = max ( 1, intval( $current_height * $ratio ) );
to
$w = intval( $current_width * $ratio );
$h = intval( $current_height * $ratio );
as it was in v3.6.
It’s a hack rather than fix, so do it at your own risk.

I don’t see how it works because the 3.8 code looks fine to me. I could imagine that the new code might be bringing out another bug somewhere else, though—for instance if the image size was in some way discarded previously as it was malformed or unobtainable, but constraining it to a max fixes it totally and incorrectly to 1px.

Alternatively, the first page of that post says it might be a permissions issue. Can anyone investigate this permissions issue?

Maybe it’s a combination of permissions (which refuses to give you the image size info, yet allows you to display the image) and the new code (which in the absence of the image size info constrains the image to 1px x 1 px).

Sounds like a plausible scenario. Any WordPress image gurus out there?

Mods: any chance you could raise this to an image specialist’s attention?

(And for completeness, if a WP image guru does pass by, here’s a previous troubleshooting post on the problem)

Apologies: that was a post that was prematurely closed. The correct troubleshooting post is here.

Side note and unrelated to this topic: please do not tag topics as modlook unless there’s abuse, spam or something that needs fixing such as broken formatting or worse posted malware.

ElectricFeet, that stuff is way above my pay grade but I hope a fix can be found. I agree with @manu-pb that it’s a nonsense to be forced to enable the retina option.

FWIW, as I have mentioned before, it is possible to fix the in-page display problem where an apparently corrupted image is manually inserted and therefore its dimensions are editable in HTML. Simply altering the 1 x 1 pixel size to the correct size of the image forces it to display properly on the page — albeit its library preview thumbnail remains broken.

Jan: Apologies Jan, won’t do it again.

Chappie: I realize that manually changing the images patches things up in posts/pages, but lots of people have this problem in their featured images, which cannot be patched up easily. I’m determined to get to the bottom of it one day, or cheer loudly when someone else does…

Manu-PB, Chappie, I can confirm that the hack:

In wp-includes/media.php function wp_constrain_dimensions(): change:

$w = max ( 1, intval( $current_width * $ratio ) );
$h = max ( 1, intval( $current_height * $ratio ) );

to

$w = intval( $current_width * $ratio );
$h = intval( $current_height * $ratio );

(as it was in v3.6)

does fix the problem (I have the problem on my local install when retina is off).

However, the problem itself is rare, so to get it fixed permanently, we need to find out under what circumstance it happens. If someone can tell me what tests to do, I can try them on my local install.

Anyone?

Thanks all for these information.
@electricfeet, I’m not ready to modify WP core files, so until the problem is fixed I continue tu use Retina.

Well, I’ve done a little more study on this. The change above seems to “correct” the problem in the media library, but does not resolve the underlying issue.

The image is coming through at 0px x 0px. This is set when the image is uploaded. Something somewhere is stopping it coming through at the proper size. (This is where I’ll look next)

The reason that changing the code above seems to help is as follows: The code in question is part of a function that (among other things) defines the size of the thumbnail image to display in the media library. As the image is coming through at 0px x 0px, the “max” function in the code above changes it to 1px x 1px, and that’s why you can only see a 1px dot in the media library. If you take the “max” function out as the other poster suggested, then the image size (which is still 0px x 0px) is not reset to 1px x 1px. WP then displays the image properly—probably because there’s some error correction going on elsewhere (something along the lines of “if the image is 0px x 0px, then it’s clearly wrong, so ignore it and display the whole thing”).

Anyway, bottom line is that it’s not WP code that’s in error, but something that’s happening on the upload.

BTW, for anyone else who wondered (like I did) how to see what’s in a variable — in a very quick and dirty way — this line of code does it:
echo '<pre>' . print_r($current_width, true) . '</pre>';
(substituting $current_width with whatever variable you want to see).

@electricfeet – following with interest. Surely the answer lies in the difference between the retina-enabled upload function and the retina-disabled upload function?

Or between the retina-disabled upload function and the standard 2013 upload function when all images displayed fine?

Hi Chappie. Yes, that will be where the problem lies, but I was trying to find out why that hack seemed to solve the problem.

Further investigations this evening (exporting my database from phpadmin — all new territory for me) show that for non-retina images, the metadata is not being saved.

Will keep you posted…

Well, that was quicker than I thought. Once I’d found there was no metadata, I could do a better search on Google. Specifically this post, where someone has an issue with loss of _wp_attachment_metadata. In his case, the poster of the question is using a filter, and the answer is telling him that he should return some data with the return statement. In Customizr’s case, we have this function:

/**
   * This function handles the support for high resolution devices
   *
   * @hook wp_generate_attachment_metadata (10 ,2)
   * @package Customizr
   * @since Customizr 3.0.15
   * @credits https://wp.tutsplus.com/author/chrisbavota/
   */
    function tc_add_retina_support($metadata, $attachment_id) {
      //checks if retina is enabled in options
      if ( 0 == tc__f( '__get_option' , 'tc_retina_support' ) )
        return;

      foreach ( $metadata as $key => $value ) {
          if ( is_array( $value ) ) {
              foreach ( $value as $image => $attr ) {
                  if ( is_array( $attr ) )
                      $this -> tc_create_retina_images( get_attached_file( $attachment_id ), $attr['width'], $attr['height'], true );
              }
          }
      }
      return $metadata;
    }//end of tc_retina_support

Following the same logic—that we should return some data—even though I shouldn’t necessarily follow the same logic as it’s not a filter, I played around with using this for the if statement instead:

if ( 0 == tc__f( '__get_option' , 'tc_retina_support' ) )
        return $metadata;

…and whaddayaknow? It seems to work. Could this be a case of the iffy if? Can you try it Chappie?

@nikeo: is this the bug fix we’ve all been looking for or is it just another case of two wrongs making a right somewhere along the way?