Hello, I’ve been using MainWP for quite a while and having no problems at all, but there is a specific situation I’d like to discuss. Here’s the thing.
Sometimes one of my servers will have a problem, eg. the database server stopped and didn’t restart automatically (yeah I know, my fault). Then when refreshing the sites in MainWP, it will show that a bunch of sites are now disconnected. Right, so I fix the hiccup in the server and it’s all good, but then I have to reconnect those sites to MainWP.
The thing is, when trying to reconnect those sites, MainWP will throw the “Public key already set” error. The fix to this is to disable the MainWP Child plugin and re-enable it. But I have a big problem to do this because:
I cannot access the site’s dashboard via MainWP because it is not connected to MainWP anymore
I (for now) cannot manually log in to the site because as a security measure I change my admin password to a random one. It’s different for each site and I don’t store that password anywhere, as I rely on MainWP to log in to the site’s dashboards.
So, I would need to manually reset the admin password via SQL so I can log in back again. That would work for one or two sites but it would be time consuming for 30 or 40. But even if I did that, there would be another problem: the plugin screen is disabled, also for security measures.
The last option would be to use WP-CLI to either reset the password or disable and reenable the child plugin, however due to how my server is set up, it runs WP-CLI with 128 MB of memory and most of the time it throws out of memory errors. I still haven’t figured out how to change that setting in the server.
And that’s the whole picture. But what I would like to know is: why that situation caused the “public key already set” error? It would be understandable if I moved the site to another server or if I created a staging site or whatever, but why a simple disconnect from the MainWP dashboard caused all of this?
Also, I remember this same situation happening in the past but not causing the “public key” issue. So, is there an easier fix other than having to disable and reenable the plugin?
Thanks @kwcjr ! As for WP-CLI, yeah, I can fix the memory issue via WP-CONFIG.PHP but then I would need to do it on every site I have, and it would also be redundant since PHP memory on my server is configured somewhere else. So the problem affects only WP-CLI, but it’s not a big issue since I don’t use it frequently.
I’ll see what I can do about the public key thing, but I’m still curious as to why this problem happens since it was a disconnection caused by a temporary issue with the server.
@denisgomes I wouldn’t be able to give you a definitive answer to that question without knowing more about your particular setup & monitoring the situation. When our test servers go down for a few minutes, usually all sites are connected without an issue once they are back up.
I suggest looking into the server logs for at least one or two of the Child Sites in question as well as the MainWP installation server logs to see if anything could give a better idea of what’s actually happening.
We also have a tool that will reset your MainWP Child Site Plugin settings as if it was never installed. However, you will still need at least FTP access to that Child Site.
Our Dev Team took a look further at this to be sure that it’s nothing on our end & has taken notice that one possible cause for that error could be when Object Cache causes a problem where the Dashboard gets information that the publickey value is set in DB while it’s actually not.
When the Dashboard hits the Child site to connect, Child gets information served from the Object-Cache where the publickey is already set, but in fact, the field is empty in the DB…
During our research, we have not found a way in PHP to programmatically skip the object cache, therefore the only way past this is to either clear the object cache & or deactivate/activate the Child Plugin.
We will continue to monitor this caveat and if we find a solution around that behavior we will be sure to include it in a future release.
I do use object caching with Memcached via the Lscache plugin (I’m running Litespeed servers). However object caching is set to expire in 6 minutes, so I think if it’s something related to the object cache then it would clear out after this time. But I kept getting the error even after 24 hours.
As for other caches I don’t use a TTL of more than 1 hour.