rmmoul

@cbctraining We ended up using the pre_get_posts filter to exclude a specific tag from the search results.

add_filter('pre_get_posts', 'exclude_private_tag_from_search');
function exclude_private_tag_from_search($query){
	
	if(!$query->is_admin && $query->is_search && $query->is_main_query()){
		$query->set('tag__not_in', array(44)); // 44 is private tag id
	}

	return $query;
}

It updated a day or so after we put the new api keys into place and finally pulled in the more recent 5 listings from the google places api.

It was less debugging help that we needed and more of a way to tell the plugin to try to pull in the data from google immediately so that we wouldn’t need to wait for the plugin to get around to it on its regular schedule.

Having a “refresh right now” button may be a helpful addition to the plugin.

You’re a life saver! Thank you for taking the extra time to look into this for us, that worked perfectly.

It turns out to be a 3 way issue between GiveWP, Woocommerce, and the Pro Panel plugin. Having GiveWP and Woocommerce activated at the same time prevents Pro Panel from working. Disabling either GiveWP or Woocommerce separately allows Pro Panel to work. For some reason the combination of both running on the site causes the issue.

We tracked this down to a custom template file that was using strtotime on just the month and day and since the year was excluded strtotime was defaulting to the current year where January 1st was a Tuesday.

Thanks for the super quick response, your patch is working great for us.

I’ve had nothing but problems when working with toolset. Working on client sites that use these plugins for page templates has been a total pain. On two occasions now, just migrating the site and changing nothing but the site’s url (like pushing the site to staging with wpengine) has caused some toolset built woocommerce templates to completely break for no apparent reason. When our clients eventually want to redesign these websites we don’t include toolset in the new build.

I figured it out. When using a “full width” row in the SiteOrigin Page Builder, the row is made full width using javascript and this is done as the page is loading but for me it’s happening after the video background is put into place so the video was just the size of the row before it expanded to full width.

To fix this, I hacked together a timer than runs every 0.5 seconds to trigger a fake resize event to get the video background plugin to make the video stretch to fill the row. This is really hacky, though and something better should be built into the plugin.

jQuery(document).ready(function($){
	var tid = setInterval(trigger_resize, 500);
	function trigger_resize(){
		$(window).trigger('resize');
	}
});

• This reply was modified 7 years, 10 months ago by rmmoul.

Could you share how you fixed the issue? A site I’m using on is having the same issue, though if I change browser tabs and come back the video will stretch automatically.

I’m experiencing this too, along with a few other issues. I was going to try to fix a few myself, but I’m going to remove this plugin. I can’t put this on a client’s site.

I hacked up a fix for this:

in the plugin file geo-redirect.php, go to the end of the file and replace the line:

if (!is_admin()) {
    do_action('check_client_location');
}

with:

if (strpos($_SERVER['HTTP_USER_AGENT'],'facebook') === false) {
    if (!is_admin()) {
        do_action('check_client_location');
    }
}

This will check the useragent string to see if it contains the word facebook, and will stop the redirection if it does. This shouldn’t be an issue for facebook since users will probably be sharing links that already went through the redirection to the proper language page, so facebook should still get the proper language without the redirect.

I’d like to get an answer on this as well. Right now, this plugin is preventing facebook from properly getting site data.

Checking the facebook debugger shows errors about the redirects. Disabling the plugin allows facebook to properly scrape the content.

I found the issue. The client is using this plugin:

Post Types Order

Disabling it fixed the issue.

Did you try updating your permalink settings after moving the database? Your permalink settings are saved in the database, but the actual permalink tool modifies your website’s .htaccess file.

I figured it out, but forget how I did it… It was awhile ago.