dancriel

I was having this issue as well. The plugin is intentionally avoiding HTTPS for some reason, and the Pixabay server seems to be intermittently throwing Bad Request (HTTP 400) errors on the non-secure https:// URLs.

The following change should stop the Pixabay plugin from forcing non-secure image download URLs.

In pixabay-images.php, replace line 190:

$url = str_replace('https:', 'http:', $_POST['image_url']);

with:

$url = $_POST['image_url'];

I think this is a 2 year old bug that was never fixed. The solution offered in this support thread worked for me and restored the Analyticator options page as well as the dashboard widget provided by this plugin, which was also broken.

Summary:

1. Edit google-analyticator/google-api-php-client/src/Google_Client.php
2. Change line 35 from: require_once "config.php"; to require_once (dirname(__FILE__) . "/config.php");

I never got my original approach to work because it looks like using the set_site_transient() function prevents these action hooks from being called, so there is no opportunity to fix the transient right after it’s inserted. So instead I decided to schedule a custom cleanup function every 15 minutes. I had to define a custom cron schedule option in order to do this. Code below:

// define a custom shorter cron interval
function dc_customize_cron_schedules( $schedules ) {
	$schedules['every15'] = array(
		'interval' => 60 * 15,
		'display' => __( 'Every 15 Minutes' )
	);
	return $schedules;
}
add_filter( 'cron_schedules', 'dc_customize_cron_schedules' );

// make sure cron job is set
function dc_setup_cron_schedule() {
	if ( ! wp_next_scheduled( 'dc_cron_every15' ) ) {
		wp_schedule_event( time(), 'every15', 'dc_cron_every15');
	}
}
add_action( 'wp', 'dc_setup_cron_schedule' );

// fix site transients autoload bug for BruteProtect
function dc_cron_fix_BP_site_transients() {
	global $wpdb;
	$result = $wpdb->query("
		UPDATE {$wpdb->options}
		SET autoload = 'no'
		WHERE option_name LIKE ( '%_brute_loginable_%' )
	");
}
add_action( 'dc_cron_every15', 'dc_cron_fix_BP_site_transients' );

The code in my last comment is not working consistently, sometimes it fires, other times it does not. Revising it now.

It looks like this bug still exists. I am running WP 4.0 and the latest version of this plugin, and I found that BruteProtect was keeping almost 45,000 rows in my wp_options table with autoload = ‘yes’. I changed them all to ‘no’ and added the following code to my functions.php file to repair future options immediately after BruteProtect sets them.

function dc_fix_BP_site_transients( $option, $value ) {
	global $wpdb;
	if ( stristr( $option, "_site_transient_brute_loginable_" ) ) {
		$transient_fragment = substr( str_replace( "_site_transient_", "", $option ), 0, 40 );
		$result = $wpdb->query("
			UPDATE {$wpdb->options}
			SET autoload = 'no'
			WHERE option_name LIKE ( '%{$transient_fragment}%' )
		");
		if ( FALSE === $result ) {
			error_log("Error trying to repair site transient {$option}");
		} else {
			//error_log("Successfully repaired site transient {$option}");
		}
	}
}
add_action( 'added_option', 'dc_fix_BP_site_transients', 10, 2 );

I hope this helps someone until there is a better workaround built in to the plugin.

I should have used add_filter instead of add_action but functionally it’s the same since add_action is an alias to add_filter anyway…

This plugin change really burned me… all the custom variable tracking was removed in version 5. I was able to re-enable the features that I use however, by adding the following code to my functions.php file.

function yoast_str_clean( $val ) {
	return remove_accents( str_replace( '---', '-', str_replace( ' ', '-', strtolower( html_entity_decode( $val ) ) ) ) );
}
function fix_yoast_GA_JS( $gaq_push ) {
	global $wp_query, $current_user;
	// Make sure $current_user is filled
	get_currentuserinfo();
	// pop & store the trackPageView action, which will be the last item in the array
	$gaq_push_tail = array_pop( $gaq_push );
	// record logged in user info
	if ( $current_user && $current_user->ID != 0 ) {
		array_push( $gaq_push, "'_setCustomVar',1,'logged-in','" . $current_user->roles[0] . "',1" );
	}
	// record post author name
	array_push( $gaq_push, "'_setCustomVar',2,'author','" . yoast_str_clean( get_the_author_meta( 'display_name', $wp_query->post->post_author ) ) . "',3" );
	// record category
	if ( is_single() ) {
		$cats = get_the_category();
		if ( is_array( $cats ) && isset( $cats[0] ) )
			array_push( $gaq_push, "'_setCustomVar',3,'category','" . $cats[0]->slug . "',3" );
	}
	// restore the trackPageView action to the end of the array
	array_push( $gaq_push, $gaq_push_tail );
	return $gaq_push;
}
add_action('yoast-ga-push-array-ga-js', 'fix_yoast_GA_JS');

This code will re-enable logged-in role, post author name, and post category custom variable tracking. Note that I hard-coded my custom variable slot numbers and it might not match the slot numbers that you were previously using. Log in to GA and check out your Custom Variables dashboard to see which slot number you should be using for each of these.

If you really need these features and you don’t feel like messing with the code, I guess you could always downgrade to v4.3.5.

I had the same issue with the %%name%% replacement variable on multiple installs. I went to GitHub and grabbed a copy of the latest version of /inc/wpseo-functions.php, and overwrote my local copy. Author page titles are now working as expected, and the other features of the SEO plugin seem to be working correctly so I believe this is a safe fix until a new version is released to the public.

I greatly improved my site performance by combining my hack mentioned above (commenting out the PHP in W3TC which would dump the entire cache all at once) along with modifying, via my theme’s functions.php file, some of the hooks that W3TC uses to determine whether to purge an object. Eventually I will block this action at the reverse proxy level instead of within the plugin so W3TC becomes upgrade safe again.

Example: W3TC will purge a post and any other associated objects (archives, feeds, etc.) depending on your settings when a comment is submitted but NOT approved for that post. So we were receiving Spam comments which were flagged by Akismet and dumped into either Spam or Trash, but yet W3TC still saw fit to purge the post from the cache immediately instead of waiting for the comment to actually be approved.

Bottom line: the Varnish purge criteria in W3TC is too aggressive and fails to consider the status of comment objects before issuing purge commands each time the object is saved in the WordPress DB.

Resolved by modifying the W3TC CDN plugin, added COLLATE statements to this query and now it runs without error even with non-ascii characters in the path.

The problem was in my theme. We are appending a clearing div to the end of our post content, and we were doing so without first inserting a newline character. As a result, an embed link at the very end of a post was failing to trigger the WordPress embed feature because it was no longer on a line by itself. Adding a newline character before our appended HTML fixed the problem.

Just do what the error suggests and delete (or move) advanced-cache.php and db.php. If you re-activate W3TC in the future those files should be recreated automatically.

Once you get back in to your site, you should be able to safely move the plugin folder back to /wp-content/plugins/. The plugin should remain disabled, but none of your settings should get lost.

If you can FTP or SSH into to your server, you can disable the plugin by moving the plugin files to another folder. Create a new directory under /wp-content/ called “plugins.disabled” and move the /wp-content/plugins/w3-total-cache/ folder to /wp-content/plugins.disabled/

The next time you visit your site, WordPress should automatically disable the plugin because it can’t find the files that you moved.

The links listed in this thread are all from other domains (ad networks, google fonts, etc.), not from the domains owned by the comment authors… you can’t control the cache settings for content coming from other sites. The solution is to just ignore these items in YSlow.