Hi @fanalejr I have not seen this before but I’ll try to reproduce this tomorrow… In the mean time: does the issue disappear when module control is deactivated?
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.
OK, thanks for this feedback. Could you share the code you are using to prevent auto-activation? And is that for the stats module only or all modules(similar to the code used in my plugin) by returning an empty array in the jetpack_get_default_modules filter?
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' );
I’m keeping ‘protect’ as auto active
As far as I understand it, Protect will always be activate on sub-sites (even if not activated manually or visibly) if it is activated on the main site, even on sub-sites where Jetpack is not connected at all. I may have misunderstood that so you might want to verify that with the Jetpack people…
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.
No, no miscommunication. I did not think you meant there was any relationship, I just thought I should mention there is (as far as I know) no reason to specifically allow Protect as long as it is activated on the main site.
Did the Jetpack folks respond yet?
I cannot reproduce this issue. Does this always happen, no matter what other modules are activated?
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
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
Have you tested with different browsers? Is there a browser plugin that might be interfering here maybe?
OK looking at the error, I have the feeling your browser is using a (cached) admin.js which is different from the one I have on my site. For example, there is no t.resize at all. Have you tried clearing the browser cache?
