site-kit-wp: Request parameter is empty: accountID
Bug Description
One user in the support forums is encountering the below error when connecting the Analytics module, specifically after selecting an account:
Request parameter is empty: accountID
This has been occurring with a subdomain setup only.
Console errors when issue occurs:
jquery-migrate.min.js?ver=3.3.2:2 JQMIGRATE: Migrate is installed, version 3.3.2
jquery.min.js?ver=3.5.1:2 jQuery.Deferred exception: jQuery(...).live is not a function TypeError: jQuery(...).live is not a function
at HTMLDocument.<anonymous> (https://th.cnx-software.com/wp-content/plugins/bwp-recent-comments/js/bwp-rc-widget.js?ver=5.6.1:1:69)
at e (https://th.cnx-software.com/wp-includes/js/jquery/jquery.min.js?ver=3.5.1:2:30005)
at t (https://th.cnx-software.com/wp-includes/js/jquery/jquery.min.js?ver=3.5.1:2:30307) undefined
S.Deferred.exceptionHook @ jquery.min.js?ver=3.5.1:2
jquery.min.js?ver=3.5.1:2 Uncaught TypeError: jQuery(...).live is not a function
at HTMLDocument.<anonymous> (bwp-rc-widget.js?ver=5.6.1:1)
at e (jquery.min.js?ver=3.5.1:2)
at t (jquery.min.js?ver=3.5.1:2)
/wp-json/google-site-kit/v1/modules/analytics/data/properties-profiles?accountID=2022395&_locale=user:1 Failed to load resource: the server responded with a status of 400 ()
googlesitekit-api.c3305021ff3630c5df8d.js:1 Google Site Kit API Error Objectcode: "missing_required_param"data: status: 400__proto__: constructor: ƒ Object()hasOwnProperty: ƒ hasOwnProperty()isPrototypeOf: ƒ isPrototypeOf()propertyIsEnumerable: ƒ propertyIsEnumerable()toLocaleString: ƒ toLocaleString()toString: ƒ toString()valueOf: ƒ valueOf()__defineGetter__: ƒ __defineGetter__()__defineSetter__: ƒ __defineSetter__()__lookupGetter__: ƒ __lookupGetter__()__lookupSetter__: ƒ __lookupSetter__()get __proto__: ƒ __proto__()set __proto__: ƒ __proto__()message: "Request parameter is empty: accountID."__proto__: constructor: ƒ Object()hasOwnProperty: ƒ hasOwnProperty()isPrototypeOf: ƒ isPrototypeOf()propertyIsEnumerable: ƒ propertyIsEnumerable()toLocaleString: ƒ toLocaleString()toString: ƒ toString()valueOf: ƒ valueOf()__defineGetter__: ƒ __defineGetter__()__defineSetter__: ƒ __defineSetter__()__lookupGetter__: ƒ __lookupGetter__()__lookupSetter__: ƒ __lookupSetter__()get __proto__: ƒ __proto__()set __proto__: ƒ __proto__()
(anonymous) @ googlesitekit-api.c3305021ff3630c5df8d.js:1
Steps to reproduce
- Setup Site Kit on a subdomain site (having previously setup Site Kit successfully on parent domain)
- Attempt to connect the Analytics module - choosing an existing account in the dropdown during setup
- Error appears
Screenshots
The screenshot below shows what occurs only once an account is selected (a snapshot from this video kindly provided by the impacted user)
Additional Context
- Site URL: https://th.cnx-software.com
- Site Health information provided
- No issues with parent domain
- Only occurs with some Analytics accounts and not others
- User has full administrator access at Analytics level
- Occurs with no plugins active other than Site Kit via Health Check & Troubleshooting plugin (evident from video above).
- One previous similar topic opened, possibly a conflict with another Analytics plugin
- Previous similar issue reported, also on NGinx server, since resolved
- No existing Analytics snippet exists on site
Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance criteria
Implementation Brief
Test Coverage
Visual Regression Changes
QA Brief
Changelog entry
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 25
@aaemnnosttv Yes, that was it. I compared my nginx configuration files, and in the websites with the issue, it was configured as follows:
location / { # This is cool because no php is touched for static content try_files $uri $uri/ /index.php;
}`I’ve changed it to
location / { # This is cool because no php is touched for static content try_files $uri $uri/ /index.php?$args; }
and the issue is now solved. Sorry about the troubles, and thanks for your help.Thanks for sharing @cnxsoft – that would definitely do it, glad things are back to normal for you 👍
Closing this one out as a non-issue for the plugin.