Support

Thank you for the kind words about Panopticon. I’m glad it’s useful to you.

Support for Panopticon is nominally provided through GitHub, not through this ticket system:

• GitHub Issues for bug reports
• GitHub Discussions for questions and help

The Panopticon community lives there, and anyone with a similar problem can find the answer later. That said, you’ve already written to me, so I’ll answer you here this time; there's no point pointing you to GitHub where I will still be the one answering this :)

I can’t tell you what exactly is going on for certain yet, but what you describe is not implausible. The WordPress version, the PHP version and the Admin Tools status all come from one request that Panopticon makes to your site’s Panopticon connector. The list of extensions comes from a different request. If that first request fails, or returns something Panopticon can’t read, those three items stay empty even though the extensions list works fine. We need to find out why that request fails on your WordPress sites, and we can’t tell from here. A security plugin, a firewall or CDN rule, or the host could all cause it.

Here's what to do.

1. Open one of the affected WordPress sites in Panopticon. In the toolbar, click Troubleshoot and then Connection Doctor. If it reports a problem, follow its suggestions. It explains the common causes, such as a firewall blocking the request or the site printing PHP warnings that corrupt the response. After fixing it, refresh the site information and see whether the values appear.
2. If the Connection Doctor says “All good!”, please tell me. This is useful information: it means the basic connection works, and the problem is specific to that one request.
3. In that case, please open the Administration -> Log Files page in Panopticon and send me the lines from the time you last refreshed that site’s information. We are looking for a message like “Could not retrieve information for WordPress site #… Invalid data returned from API call.” or any error mentioning that site.
4. Please also tell me:
   • the version of the Akeeba Panopticon Connector plugin on that WordPress site,
   • the WordPress version, and
   • your hosting provider, and whether the site is behind a CDN or firewall service such as Cloudflare or Sucuri.

With the Connection Doctor result and the log lines we should be able to say what is blocking the request.

The connection doctor does everything I can test for if given access to Panopticon and the site. The Connection Troubleshooting documentation page has everything I know about how to troubleshoot connection issues. I don't keep any knowledge to myself.

Can you send me a screenshot of what you see in Panopticon for these sites, though?

Thank you for the screenshots and for testing on so many hosts.

In my previous reply I asked you to look in the Panopticon log for an “Invalid data returned from API call” message. By default, Panopticon only records messages of level warning and above, and that message is logged at a lower level. So “no errors in the log” doesn’t rule anything out. Sorry about that.

What we can tell from the screenshot:

• All four WordPress sites behave the same way, on different hosts, while the Joomla sites work. So it’s unlikely to be one specific host.
• The Connection Doctor tests whether Panopticon can log in and read the list of plugins. That works for you, which is why the extensions list is fine. It does not test the separate request which provides the WordPress version, the PHP version and the Admin Tools status. That is the request which seems to be failing.
• If that request had failed with an error, Panopticon would normally have logged an error. So my best guess is that the site answers, but Panopticon can’t use the answer. This is a guess, not a conclusion. We need to look at the actual answer.

Meanwhile, my copy of Panopticon works fine across all WordPress sites I have access to, which is perplexing. It's like one data point points at a connector issue, the other points at no issue at all. Huh.

Before we do anything else: have you installed the latest available version of the connector that you have manually downloaded from GitHub? If not, try it now. It's possible that WordPress does not offer the updated version and you're using an old, buggy version of the connector plugin.

In any case, I’d like to try this without asking for access to your Panopticon installation or your sites. The three steps below should show us what’s going on.

1. Turn on debug logging. In Panopticon, go to System Configuration and set Log level to Debug. Save, then refresh the information of one of the WordPress sites. Open Log Files, and send me the lines from that refresh. You can remove the lines about your other sites.

2. Show me what the site actually returns. Run the command below on your computer, in a terminal. Replace KEY with the API key of that site (shown on the site’s edit page in Panopticon) and SITE with the site’s domain name:

   curl -i -H "X-Panopticon-Token: KEY" "https://SITE/wp-json/v1/panopticon/core/update?force=1" | head -c 3000

   Send me the output. Do not include the API key. The output itself doesn’t contain it, but double-check before pasting. If the output contains a secret_word entry, replace its value with XXX first.

3. Rule out system information collection. On one of the WordPress sites, open the settings of the Akeeba Panopticon Connector plugin and turn off Report System Information. Then refresh that site in Panopticon, and tell me whether the WordPress and PHP versions appear.

If step 3 fixes it on that site, please also send me the results of steps 1 and 2 from before you changed the setting. They would tell us why it fails.

This was gnawing on my brain all day. I sleuthed and found this 2-year-old discussion: https://github.com/getpanopticon/panopticon/discussions/800 In that case, the user had downloaded and installed the wrong ZIP file. Is it possible you did the same?

No worries! I am glad it was something so simple to fix. Have a great weekend!