Add image replacement feature

[hugosolar]

Description of the Change

Extending our previous feature to replace PDFs in #220
Now I'm adding the feature to replace images.
The criteria to replace images is based on the source image, we're using it as a reference to handle metadata
The process is to loop over the registered sizes for the image and find the image with the nearest size from the replacement and replace the correspondent image size.
This approach seems to be the one used by known plugins like Enable Media replace

The workflow we're following is

• Selecting an image to be replaced
• Click "Replace this media"
• Select an image to replace
• The new image is going to be uploaded to Azure
• After that if "Replace media" is clicked:
  • Replacing the main image
  • Loop through the source sizes in _wp_attached_file and copy those over to replace the location finding the closest size possible
  • Then we delete the newest attachment

https://drive.google.com/file/d/1vPuk_cYUdWrlGBY3bUkjxWTpZeYr-BTG/view

This plugin also fixes #184 ensuring we're processing an array with array_flip otherwise returning a WP_Error object
closes #182 #130

How to test the Change

• Clone this branch to your local environment
• Follow the workflow in the video: https://drive.google.com/file/d/1vPuk_cYUdWrlGBY3bUkjxWTpZeYr-BTG/view

Changelog Entry

Added - New feature
Feature to replace images at the blob storage level

Fixed - Bug fix
Fixed bug relate to the use of array_flip and not ensuring it was an actual arrat

Credits

Props @hugosolar

Checklist:

• I agree to follow this project's Code of Conduct.
• I have updated the documentation accordingly.
• I have added tests to cover my change.
• All new and existing tests pass.

[jeffpaul]

@rickalee looking to you / your team for review / approval here

[rickalee]

@hugosolar Approved. Looks great. Any considerations with Cache and configuration we need to document for other users of public plugin?

[hugosolar]

@rickalee I've addressed cache issue by setting the blob properties cache to 30 segs

[hugosolar]

@jeffpaul the e2e error seems to come directly from wp-env

ERROR: for f505fb82f2963a5299b2972f47ad8834_mysql_1  'ContainerConfig'
Creating f505fb82f2963a5299b2972f47ad8834_tests-wordpress_1 ... done
Creating f505fb82f2963a5299b2972f47ad8834_tests-cli_1       ... 
Creating f505fb82f2963a5299b2972f47ad8834_tests-cli_1       ... done
[2378] Failed to execute script docker-compose

ERROR: for mysql  'ContainerConfig'

have you seen this before?
actually, we're using @wordpress/env 8.7.0 in the plugin and it's currently at 2.0.0 I can try to update that library and see how it goes

[dkotter]

@hugosolar Yes, updating @wordpress/env to the latest should fix that particular issue, as we've ran across this on a few other plugins. Seems GitHub updated the ubuntu-latest image and this causes issues with wp-env if it's not running the latest

[hugosolar]

@dkotter @jeffpaul I've updated wp-env and I can see the build is passing now
now it's failing on cypress tests since I'm pushing from a forked repository and secrets aren't available to accomplish those tests.
This has been fixed on my other PRs
let me know how can I help with this

[dkotter]

Wondering if we need to be more defensive here? For both $source_sizes and $target_sizes, will these always be arrays and will the keys we want always exist? Or do we need to check for those before proceeding?

[hugosolar]

@dkotter since this array is made above, it stores WordPress default _wp_attachment_metadata so it's always expected to exist if it's a valid attachment. Although I agree with the extra check because we never knows if we're about to handle an invalid attachment or a similar situation.
I've added some extra checks to bail early

[jeffpaul]

Note I'm holding for @rickalee's review before merging here