Tyler Johnson

Hey Healthnut,

It’s working for me. Is it working for you now? What did you do?

Also, I have it filtered on “Advanced” tab under the “Your Social Networks Accounts” settings panel and I’ve un-selected the category I don’t want to auto post.

I also set it under the “Settings” tab with “Categories to Include/Exclude:” by unchecking the category I don’t want to auto post as well.

The posts are scheduled to be posted. When the schedule tells them to post, here’s what the log says…

[2015-05-21 13:10:08] - [Posted] [Twitter - jmattbarber] - OK - Message Posted | PostID: 38841 - New Cellphone Video Shows Freddie Gray Put In Police Van |im | Post Link
[2015-05-21 13:10:08] - [Posted] [Facebook - BarbWire Facebook Page] - OK - Message Posted | PostID: 38841 - New Cellphone Video Shows Freddie Gray Put In Police Van |im | Post Link
[2015-05-21 13:10:03] - [Start =- ]- ------=========#### NEW AUTO-POST REQUEST PostID:(38841) Automated ####=========------
[2015-05-21 13:10:03] - [*** ID: 38841, Type: post]- Status Changed: new_to_publish. Autopost requested.

Thanks for your help!

I can confirm Jan that it isn’t just MP3s, but all file types from the media uploader on posts. Doesn’t matter if it’s a JPG, PNG, GIF, etc., it’s all broken.

I’m seeing this issue on tons of sites. It’s really getting annoying! Can someone take look at this?

Also, sorry, I meant to post this in the other thread, but got my tabs mixed up.

Okay, sweet! Those two fields are the only fields I need, and the site I’m using it on is launching on the 6th. I’ll PayPal you for one site license in a couple of minutes.

Is the ETA on the custom fields correct?

Hey htown,

Don’t know if it’s too late, but this is how I fixed it. You have to add this via CSS:

.ui-dialog.ui-widget.ui-widget-content.ui-corner-all.ui-front.wp-dialog.ui-dialog-buttons.ui-draggable.ui-resizable {
    z-index: 999999 !important;
}

After looking around a little bit, these are processes on the backend…

UPDATEwp_optionsSEToption_value= 'a:16191:{i:1419011820;a:1:{s:27:\"wpua_has_gravatar_cron_hook\";a:1:{s:32:\"40cd750bba9870f18aada2478b24840a\";a:3:{s:8:\"schedule\";s:5:\"daily\";s:4:\"args\";a:0:{}s:8:\"interval\";i:86400;}}}i:1419011825;a:1:{s:27:\"wpua_has_gravatar_cron_hook\";a:1:{s:32:\"40cd750bba9870f18aada2478b24840a\";a:3:{s:8:\"schedule\";s:5:\"daily\";s:4:\"args\";a:0:{}s:8:\"interval\";i:86400;}}}i:1419011832;a:1:{s:27:\"wpua_has_gravatar_cron_hook\";a:1:{s:32:\

These cron jobs are inserting 3MB sized binary logs into the wp_options table were adding up to a Gig within 5-7 minutes.

Here’s the portion of the plugins code that’s responsible for the large updates:

/**
?  * Checks whether registered user has Grvatar-hosted image or not.
?  * Set the flag in database according to existence of Gravatr image.
?  * @uses object $wpua_functions
?  * @uses int $blog_id
?  * @param int $user_id
?  * @uses wpua_has_gravatar()
? */
? public function set_wpua_has_gravatar($user_id=""){
? ? ? ? global $blog_id, $wpua_functions;
? ? ? ? if(!empty($user_id)){
? ? ? ? ? ? ? ? $flag = $wpua_functions->wpua_has_gravatar($user_id);
? ? ? ? ? ? ? ? ? ? ? ? // Update usermeta
? ? ? ? ? ? ? ? ? ? ? ? update_user_meta( $user_id, 'wpua_has_gravatar', $flag);
? ? ? ? }
? ? ? ? else{
? ? ? ? ? ? ? ? $blogusers = get_users( 'blog_id='.$blog_id );
? ? ? ? ? ? ? ? // Array of WP_User objects.
? ? ? ? ? ? ? ? foreach ( $blogusers as $user ) {
? ? ? ? ? ? ? ? ? ? ? ? $flag = $wpua_functions->wpua_has_gravatar($user->ID);
? ? ? ? ? ? ? ? ? ? ? ? // Update usermeta
? ? ? ? ? ? ? ? ? ? ? ? update_user_meta( $user->ID, 'wpua_has_gravatar', $flag);
? ? ? ? ? ? ? ? }
? ? ? ? }
? }

For a quick remedy, my host applied max_binlog_files to cap how much in binary log can be written, which takes care of the load for the time being, but it isn’t a permanent solution.

Any idea how we can optimize this code so that it doesn’t attempt to write Gigs worth of data to the wp_options table?