Plugin Author
RavanH
(@ravanh)
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.
Plugin Author
RavanH
(@ravanh)
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' );
Plugin Author
RavanH
(@ravanh)
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.
Plugin Author
RavanH
(@ravanh)
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?
Plugin Author
RavanH
(@ravanh)
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
Plugin Author
RavanH
(@ravanh)
Have you tested with different browsers? Is there a browser plugin that might be interfering here maybe?
Plugin Author
RavanH
(@ravanh)
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?
-
This reply was modified 2 years ago by
RavanH.