dfender

Ok, I think I figured it out:

This morning, after searching in vain through all the logs and server settings I could find for any hint of a clue of something to try, I decided to try running the WordPress troubleshooting mode again since I fixed the .htaccess rewrite/redirect issue and the issue with the SSL intermediate server certificate yesterday.

Once again, in Troubleshooting mode, Site Kite connected without errors.

But, as I started re-enabling the other plugins this time, I did NOT get the same server crashing errors that I encountered the other day (or any other errors on the plugins screen).

And, unlike the other day, I did find one plugin, an embedded video player, that tripped Site Kit into producing the REST API error. After checking the rest of the plugins, I exited Troubleshooting mode, deactivated the video player plugin and now Site Kit works like it’s supposed to.

I’m not sure why that plugin didn’t cause a conflict on my old host, but did on my new one. I moved hosts because I could get the most recent MySQL and such that my old host wasn’t providing, so perhaps something about the new versions of that stuff broke the old plugin.

Anyway, I appreciate your help – it did help me stumble into finding a solution. Thanks!

I opened up the developer tools in Chrome and get this error message when trying to connect to Site Kit:

googlesitekit-api-81eec639102e319fbfee.js:1 Google Site Kit API Error method:GET datapoint:health-checks type:core identifier:site error:”The response is not a valid JSON response.”

Another update:
1) I found out that the cache on my browser was making me think I was being redirected to https, but the settings I thought I had set didn’t actually get written into my .htaccess file. So, I think I fixed that problem and everything really is being redirected now. Does that correct the insecure version you mentioned above?

2) I also fixed the intermediate certificate issue with my SSL. Why No Padlock? shows everything is good now.

BUT – neither of those fixes has corrected my original problem of SiteKit not accessing the REST API. So the mystery continues

~David

After reading the link you mentioned above – I did find that page before and it wasn’t able to help.

I’m not sure what you mean by the insecure version is still accessible. I have my settings set to force and direct to secure content. Unless:

1) I ran my site through Whynopadlock and it says “You have an invalid or missing intermediate (bundle) certificate. This may not break your padlock on all browsers, but will on others. Please contact your SSL Vendor for assistance with this error.” I’m not sure why that is, so I’m looking into that.

2) In the meantime, I notice that my httpd.conf file has a VirtualHost entry to http on port 80 as well as the https on port 443. Should I remove that entry?

Thanks for the reply. I submitted the site health info. There are no errors showing up in the status related to Rest endpoints (just one about object caching that I’m also working on and another about plugins not being compliant with the Consent API)

I will over the link that you provided in a little bit when have a minute to check on that error and let you know if that makes any difference.

I fixed it (I think)

First – in an attempt that failed, I deleted my existing analytics setup on the Google site and created a new Google login for SiteKit to connect to to see if the problem was tied to the Analytics account.

The same problem occurred – as soon as it goes to the “verification” page, it loops back to a 404 error on my website.

So, following up on my original hunch that the problem all along has been that the SiteKit plugin is coded to grab the installation address from the “Site” address in the WordPress settings instead of the “WordPress” address, I simply added the subfolder between my web address and “wpadmin” to the link that was in browser’s address bar when the 404 page returned, hit return, and things magically started working.

It didn’t get all the way through – after 3 or 4 pages it got hung up on a bad address again. But after I tried it a second time, everything connected and SiteKit is now happy and setup and attached to my new analytics account.

So, now I’ll wait a couple days to see if data actually starts transmitting and I’ll check back in here to confirm one way or the other.

Yes, when I reset the WordPress installation to the root location – both the site address and the WordPress address were set to the root as it originally was. And SiteKit connected just fine. Then I did the Reset Site Kit process and deactivated and deleted the plugin.

I would welcome someone checking the records on the service side – that’s what I originally asked for.

In a nutshell – THAT DID NOT WORK

Specifically, what I did:

1. Reset Site Kit in the existing subfolder install
2. Deactivated and deleted the SiteKit Plugin
3. Backed up my existing subfolder install
4. Deleted the existing subfolder install
5. Restored the wordpress install that was on the root drive
6. Installed SiteKit and connected – everything loaded and connected fine
7. Reset Site Kit
8. Deactivated and deleted the Sit Kit plugin
9. Uninstalled WordPress
10. Restored my subfolder install
11. Installed Google SiteKit from scratch
12. Activated and tried to connect
13. BACK TO REDIRECTING TO MY WEBSITE

I’m no genius about this stuff, but it seems to me that the problem is the SiteKit plugin is pulling the location of the wp-admin file from the WordPress “Site Address” field instead of the “WordPress Address” field – because the address in my browser shows it’s going to the wrong place when it doesn’t work, and it connects just fine if you change the site address field to include the sub-folder in it – but that is not how I want the install to be.

In any event, I’m done moving wordpress files around. If this can’t be fixed, I’ll just give up on it.

• This reply was modified 1 year, 9 months ago by dfender.