• Resolved fwdcar

    (@fwdcar)


    Hi,

    When using meta slider with cropping, it adds another image to the gallery with the cropped size appended to the file name. The WP Offload S3 plugin does not see this add happening, and therefore does not copy the file to S3. This is solved by going into the gallery and manually copying the file to S3. But there is still another problem – the S3 plugin will only use the new image if it’s in the ‘sizes’ array of _wp_attachment_metadata in the wp_postmeta table. So, what I did was add the following code to metaslider.imagehelper.class.php in the resize_image() function at line 340 just before the return of the URL:

    /////
            $sizes = get_post_meta( $this->id, '_wp_attachment_metadata', true );
            unset($saved['path']);
            $sizes['sizes']["meta-slider-resized-{$dest_size['width']}x{$dest_size['height']}"]=$saved;
            update_post_meta( $this->id, '_wp_attachment_metadata', $sizes);
    /////
    return $url;
    }
    

    This is the function that adds the new image to the galley, and also adds the image to the ‘_wp_attachment_backup_sizes’ meta, but, fails to also add it to the ‘sizes’ array of _wp_attachment_metadata in the wp_postmeta table.

    I hate modifying plugin code. Would it be possible to add a hook at this location so that we can jump in and do something like this after the new image is added? Or, add the code necessary to add the size of the new image to the sizes array in the meta?

    Thank you.
    FW

Viewing 12 replies - 1 through 12 (of 12 total)
  • Thread Starter fwdcar

    (@fwdcar)

    Any comments on this post? Was still wondering if a hook could be added at gallery add time.

    Thanks.

    Thread Starter fwdcar

    (@fwdcar)

    Hello,

    No interest at all in this enhancement? It wouldn’t take much…it’s only a few lines of code.

    Thanks.

    matchalabs

    (@matchalabs)

    Hi fwdcar,

    Apologies for the radio silence on this end.

    I haven’t been able to test your change (I really need to thoroughly understand the code, and if it may have any consequences, before adding it to the plugin), but in 3.5 we added a new action/hook which should let you execute your code after the image has been resized. Please can you take a look here for details on the change:

    https://plugins.trac.wordpress.org/changeset/1613401/

    Regards,
    Tom

    • This reply was modified 7 years ago by matchalabs.
    Thread Starter fwdcar

    (@fwdcar)

    Hey Tom,

    No worries, and I fully understand the need for caution with regards to adding/changing code. I believe the hook will work for me, and it is definitely better than changing the source.

    As far as a better understanding the code, so that you can make the change permanent, here is my pitch:

    One of the things that metaslider does when creating a new image (as a result of cropping), is to add the new image meta info to the _wp_attachment_backup_sizes column of the wp_postmeta table. This happens at lines 340 – 348.

    I believe an argument can be made that it is somewhat of a bug to not ‘finish’ the task at hand by not also adding the same meta info to the _wp_attachment_metadata column of the same table. Both of these columns are used by various WP processes to determine which sizes of an image currently exist on the server. To not update the data in both columns, in my opinion, leaves the table in an incomplete state.

    Here is the code I’m using to add the data to the other column: (you’d obviously do something different if your were to make the change in-line)

    // first, get the existing value of the _wp_attachment_metadata column
    $sizes = get_post_meta($postID, '_wp_attachment_metadata', true );
    
    // the array stored in the _wp_attachment_metadata column (with one exception)
    // is exactly the same as for the _wp_attachment_backup_sizes.  The exception is 
    // the 'path' field.  So, I unset it here
    unset($sizeArray['path']);
    
    // add a new element to the array with the new image size
    $sizes['sizes']["meta-slider-resized-{$metaWidth}x{$metaHeight}"]=$sizeArray;
    
    // finally, update the table
    update_post_meta($postID, '_wp_attachment_metadata', $sizes);

    Hope this helps. It would be much better if this was just made a part of the code.

    Thanks again Tom,
    fw

    • This reply was modified 7 years ago by fwdcar.
    Thread Starter fwdcar

    (@fwdcar)

    (sorry if this is a duplicate reply – seemed to be having some issues with the first)
    Hey Tom,

    No worries, and I fully understand the need for caution with regards to adding/changing code. I believe the hook will work for me, and it is definitely better than changing the source.

    As far as a better understanding the code, so that you can make the change permanent, here is my pitch:

    One of the things that metaslider does when creating a new image (as a result of cropping), is to add the new image meta info to the _wp_attachment_backup_sizes column of the wp_postmeta table. This happens at lines 340 – 348.

    I believe an argument can be made that it is somewhat of a bug to not ‘finish’ the task at hand by not also adding the same meta info to the _wp_attachment_metadata column of the same table. Both of these columns are used by various WP processes to determine which sizes of an image currently exist on the server. To not update the data in both columns, in my opinion, leaves the table in an incomplete state.

    Here is the code I’m using to add the data to the other column: (you’d obviously do something different if your were to make the change in-line)

    // first, get the existing value of the _wp_attachment_metadata column
    $sizes = get_post_meta($postID, '_wp_attachment_metadata', true );
    
    // the array stored in the _wp_attachment_metadata column (with one exception)
    // is exactly the same as for the _wp_attachment_backup_sizes.  The exception is 
    // the 'path' field.  So, I unset it here
    unset($sizeArray['path']);
    
    // add a new element to the array with the new image size
    $sizes['sizes']["meta-slider-resized-{$metaWidth}x{$metaHeight}"]=$sizeArray;
    
    // finally, update the table
    update_post_meta($postID, '_wp_attachment_metadata', $sizes);

    Hope this helps. It would be much better if this was just made a part of the code.

    Thanks again Tom,
    fw

    Thread Starter fwdcar

    (@fwdcar)

    Sorry, here’s the full code implemented with the new action hook:

    ////////////////////////////////////
    // hook into metaslider plugin to add cropped images to the post meta table
    ////////////////////////////////////
    function CN_add_meta ($postID, $metaWidth, $metaHeight, $sizeArray)
    {
      $sizes = get_post_meta($postID, '_wp_attachment_metadata', true );
      unset($sizeArray['path']);
      $sizes['sizes']["meta-slider-resized-{$metaWidth}x{$metaHeight}"]=$sizeArray;
      update_post_meta($postID, '_wp_attachment_metadata', $sizes);
    }
    add_action('metaslider_after_resize_image','CN_add_meta',10,4);
    matchalabs

    (@matchalabs)

    Hi fw,

    I appreciate the time (and education) you’re giving me here! I’ve been stepping through the code and it’s all making complete sense now.

    I’ve updated the plugin with your suggestions. Please can you install the WP Rollback plugin, and use it to roll Meta Slider forward to version 3.5.1? You should be able to/will need to remove your custom action.

    Regards,
    Tom

    Thread Starter fwdcar

    (@fwdcar)

    That’s great Tom!

    I can run some tests on it. Is it possible I can download 3.5.1 instead of using the rollback plugin? Or perhaps you can just post the lines of code that changed?

    Thanks,
    fw

    Thread Starter fwdcar

    (@fwdcar)

    Ignore my last post Tom, I was able to download 3.5.1.

    Thread Starter fwdcar

    (@fwdcar)

    Hi Tom,

    $saved[‘path’] was unset at line 352 but then used at line 356 (passed to the do_action) and 358 (to build $url) – the latter causing an exception error.

    If I may, here is some suggested code for the fix. I tried to name the vars consistent with what already existed. The code becomes lines 350-364:

            // Update recorded image sizes in the metadata
            $meta_sizes = get_post_meta($this->id, '_wp_attachment_metadata', true );
            if ( ! is_array( $meta_sizes ) ) {
                $meta_sizes = array();
            }
            $temp_saved=$saved;  // working copy of $saved
            unset($temp_saved['path']); // this does not belong in the meta data
            $meta_sizes['sizes']["meta-slider-resized-{$dest_size['width']}x{$dest_size['height']}"] = $temp_saved;
            update_post_meta($this->id, '_wp_attachment_metadata', $meta_sizes);
    
            $url = str_replace( basename( $this->url ), basename( $saved['path'] ), $this->url );
    
            do_action( "metaslider_after_resize_image", $this->id, $dest_size['width'], $dest_size['height'], $url );
    
            return $url;

    ***** Please note: I took the liberty to move the do_action just before the return statement and changed its last parameter to $url. This is only a suggestion, as I do not know what other uses may have been intended for the do_action. If the only purpose was mine, then feel free to remove the do_action all together if you like.

    I ran several tests with this code, and all seems fine, but i’m sure you’ll run it through your own testing.

    I hope this all helps Tom.

    Thanks,
    fw

    matchalabs

    (@matchalabs)

    Hi fw,

    Thanks again for your feedback, and good spot on the $saved[path] issue.

    Please note: I took the liberty to move the do_action just before the return statement and changed its last parameter to $url. This is only a suggestion, as I do not know what other uses may have been intended for the do_action. If the only purpose was mine, then feel free to remove the do_action all together if you like.

    Yep, it was just added for you. It makes sense to have an action there so I’ve left it in and moved it as you suggested.

    The development version has been updated now πŸ™‚

    Regards,
    Tom

    Thread Starter fwdcar

    (@fwdcar)

    That’s great Tom. Thanks very much for all the effort on this.
    fw

Viewing 12 replies - 1 through 12 (of 12 total)
  • The topic ‘compatibility with WP Offload S3 plugin’ is closed to new replies.