Skip to content

Regenerate with --image_size deletes all other sizes from postmeta #130

Description

@goaround

Bug Report

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

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

Activity

  1. turtlepod commented on Aug 19, 2020

    @turtlepod

    I get same problem.

  2. chesio commented on Nov 13, 2020

    @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...

  3. derweili commented on Feb 8, 2021

    @derweili

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

  4. thomasmb commented on Mar 12, 2021

    @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

  5. petersphilo commented on Mar 17, 2021

    @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..

  6. mjot commented on Mar 17, 2021

    @mjot

    I can confirm this problem.

  7. mklepaczewski commented on Apr 27, 2021

    @mklepaczewski

    Above PR #141 (hopefully) fixes the issue.

  8. marikunt commented on Jun 19, 2021

    @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.

  9. manuhook commented on Jul 1, 2021

    @manuhook

    Thanks @mklepaczewski Is it possible to merge #141 ?

  10. danielbachhuber commented on Aug 3, 2021

    @danielbachhuber
    Member

    I've just run into this issue too!

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

  11. schlessera commented on Aug 5, 2021

    @schlessera
    Member

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

  12. jdelia commented on Oct 1, 2021

    @jdelia

    I've run into the same issue as well.

  13. mklepaczewski commented on Jun 7, 2022

    @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".

  14. screenpartner commented on Oct 27, 2022

    @screenpartner

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

  15. FabienArr commented on Nov 24, 2022

    @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

  16. FabienArr commented on Nov 24, 2022

    @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 :
    image

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

    image

    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

  17. FabienArr commented on Dec 13, 2022

    @FabienArr

    Hi,

    Nobody to help me to try to fix this ?

    Regards

  18. danielbachhuber commented on Dec 13, 2022

    @danielbachhuber
    Member

    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)
    
  19. FabienArr commented on Dec 13, 2022

    @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

  20. wojtekn commented on Dec 14, 2022

    @wojtekn
    Contributor

    @danielbachhuber I'm going to check this one.

  21. wojtekn commented on Dec 15, 2022

    @wojtekn
    Contributor

    @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.

  22. wojtekn commented on Dec 15, 2022

    @wojtekn
    Contributor

    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.

  23. danielbachhuber commented on Dec 16, 2022

    @danielbachhuber
    Member

    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.

  24. added this to the 2.0.16 milestone on Dec 16, 2022
  25. WiredWonder commented on Apr 4, 2024

    @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.

  26. chesio commented on Apr 4, 2024

    @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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions