fanalejr

It looks like you are manually adding this code? You’ll notice the current_url value in the code you are using:

https://screencast.com/t/ER2Ozjd0

That needs to be changed based on the URL of the page you are manually adding this code to. Otherwise, FB is just going to pull the comments based on that one URL if it’s not changed.

Hope that helps

This is really awesome news! We use this on a multisite install an many users take advantage of it. Can’t thank you enough.

Thanks for the quick response – yes you can do it on a site install, is there a way to do it network wide?

Great – thanks for the quick response Alex. We’ll revert for now. FYI, the new version functionality is awesome. Some really cool updates with look and feel.

• This reply was modified 7 years, 1 month ago by fanalejr.

We actually have that plugin on our network and it’s awesome. However, again, this isn’t an ideal fix because we don’t want to auto activate this plugin on every site on our network, as many I’m sure don’t use it. For instance, if 500 or so use it and 500 or so don’t, we don’t want to force activate it on every single site.

We use this plugin on a multisite network with thousands of users. We experienced this issue on our staging server and had to revert. Updating would cause every one of our users to lose their widgets from this plugin, and require them to manually go back in and activate their plugin? Is there no way around this?

Yes – I’ve tested on 3 different multisite installs and getting the same functionality on each (one with subdomains, one subdirectories, one with hyperDB as well and domain mapping). I’ve tried on a fresh multisite install as well, wordpress 4.7.3 and 4.6.3 and getting the same deal every time. Here is a quick screencast of exactly what I’m seeing: https://screencast.com/t/QCjKlcCcFfZM

Ah cool – Nah, nothing yet from the Jetpack folks – were you able to reproduce this at all? I’ll let you know as soon as I hear anything on their end.
Thanks

Hey – sorry for the miscommunication here. Nothing to do with the ‘protect’ module – just the site stats. What I’ve found is that if I have the plugin set to not auto-activate modules, then the user has to manually activate site stats. If the user has to do that, then they get the console error mentioned above. If I allow site stats to be auto activated, then everything is fine.

Yes – it’s the default jetpack hook. I’m keeping ‘protect’ as auto active but have been toying around with site stats being turned off/on from auto activation.

function custom_auto_activate_modules() {
    return array( 'protect' );
}
add_filter( 'jetpack_get_default_modules', 'custom_auto_activate_modules' );

Thanks for the response. I’m still doing a bunch of testing on my end and have a back and forth going with the Jetpack guys. The latest thing I’m finding is that it’s not necessarily your plugin, but not allowing site stats to activate upon connection. If I remove your plugin and just use code to whitelist modules AND allow site stats to auto-activate, everything is fine. If I turn off auto-activation for site stats, and the user has to manually click on “Activate Site Stats” – that’s when the error comes in. This occurs on any multisite installation I’ve tested on, even with no other plugins active. Haven’t nailed down anything definitively yet.

Awesome – we’ll test it out – thanks so much for the quick response

Joel – that’s great! Thank you – we’ll try to get it up on our staging server tomorrow and test it out. Thanks

Be sure to see what your Firefox settings are like, or if you are using incognito mode. The likebox shows up for me in Firefox, but in incognito there is a console error:

The resource at "https://connect.facebook.net/en_US/all.js#xfbml=1&appId=395202813876688" was blocked because tracking protection is enabled.

@adam_ph – Looks like you got it figured out at the bottom of your site. Question – were those images previously ‘featured images’ from posts/pages? We recently upgraded on a staging site and we’re finding that with Divi, if you have it set up to use ‘thumbs’ on archives/posts, meaning Divi will take the first image in the post and use it as a featured image, then – if you don’t manually upload a specific featured image that Offload S3 seems to miss changing the URL on load and attempts the local server URL, which in our case would be broken because we remove images from our server.

Thanks