Regenerate with --image_size deletes all other sizes from postmeta

[goaround]

Bug Report

--- ✅ If you are in the correct location now... --->

• Yes, I reviewed the contribution guidelines.
• Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior

I changed the height/width of an image size and tried to regenerate only the thumbnails for this specific size with--image_size=medium Here my full command:

wp media regenerate --image_size=medium --skip-delete --only-missing

After the regeneration, the REST API showed only medium under sizes. I checked the postmeta database table for the _wp_attachment_metadata and it seems like, that _wp_attachment_metadata now only contains the regenerated size, all other are gone:

 'sizes' => 
  array (
    'medium' => 
    array (
      'file' => 'Lissabon-Strassenbahnen-300x214.jpg',
      'width' => 300,
      'height' => 214,
      'mime-type' => 'image/jpeg',
    ),
  ),

If I run the command without --image_size its fine again:

wp media regenerate --skip-delete --only-missing

'sizes' => 
  array (
    'medium' => 
    array (
      'file' => 'Lissabon-Strassenbahnen-300x214.jpg',
      'width' => 300,
      'height' => 214,
      'mime-type' => 'image/jpeg',
    ),
    'thumbnail' => 
    array (
      'file' => 'Lissabon-Strassenbahnen-150x150.jpg',
      'width' => 150,
      'height' => 150,
      'mime-type' => 'image/jpeg',
    ),
    'medium_large' => 
    array (
      'file' => 'Lissabon-Strassenbahnen-768x548.jpg',
      'width' => 768,
      'height' => 548,
      'mime-type' => 'image/jpeg',
    ),
    'logo' => 
    array (
      'file' => 'Lissabon-Strassenbahnen-180x128.jpg',
      'width' => 180,
      'height' => 128,
      'mime-type' => 'image/jpeg',
    ),
  ),

Describe how other contributors can replicate this bug

1. Upload an Image
2. Change the size settings for medium in WordPress
3. Regenrate the thumbnails with --image_size=medium
4. Check postmeta table for _wp_attachment_metadata

Describe what you would expect as the correct outcome

I would expect, that all other sizes would still be in the metadata, only the specific size changed

Let us know what environment you are running this on

OS:	Darwin 19.4.0 Darwin Kernel Version 19.4.0: Wed Mar  4 22:28:40 PST 2020; root:xnu-6153.101.6~15/RELEASE_X86_64 x86_64
Shell:	/bin/zsh
PHP binary:	/usr/local/Cellar/php/7.4.0/bin/php
PHP version:	7.4.0
php.ini used:	/usr/local/etc/php/7.4/php.ini
WP-CLI root dir:	phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:	phar://wp-cli.phar/vendor
WP_CLI phar path:	/Users/johanneskinast/Valet Sites/travel-dealz
WP-CLI packages dir:	
WP-CLI global config:	
WP-CLI project config:	
WP-CLI version:	2.4.0

[turtlepod]

I get same problem.

[chesio]

I think I've stumbled upon the same problem. In my case I've noticed that responsive images stopped working after I regenerated a particular image size. Since the other sizes are not included in meta, wp_calculate_image_srcset only outputs full and the recently regenerated image size...

[derweili]

I get the same error.
The other image sizes are still on the server as image files but removed from the post metadata.

[thomasmb]

Can confirm. Here is an example:

Start with image that already is correct. Now, if you run wp media regenerate IMAGEID --image_size=thumbnail, the _wp_attachment_metadata sizes array will only contain the thumbnail image size.

If you use the --only-missing option, it will only work if in fact you are missing that image size.

Running wp media regenerate IMAGEID --only-missing will restore the sizes array

[petersphilo]

i have had the same issue..
also, this issue seems to be the same thing:
#121

i can confirm that running the command
media regenerate --only-missing
resolved all issues
Thank You..

[mjot]

I can confirm this problem.

[mklepaczewski]

Above PR #141 (hopefully) fixes the issue.

[marikunt]

I can confirm this issue too. The workaround without image_size and --only-missing does not work for me. All image sizes will be recreated on disk again with this workaround. I tried also the workaround from thomasmb, but this does the same. Not only the array will be touched, also the files on disk will be recreated.

[manuhook]

Thanks @mklepaczewski Is it possible to merge #141 ?

[danielbachhuber]

I've just run into this issue too!

@schlessera Would it be possible to get this into v2.5.1?

[schlessera]

@danielbachhuber Yes, I can look into including that. The current PR is still missing tests, though.

[jdelia]

I've run into the same issue as well.

[mklepaczewski]

Unbelievable. I've just got over 1 million image sizes unregistered due to this bug. Can this get fixed please????

Please note that I'm not part of the wp-cli team, I merely added the pull request to fix the issue.

Yes, you can fix it. You can hire someone on Upwork to write missing Behat tests and push the fix forward. Or ask your in-house devs to do it. Surely it's cheaper than losing another 1 million images due to the issue.

I apologize for being snarky, but... Multiple people reported the issue, some of you must have developers on the payroll. No one decided "hey, maybe let's spend 2-3 hours of our development time on pushing forward the issue that is so irritating to us".

[screenpartner]

Has anyone found a method of populating the missing meta data without running regenerate command for all images?

[FabienArr]

Hello,

I have the same problem, i would debug this part but i don't known how. I have read this : https://make.wordpress.org/cli/handbook/contributions/pull-requests/#setting-up
But when i tried the point 5 : vendor/bin/wp --info i have error, i'm on windows.
I just want do debug the class Media_Command with my Wordpress Database.
Tell me how i can do that easily to try to solve this problem ?

Regards

[FabienArr]

With success I do some tests, but i didn't fix the problem but it can help, i can't spend all my time on this bug but :
If you go in the the function regenerate there is :

The function process_regeneration take the --image_size parameter but the filter is put in the previously function.
And what i find is here :

https://developer.wordpress.org/reference/functions/wp_generate_attachment_metadata/
call https://developer.wordpress.org/reference/functions/wp_create_image_subsizes/

1. I don't know what are the impact if we remove the image filter in regenerate ?
2. I think it's better to test if metadata already exists, if it's the case why genarate the metadata and update them just after ?

When i will get more time i could try to fix it, but if someone can look at this first ?

Regards

[FabienArr]

Hi,

Nobody to help me to try to fix this ?

Regards

[danielbachhuber]

Pulling in the diff from #141: https://gist.github.com/danielbachhuber/9ce0653b91faa5151882b149fca38d02

It doesn't seem like its tests currently pass, however...

$ composer behat -- --tags @daniel
> run-behat-tests '--tags' '@daniel'
..............................F----------------------

--- Failed steps:

001 Scenario: Regenerate all images default behavior                            # features/media-regenerate.feature:16
      And the wp-content/uploads/white-150-square-150x150.jpg file should exist # features/media-regenerate.feature:62
        /var/folders/6t/fzd50mwd57766jb0qdj2vl100000gn/T/wp-cli-test-run--63989629586e79.31321936/wp-content/uploads/white-150-square-150x150.jpg doesn't exist. (Exception)

[FabienArr]

OK thanks, when i will terminate my other project, i will try to do some modifications on this code, but could you confirm what i found please ?

Regards

[wojtekn]

@danielbachhuber I'm going to check this one.

[wojtekn]

@danielbachhuber I've opened a PR for the failing test: #169

The tests from https://gist.github.com/danielbachhuber/9ce0653b91faa5151882b149fca38d02 succeed when I apply this diff on top of my PR. I will review the fix more and will add a separate PR for that.

[wojtekn]

I've created a PR (#170) with the fix from the linked gist and it fixes the issue - Behat tests go through, I tested it manually in stand-alone WP as well.

[danielbachhuber]

For posterity, it looks like this bug might've been introduced with WordPress 5.3 (November 2019): WordPress/wordpress-develop@ca84ae5

Specifically, wp_generate_attachment_metadata() started calling update_post_meta(), which caused our failed state of incorrect data stored.

[WiredWonder]

Is there a chance this has been reintroduced? I have had meta mysteriously go missing after a --only-missing --image_size. Running 2.6.0.

[chesio]

Running 2.6.0.

Update your WP-CLI instance. Current version is 2.10, version 2.6.0 has been released more than two years ago...