• Thanks for this awesome plugin! It’s working really smoothly on my staging site and I think I’ll be using it A LOT.

    One problem I’ve found is that it doesn’t work with the new Image Editor in wordpress. After cropping and image and saving it, a new file isn’t uploaded to s3, but the path is still replaced.

    Looks like there’s a filter we could hook into to trigger a save: wp_save_image_editor_file

    If that could be implemented in an upcoming version, or if anyone has input for a workaround for me for now, that would be much appreciated!

    Thanks again.

    https://wordpress.org/plugins/amazon-s3-and-cloudfront/

Viewing 10 replies - 1 through 10 (of 10 total)
  • Thread Starter bigmikestudios

    (@bigmikestudios)

    Tried this, but to no avail. Am I on the right track?

    function cur_save_image_editor_file( $saved, $filename, $image, $mime_type, $post_id )
    {
      wp_generate_attachment_metadata( $post_id, $filename );
      return ($saved);
    }
    add_filter( 'wp_save_image_editor_file', 'cur_save_image_editor_file', 10 , 5 );
    Thread Starter bigmikestudios

    (@bigmikestudios)

    Needed to add the save within the function. That _mostly_ works, but it seems that the amazonS3_info meta field is always lagging one version behind. looking into that forthwith…

    function cur_save_image_editor_file( $saved, $filename, $image, $mime_type, $post_id )
    {
    
      $save_attempt = $image->save( $filename, $mime_type );
      wp_generate_attachment_metadata( $post_id, $filename );
      if ( null !== $saved )
        return $saved;
      return $save_attempt;
    
    }
    
    add_filter( 'wp_save_image_editor_file', 'cur_save_image_editor_file', 10 , 5 );
    Thread Starter bigmikestudios

    (@bigmikestudios)

    Got it working, but I needed to hack the plugin. I suggest this should possibly be included in the next release, either that or perhaps a hook or filter could be implemented for me to call.

    at line 132 in amazon-s3-and-cloudfront.php, within the wp_generate_attachment_metadata function:

    //$file_path = get_attached_file( $post_id, true );
    $upload_dir = wp_upload_dir();
    $upload_path = $upload_dir['basedir'];
    $file_path = $upload_path."/".$data['file'];

    This basically allows the plugin to use the name of the CURRENT incarnation of the file, otherwise it finds the filename of the last incarnation of the file (when using the image editor).

    I tried this solution and it kind of works, but it creates and saves a new batch of files based on the resized file name, rather than only saving the one full-size resized image and deleting the old full-size image. With the exception of the new resized full-size image, WordPress does not use the new resized images when inserting them into posts.

    Is there a solution for this?

    Thread Starter bigmikestudios

    (@bigmikestudios)

    I found the same thing – I think I’ve now got it working with the hack above implemented and this added to the functions file:

    function cur_save_image_editor_file( $saved, $filename, $image, $mime_type, $post_id )
    {
      // if we've already run this, don't do it again...
      global $cur_has_saved;
      if ($cur_has_saved) return $saved;
    
      $save_attempt = $image->save( $filename, $mime_type );
      wp_generate_attachment_metadata( $post_id, $filename );
      if ( null !== $saved )
        return $saved;
      $cur_has_saved = true;
      return $save_attempt;
    }
    add_filter( 'wp_save_image_editor_file', 'cur_save_image_editor_file', 10 , 5 );
    
    function cur_update_attached_file( $file, $attachment_id ) {
      // if we've already run this, don't do it again...
      global $cur_has_saved;
      if ($cur_has_saved) return $file;
    
      $check = wp_check_filetype( $file );
      $mimetype = $check['type'];
    
      $image =  wp_get_image_editor($file, $mimetype);
      $save_attempt = $image->save( $file, $mime_type );
    
      wp_generate_attachment_metadata( $attachment_id, $file );
      return $file;
    }
    add_filter( 'update_attached_file', 'cur_update_attached_file', 10 , 2 );
    Thread Starter bigmikestudios

    (@bigmikestudios)

    An edit to the above – the line $image = wp_get_image_editor($file, $mimetype); shouldn’t include the $mimetype argument. Instead, the whole thing should look like this:

    function cur_save_image_editor_file( $saved, $filename, $image, $mime_type, $post_id )
    {
      // if we've already run this, don't do it again...
      global $cur_has_saved;
      if ($cur_has_saved) return $saved;
    
      $save_attempt = $image->save( $filename, $mime_type );
      wp_generate_attachment_metadata( $post_id, $filename );
      if ( null !== $saved )
        return $saved;
      $cur_has_saved = true;
      return $save_attempt;
    }
    add_filter( 'wp_save_image_editor_file', 'cur_save_image_editor_file', 10 , 5 );
    
    function cur_update_attached_file( $file, $attachment_id ) {
      // if we've already run this, don't do it again...
      global $cur_has_saved;
      if ($cur_has_saved) return $file;
    
      $check = wp_check_filetype( $file );
      $mimetype = $check['type'];
    
      $image =  wp_get_image_editor($file);
      $save_attempt = $image->save( $file, $mime_type );
    
      wp_generate_attachment_metadata( $attachment_id, $file );
      return $file;
    }
    add_filter( 'update_attached_file', 'cur_update_attached_file', 10 , 2 );

    Thanks for your response bigmikestudios. I tried this solution and it caused the upload to fail:

    Warning: fopen(C:\wamp\www\editorialhub/wp-content/uploads/): failed to open stream: No such file or directory in C:\wamp\www\editorialhub\wp-content\plugins\amazon-web-services\vendor\aws\Aws\Common\Client\UploadBodyListener.php on line 83

    The files go to S3, but the thumbnail does not show, and the edit screen says “Image data does not exist. Please re-upload the image.”

    Any help would be greatly appreciated. Thanks.

    Hey @bigmike

    Yea the plugin is great but also has no support for the large medium and thumbnail files… i.e you can’t upload one photo and have all the versions made for you and put into s3 and then you chose which one you want…

    I know you were working on when you edited a pictured… But i think this is along the same thread… Great work!

    Would be awesome to have all this stuff implemented in the next release! Then users really could use the photos on WP just like normal even though everything is on S3 and delivered by cloud front 🙂

    unfortunately the “cur_update_attached_file” breaks the functionality for me. So I had to remove it.

    However, the “cur_save_image_editor_file” does work.
    and here is what I have in amazon-s3-and-coudfront/classes/amazon-s3-and-cloudfront.php

    $upload_dir = wp_upload_dir();
    $upload_path = $upload_dir['basedir'];
    $file_path = $upload_path."/".$data['file'];
    
    if(!file_exists($file_path))
    {
        $file_path = get_attached_file( $post_id, true );
    }

    It does work however, the image shown in the Admin panel after the edit doesn’t always show the new edits, but it does work on the front end after I save the post. Also the revert Image back doesn’t seem to work either, but that is not used as often.

    I’m trying to use the S3 plugin and came across the same edit image bug. I tried just adding the code y’all mentioned, but I’m having trouble getting it to work. I know where to paste the code that Gravitate mentions, but I can’t figure out if I am putting the code that bigmike mentioned in the right place. Is it supposed to go into a new file?

    Edit: Silly me. Syntax errors and stuff. Got it, thanks y’all for this update!

Viewing 10 replies - 1 through 10 (of 10 total)
  • The topic ‘Feature request – Update S3 after image editor is used’ is closed to new replies.