Good, but a little intrusive

Hi there,
Re: PHP versions. We only show the notices to those on PHP versions where MonsterInsights has an existing public plan to deprecate support. For those users, we want to make sure they get that updated so they will be able to continue to use MonsterInsights. We include a link to both the versions we support, the ones we are planning on removing support for (and when) and a letter you can send to the hosting provider to get them to upgrade you on the link (which is https://www.monsterinsights.com/docs/update-php/).

WordPress as of yesterday no longer supports PHP 5.2, 5.3, 5.4 and 5.5 installs (though we only show the notice for PHP 5.2 & 5.3 as we’re going to internally keep supporting the remaining 2 for a little bit longer than WordPress will).

Along with Yoast SEO and a couple others, WordPress Core had reached out to us about demoing the notices in our plugin (WordPress core itself also ships a notice in the latest versions). As Core will not permit users on the aforementioned versions to update WordPress to the latest version starting with WordPress 5.2 on April 30th, anything we can do to help our users make sure they’re able to keep their site running reliably, and safely, and to continue to use MonsterInsights is a win for us.

2. For the install wizard, we see a lot of our users confused about what steps they need to take in order to ensure they have MonsterInsights installed and configured. This wizard allows users to quickly setup the required minimum steps and includes many behind the scenes features, some of which you might not have seen (for example, we scan the HTML code and show you an alert with a link a guide on how to find and remove them, if we find more than 1 GA install on a site so that way you don’t get double pagecounts — something you can’t reverse later).

We don’t enable auto-update by default, that’s something you have to manually turn on. What we do offer is a setting so that you can have MonsterInsights automatically install new major and/or minor releases (configurable) if you desire, so that way you don’t have to go in and manually update it (which helps out a lot of people who run MonsterInsights on a lot of sites). Again, you have to manually turn that on.

The manual UA code, as mentioned on a different thread, is still supported, the link is missing to enter it on new installs only currently due to a bug after a complete dashboard rewrite into VueJS and we made sure its there on the next version

Thanks for the comprehensive reply, and apologies if my review sounded too harsh – it was on a bad day dealing with old installs.

When you have hundreds of clients, most who are happy to have their sites updated, you’re still going to have a few non-techie clients who don’t want to pay to keep things tip-top. Sometimes they have old purchased themes that break >5.6. Moving these along is a slow process but we’re getting there.

I stand by the point that plugins shouldn’t display non-dismissable prompts. If you have 10 plugins doing that you’d have no screen real estate left. I acknowledge that WP asked to help out on this, but the way WP does this, from core, on the dashboard seems a good balance to me rather than taking up the screen space. Perhaps consider making it dismissable at least?

The v4.2.8 definitely upgraded without proactive action when I moved it to their new install. Also perhaps the on-boarding wizard might be good as an option to click rather than auto-starting? Good to know the manual UA entry is coming back too.

All of my complaints were perhaps a perfect storm of frustration, so on reflection I’ll bump up my review a notch.

Best regards

Hi there,
We’re definitely looking at ways of doing the notice. After we started the trials, WP.org ended up going the route of that dashboard notice and we’ll probably do that if there’s is not already displaying. We’ve been working on eliminating dashboard notices where we can, since we run all of our own software on our sites and I don’t like them either. I know most of the ones we used to show on our own settings panel are now gone with the 7.4 update, as well as all of the non-urgent things

Our goal isn’t to try to annoy anyone, we just deal with (generally speaking) an audience that doesn’t know what PHP is or what it’s used for but does need to update relatively soon in order to be able to have things running normally with WordPress dropping those PHP versions yesterday. That’s also why we don’t show the notice for the latter 2 versions (5.4 and 5.5). We only want to get to be able to use some of the things introduced in PHP 5.4 as it will make a lot of the things we do so much simpler. And for those users we’re giving them basically an extra 6 months of notice after WordPress stops supporting them (on top of the many months they’ve already had). I know the last time we talked about making them dismissable, we decided against it, but its something we could definitely re-look at now.

The v4.2.8 thing is really interesting to me (I work on the security team that works on that autoupdater system in Core). 4.2.8 was before we owned/maintained the plugin (Prior to 5.5 Yoast owned it), 4.2.8 would be like at least 5 years agoish. But the odd thing is, we didn’t add the option or ability for us to autoupdate if you had that setting turned on until I think 7.1 or 7.2 maybe a year ago. So that autoupdate can’t be coming from us, the code for it didn’t exist in Yoast’s (it was something we added based on user feedback).

I think what’s possible is that maybe your host autodetected it and updated it (I know some do because a few years before we took it over there was a security bug reported). It could be that’s what’s happening. But like the code like isn’t in our plugin in the version you’re describing since I wrote it, and our first version release was 5.5. Very odd. Host would be my best guess. That would also explain the speed of the update (since even with that on, like WordPress the updater rolls, it doesn’t just continuously poll for updates).