katdidit

Google+ is no longer – per google they are shutting it down and the API will be discontinued permanently in March, https://developers.google.com/+/api-shutdown.

“Beginning March 7, all OAuth token requests with scopes starting with “plus.” (i.e. “plus.me”, “plus.login”, “plus.profile.emails.read”, etc) will fail upon request, and may start to intermittently fail as early as February 15, 2019.
The Google+ Sign-in feature has been fully deprecated and will also be shut down on March 7, 2019. Developers should migrate to the more comprehensive Google Sign-in authentication system.
Over the Air Installs is now deprecated and has been shut down.”

Did you ever find a solution for this? Been beating my head against it for a few days, I wish we had MPDF version six fonts back in the plugin. It was a lot less hassle to enable languages. Would love to hear from anyone who has successfully installed and enabled subset embedding in Chinese and other language fonts. SunA and SunB at least arent’ throwing an error but I’m still getting squares.

what emails are you talking about? The user registration notifications?

“Blocked loading mixed active content “https://app.ecwid.com/script.js?1208150””

Try replacing http: with https: to all of your calls to that script – and if your store program vendor does not support https then you need to replace it, but I can’t imagine that they don’t if it’s still being maintained, its standard in ecommerce these days. It also may require a switch in your store settings to serve to an SSL

You can avoid conflicts in calling to a server you don’t know if you should use http or https, by using // “//app.ecwid.com/script.js?1208150” but your problem is that you are using ssl and calling to unencrypted content on the store server,

Actually, The fix posted above does work in chrome, but kills the parallax scroll in firefox and ie –
The final solution was to add a class for the browser type with the global booleans and body_class filter (child them function), then add the CSS above using the selector .chrome .panel-image

//add browser class to body class 
function browser_body_classes($classes) {
   global $is_iphone, $is_chrome, $is_safari, $is_NS4, $is_opera, $is_macIE, $is_winIE, $is_gecko, $is_lynx, $is_IE, $is_edge;
if  ($is_iphone) $classes[] = 'iphone-safari';
	elseif  ($is_chrome)  $classes[] = 'chrome';
	elseif  ($is_safari)  $classes[] = 'safari';
	elseif  ($is_NS4)  $classes[] = '	netscape4';
	elseif  ($is_opera)  $classes[] = 'opera';
	elseif  ($is_macIE)  $classes[] = 'mac-ie';
	elseif  ($is_winIE)  $classes[] = 'win-ie';
	elseif  ($is_gecko)  $classes[] = 'firefox';
	elseif  ($is_lynx)  $classes[] = 'lynx';
	elseif  ($is_IE)  $classes[] = 'ie';
	elseif  ($is_edge)  $classes[] = 'ms-edge';
	else 	$classes[] = 'unk-browsr';			
return $classes;
}
add_filter('body_class','browser_body_classes');

Hello I am just checking back and noticed I didn’t include the error its generating just the path My bad. the error being generated is “Invalid argument supplied for foreach() ”

Hope it helps, all the credit goes to Woo though ??

Hi usually this is a problem with PayPal and/or Woo IPN settings not set up correctly.

https://docs.woocommerce.com/document/paypal-standard/ gives you info on how to make sure its set up correctly in woo and PayPal – if that does not work I would suggest finding another developer unless you are savvy enough to diagnose the site yourself.

the problems in your header links not your htaccess you are missing the header entries for canonical and shortlink and oembed/ between the wlmanifest and the woo gallery tags. My best guess for this is your theme, have you tried it with a vanilla theme?

link rel="wlwmanifest" type="application/wlwmanifest+xml" href="/wp-includes/wlwmanifest.xml" /

<link rel="canonical" href="https://yourdomain/cart/" />
<link rel='shortlink' href='https://yourdomain/?p=1215' />
<link rel="alternate" type="application/json+oembed" href="https://yourdomain/wp-json/oembed/1.0/embed?url=https~hash~yourdomain%2Fcart%2F" />
<link rel="alternate" type="text/xml+oembed" href="https://yourdomain/wp-json/oembed/1.0/embed?url=https%3A%2F%2Fyourdomain%2Fcart%2F&format=xml" />
	

<noscript><style>.woocommerce-product-gallery{ opacity: 1 !important; }</style></noscript>

• This reply was modified 7 years, 4 months ago by katdidit.

can you link me to one of the other pages?

The only 404’s I’ve seen are on the cart and checkout pages – have you activated your checkout process and set the right pages for them? Check your Woocommerce settings under checkout and woocommerce status to what pages they are set to show up on.

oops not the same error. sorry will open my own issue or look for my issue.

• This reply was modified 7 years, 5 months ago by katdidit.
• This reply was modified 7 years, 5 months ago by katdidit.

You have several 304 errors on your theme, which means you are doubling up, but other than that I can’t tell you much. To compare the calls highlight the scripts and look at the right hand boxes. You might also want to run the debugger tool with your theme. After you turn it step through it as you click for your thumbnails.

Also just a thought, have you declared woo-commerce support in your theme’s function file? https://docs.woocommerce.com/document/declare-woocommerce-support-in-third-party-theme/

yes there is, but you’ll need to disable your no-right clicks to do it then you can use firefox, ie or chromes webdeveloper tools – under network, xhr, js to inspect the calls being made, I would do it with the theme that works and then the theme that isn’t working to see the difference.

Also, just so you know the word cookie does not have a second c in it.

sometimes things appear to be one thing but are really another – because your shop is working and the other pages are not affected it is most likely a conflict with Avada/Woo, but there is always a possibility that another plugin is in conflict as well, and that’s why its always a good idea to try disabling them one at a time to see if any of them are factors. The only reason I would have started with rev slider is because its the first place where your header fails to load, but after testing that you should really go on to each plugin. Also because it is happening on your blog posts and not on your shop is another reason that points to a theme conflict rather than a woo problem.