Hi @kdowns, thanks for getting in touch. I apologize for missing the update as I’d sent the extra reply a week after requesting the diagnostic to keep it from being closed.
To prevent any further delays, it still looks like a diagnostic containing your username was never received to our inbox so it might be best to send it from your own email address. Are you able to download the txt version from the Wordfence > Tools > Diagnostics page and email it to wftest @ wordfence . com manually as an attachment? Don’t forget to include your forum username in the subject line, and once again let me know here when you’ve sent it over.
Often this can occur when emails aren’t sending from your site, which might be linked to any communication errors that might also be affecting the scans. I’ve closed the other topic and we’ll continue here.
Thanks,
Peter.
@wfpeter, thank you! The email has just been sent over with an export of the the diagnostic info. Subject line is as follows: “WF Diagnostics Report – @kdowns”
Hi @kdowns,
Thank-you for sending that over. After looking into your diagnostic, I have some similar questions from the original thread because I’m seeing the “200 OK” message along with page content returned when we attempt to connect back to your site. I can already see that your login page doesn’t appear to be hidden behind an alternative URL or by another plugin, which is a common cause of this outcome.
I can also see that your list of active plugins don’t appear to contain anything that we deem to be incompatible. However, I wasn’t able to see whether you’d already tried disabling all plugins and switching your theme to a WordPress default (such as Twenty Twenty-Three), leaving only Wordfence active. If you do try this, see if the “Connecting back to this site” in Wordfence > Tools > Diagnostics changes from wp_remote_post() test back to this server failed! Response was: 200 OK to OK - IP Address with a green checkmark.
If that does help, reenable your plugins and theme one-by-one to see when the problem starts reoccurring. The reason I ask for this check is because specific custom code can also affect connectivity, so could be theme or functions.php related rather than something we’ve seen before from a known plugin.
Let me know what you find out!
Peter.
Thank you! I ran through those steps and discovered the issue appears to be present when the CoSchedule plugin is active. The plugin is running 3.3.9 and does not have any pending updates at the time of this message.
I’ve left CoSchedule deactivated for now but are you aware of any conflicts with that plugin or with specific versions of that plugin? This might stretch outside testing cases but I’m curious if there may be an awareness of any potential issues.
Hi @kdowns,
I’d just come back to this topic to request a scan log to see the point at which the failure occurred and saw you’d just replied. Thanks for checking that out, CoSchedule hadn’t come up in my records for plugins that are outright incompatible, but I did recently see it mentioned internally regarding another case.
In that instance, CoSchedule was installed but hadn’t completed its initial setup process, so was redirecting logged-out users (rightly) to the login page if the setup page attempted to load. However, it appeared there was a possible bug in when it decided to perform that redirect.
Our connection check won’t be logged into your site, and the 200 OK response was showing the response as the HTML contents of your login page, so it could be connected to this redirect. Unfortunately, I don’t have any news on whether the other customer attempted to contact the CoSchedule developers to seek a resolution.
Thanks again,
Peter.
