fwdcar

I found the problem.

It was data corruption (ref. integrity issues) in the wp_sitemeta table. Somewhere along the way (months?/years?) the sitemeta table had rows with site_id(s) that didn’t actually exist. Version 1.8.1 obviously didn’t have a problem with this, but 2.2.0 did.

Hope this helps someone else in the future.

update:

These are the erros without XDebug loaded:

Warning: Creating default object from empty value in C:\Apache24\htdocs\wp\wp-content-test\plugins\wp-multi-network\wp-multi-network\includes\functions.php on line 238

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 262144 bytes) in C:\Apache24\htdocs\wp\wp-includes\class-wp-network.php on line 286

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 262144 bytes) in C:\Apache24\htdocs\wp\wp-includes\plugin.php on line 453

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

I haven’t tried this, and it’s really a GUESS, but if you go to networks and ‘edit’ the network, there’s are ‘site assignment’ section at the bottom. Again, pure speculation on my part!

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

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

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

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);

(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

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, 11 months ago by fwdcar.

Hello,

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

Thanks.

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

Thanks.

Sure… I don’t use skype, but I can email you.

• This reply was modified 8 years, 1 month ago by fwdcar.

Yes, relative/absolute paths! Those were the terms that were escaping me. lol.

I did see the docs on the S3 Offload site. I think, though not certain, that if a plugin is using ‘posts’ for their storage (table WP_POSTS) and the WP functions to access these ‘posts’, that other plugins can ‘hook-in’ and change things on the fly…in this case the URL. I was forced to use Meta Slider on another site (I prefer yours) and S3 Offload is able to catch their ‘get’ operations on the image and modify it’s URL…Meta Slider does not have their own tables in the DB, they use WP-POSTS.

Let me ask you this last question… the S3 Offload site also provides a ‘tweaks’ .php file that one can use to ‘overcome plugin incompatibility’. If I wanted to hook into Crelly, just before you go get the image, would this be possible? i.e., do you have a place I can hook into your plugin and change the URL?

FW

No Worries @fabiorino, thanks for the reply back.

I see what you’re saying. Keep in mind that I am not an extreme WP techie, but let me ask this. If crelly would just store the image name in the DB and obtain the ‘domain/directory’ portion of the URL at run-time, wouldn’t that allow you to provide the greatest flexibility with respects to where images are ultimately stored?

Because unless I’m missing something, and that is very possible :), using (for example) the #defines WP_CONTENT and WP_CONTENT_URL in wp-config.php, which tell WP at runtime where to look for ‘content’, would break the crelly sliders correct? Or, if I as a developer, want to do local-host development and then move to production, wouldn’t I have to open up each slide in crelly and reselect the image from the media gallery?

And really, the other example is using a CDN (like S3). It would be nice to be able to turn one’s CDN off and on within the site and not have to worry about hard-specified paths. If I understand the S3 Offload plugin in question, they ‘hook’ into the API to modify the URL when the attachment is requested? That appears what their docs say, but again, not really technical on the hooks and filters functionality within WP.

Thanks for bearing with me, and please feel free to correct me if I’ve misunderstood.

Thanks,
FW