Support

Does this appear to happen around the time there's an update available for these plugins? 

Are you using WordPress' auto-update feature for these plugins? See the Plugins page.

Have you entered the Download ID and checked it is the same you see on our site's My Account > Add-on Download IDs page? Do NOT tell me what the Download ID is; this is a public ticket. I just need a yes / no.

I have noticed that sometimes (but not consistently) when we ask WordPress to update a plugin remotely through Panopticon it will go through the process except the last step:

• Download the update ZIP file
• Disable the plugin
• Move the plugin's directory to a temporary location
• Extract the update ZIP file to a (different) temporary location
• Move the extracted plugin in the (original) plugin's folder under wp-content/plugins
• Delete the copy of the previous version of the plugin in the temporary location
• Re-enable the plugin <-- This is what is skipped sometimes

The really wild thing is that we are using WordPress' own code to update plugins, using the exact same trick they are using in WP-CLI. There's nothing special or custom about it. WordPress just… forgets to carry out the last step.

I do not know why it happens, and I do not have the time to troubleshoot this. Panopticon is AGPLv3. If someone wants to spend the time to figure this out they don't just have my blessing, they have my explicit permission as stated in the license.

I just saw that sending you the email notification about this ticket failed because your mail server is misconfigured. Emails sent to you are received by antispamcloud.com. However, instead of that service relaying the message to your actual mailserver, it pretends that it is the sending server of the email! This of course breaks both the DKIM signature, and violates our SPF policy which is designed to only allow the two very specific origins we use for sending emails to prevent email spoofing. This is the correct behaviour; antispamcloud.com and their IP address 91.246.57.194 are NOT allowed to send email on our behalf which makes the delivery of the email sent (not relayed!) by them fail as it should.

I can't believe these idiots charge money for this crap. Setting up a spam trap server which re-sends instead of relaying messages is a fireable offence, not a paid service. Sigh.

For what it's worth, I was able to finally track down why re-enabling the plugin wasn't taking place. WordPress apparently doesn't know if it's running a single- or multi-site installation when you tell it to re-enable a plugin. You have to tell it explicitly. And how do you know that? By asking WordPress, of course. Seriously. It needed me to tell it something it knows and tells me itself. I kid you not.