I’m not too surprised that it’s back. I suspect that’s just because of how it’s designed to be stored in a transient, which is data that can expire, and then needs to be refreshed.
However, since we interacted last on this, I’ve spent some time experimenting with the plugin in multisite mode and have found that it really doesn’t work smoothly. It wasn’t designed with multisite in mind, though it will be pretty straightforward to add multisite support when time and priority are available to do so.
The new version (currently at 4.0.0-rc17–you could just update from the plugins directory) might work a little better in your case, because the releases metadata (which is what it’s specifically complaining about) are stored in a “site” transient, which is supposed to work network wide.
However, there are several additional changes that would need to be made to really provide a smooth multi-site experience. I can’t offer any ETA for when those changes might be made.
In the meantime, I think it will probably work best to just use it on a site-by-site basis. So, don’t do a network-wide activation; activate the plugin on each individual site. You’d also need to deactivate it on each individual site, when the time comes to deactivate, and manage the options separately on each site. I expect all of that to work reasonably well. When it comes time to uninstall, however, the plugin doesn’t yet include logic in it to uninstall across all of the sites, so some leftover data will remain in the database. That shouldn’t be terrible–it’s a relatively small amount of data that are stored. The bigger chunk of data (the releases metadata) would be removed upon deactivation of the last site.
Our general guidance at this point is that this plugin is not compatible with multisite mode–because it really isn’t designed for that yet. But if you’re feeling adventurous and want to try this site-by-site approach with it, I’ll be interested to hear how it goes.
