t.every is not a function
Bug Description
There have been 2 reports in the support forums of the below error:
t.every is not a function
This have occurred since Site Kit 1.122.0
t.every is not a function</p> <pre class=”wp-block-code”><code>in WidgetNull in WithWidgetSlug(WidgetNull) in WhenAdsenseActive(ModuleOverviewWidget) in div in WidgetRenderer in div in WidgetCellWrapper in div in Row in div in div in Grid in WidgetAreaRenderer in div in WidgetContextRenderer in DashboardMainApp in DashboardEntryPoint in RestoreSnapshots in ErrorHandler in ThemeProvider in StrictMode in Root
We don't have any further insights into this at this stage. Reports of this in the support forums below:
- https://wordpress.org/support/topic/issue-after-update-version-1-122-0/ | No SH info
- https://wordpress.org/support/topic/site-kit-encountered-an-error-121/ | No SH info
Steps to reproduce
Unable to reproducible so far.
Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance criteria
Implementation Brief
- [ ]
Test Coverage
QA Brief
Changelog entry
Sharing some findings here along with this screenshot from support of the error happening in the settings screen
There are only a few places where we use the referenced function, but this error indicates the isZeroReport for GA4 which would be checked in the conditions for surfacing key metrics.
https://github.com/google/site-kit-wp/blob/4dd03daf87ee7718e08a5de1abc5714704d5b321/assets/js/modules/analytics-4/utils/is-zero-report.js#L41
I also see it referenced in the recently added GA4AdSenseLinkedNotification in a way that could perhaps also trigger the error since this is invoked everywhere the header is. cc @tofumatt
https://github.com/google/site-kit-wp/blob/4dd03daf87ee7718e08a5de1abc5714704d5b321/assets/js/components/notifications/GA4AdSenseLinkedNotification.js#L149-L154
We should generally audit all uses of .every as there really aren't that many.
The component trace shared above indicates an error happening on the main dashboard, but hard to say from where. It seems AdSense is not active though despite the reference (also supported by Site Health in one case).
I was unable to reproduce this. From the stack trace, it seems like the error is coming from isZeroReport function of analytics-4 module. My assumption is that there was a period of time when API was returning a non-array value for the report.totals, and besides doing some defensive programming by explicitly checking if report.totals is an array before calling every. there's nothing more to be done.
What do you think @aaemnnosttv?
@kuasha420 @aaemnnosttv I have actually by chance just come across this on one of our test sites https://test.cmsdevrel.info/. I have added you both as admins to the site if you'd like to check this further to see if you can gather anymore information on this.
Oh lovely, I'll definitely have a look. @adamdunnage!
@kuasha420 would it be possible to add a time estimate to this one please?
We generally add the estimate in IB phase, but this is a straightforward one, and a 7 seems like a good guestimate @binnieshah
AC ✔️
We should be able to check that every is available by using report?.totals?.every?.( isEmpty ) instead of adding an additional check, which will be a bit harder to read here. Is there any reason that wouldn't work @zutigrm?
@tofumatt Ah indeed, you are right. Not sure why I went with longer route. IB updated
@zutigrm No worries, I probably would have done the same if I were writing the IB! 😅
IB ✅
QA Update: ❌
@benbowler I have logged into the site mentioned above (test.cmsdevrel.info/) and could recreate the error in the ticket. I then enabled the tester plugin and switched to the develop branch (with Site Kit 1.129.1) and the error below appears, when I go to the Site Kit Dashboard. I cleared application local and session storage and also cleared cache but it still existed.
An error occurred while running 'mapSelect': e.totals.some is not a function
The error may be correlated with this previous error:
TypeError: e.totals.some is not a function
at o (https://test.cmsdevrel.info/wp-content/plugins/google-site-kit/dist/assets/js/googlesitekit-main-dashboard-8975c9b23f11eff07385.js:44:10069)
at w.hasZeroData (https://test.cmsdevrel.info/wp-content/plugins/google-site-kit/dist/assets/js/googlesitekit-modules-analytics-4-18c762efc16b5c1dfd80.js:118:43655)
at t (https://test.cmsdevrel.info/wp-content/plugins/google-site-kit/dist/assets/js/googlesitekit-vendor-f47597c85a9101ec1e31.js:7:35042)
at https://test.cmsdevrel.info/wp-content/plugins/google-site-kit/dist/assets/js/googlesitekit-vendor-f47597c85a9101ec1e31.js:7:494158
at Object.n [as hasZeroData] (https://test.cmsdevrel.info/wp-content/plugins/google-site-kit/dist/assets/js/googlesitekit-vendor-f47597c85a9101ec1e31.js:7:493724)
at Object.current (https://test.cmsdevrel.info/wp-content/plugins/google-site-kit/dist/assets/js/googlesitekit-main-dashboard-8975c9b23f11eff07385.js:74:15765)
at e (https://test.cmsdevrel.info/wp-content/plugins/google-site-kit/dist/assets/js/googlesitekit-vendor-f47597c85a9101ec1e31.js:7:182286)
at https://test.cmsdevrel.info/wp-content/plugins/google-site-kit/dist/assets/js/googlesitekit-vendor-f47597c85a9101ec1e31.js:7:182448
at https://test.cmsdevrel.info/wp-content/plugins/google-site-kit/dist/assets/js/googlesitekit-vendor-f47597c85a9101ec1e31.js:7:498460
at Array.forEach (<anonymous>)
Original stack trace:
in ZeroDataStateNotifications
in BannerNotifications
in div
in Header
in DashboardMainApp
in DashboardEntryPoint
in RestoreSnapshots
in ErrorHandler
in ThemeProvider
in StrictMode
in Root
@benbowler @adamdunnage an odd one this. I logged back into the site and noticed the plugin was on the latest version 1.129.1. I then went to the Site Kit dashboard and after a second the error message appeared An error occurred while running 'mapSelect': t.every is not a function I then enabled the tester plugin and switched to the develop branch and this error appeared, An error occurred while running 'mapSelect': e.totals.some is not a function I am logging in with Adam's admin account. I am using Chrome (126.0.6478.63) and I am on MacOS Sonoma 14.5. I am baffled why you cannot see the same. Screencast below.
https://github.com/google/site-kit-wp/assets/73545194/1f426d88-611f-4b09-8d6a-68856ff0524c
Updating here from my investigation based on the recurring issue. I managed to catch the report in the debugger and the reason this error happens is actually due to the totals row (and actually all arrays in the report) being returned as numerical keyed objects instead of arrays, and the zeroth element is empty in totals.
I've created a PR that addresses this case.
It looks like the structure of GA reports has changed and arrays are now returned as objects with numeric keys, my evidence for this is the tests in assets/js/modules/analytics-4/utils/is-zero-report.test.js which all use standard arrays.
It looks to me like JSON_FORCE_OBJECT is now being applied to json_encoded output, or similar. I can't find any documentation on a change of behaviour of wp_json_encode or json_encode and we don't explicitly pass this flag in our codebase. It could be a change on the GA side.
It's worth keep an eye on this across the app incase this effects other uses of analytics reports.
QA Update: ❌
@benbowler when I refresh the site to the develop branch, I now see an error in the All traffic widget.
Error message is:
Invalid attempt to destructure non-iterable instance. In order to be iterable, non-array objects must have a [Symbol.iterator]() method.
@benbowler Actually, yeah, the change in #8931, come to think of it, doesn't make sense, because in a lot of other places were are expecting totals to be an array: https://github.com/google/site-kit-wp/blob/e46b360a0f353f0d41e263e6c4989b0f5e4433f2/assets/js/modules/analytics-4/components/dashboard/DashboardAllTrafficWidgetGA4/TotalUserCount.js#L90
If it's not, and that's an expected behaviour of the GA4 API, we should probably file an explicit issue about it because that's a more significant change. I wonder if we should revert the existing change or something for now? 🤔
Ok, based on a deeper dive here, I have found that the issue in this test site is the Transliterator plugin. When enabled this plugin is parsing the JSON output for the report endpoint (and likely others), updating arrays to numerical keyed objects:
"totals":[{}]
becomes:
"totals":{"0":{}}
There are a couple of ways to go here including raising a request/submitting a fix to the external plugin or attempting to use a hook on the SK side to revert this structural change.
As the two original PRs were treating a symptom and not the cause, and they did not fix the issue, I've created a third PR to revert these changes to keep the code base clean.
We should discuss the above and decide on the best cause of action, likely bringing the ticket back to IB.
I created a topic here on the Transliterator plugin support page.
We should discuss the above and decide on the best cause of action, likely bringing the ticket back to IB.
I'm not really sure there's anything for us to do. I don't want us to revert that plugin's behaviour in a game of cat-and-mouse 😅
Really we should display a warning if that plugin is installed, but that's about it.
But we shouldn't try to fix that other plugin's bad behaviour, we should just warn users of the incompatibility. 🤔
I'm removing this issue from the sprint/release and back to ACs, but I don't think we have any compatibility warning messages like that… so we might want to ask @sigal-teller for a design 🤔
I've modified the issue contents and the ACs here, because the only thing we can really do here is warn the user that the Transliterator plugin causes issues and should be disabled.
I'm not sure we want to do that, as we'll also need to display a message once there is an upstream fix informing users who have seen the message that it's been fixed… so maybe we want to log that the user saw the notice. 🤔
Leaving this in ACR for others to look over and see if they're cool with this approach.
Thanks @tofumatt. We should avoid raising plugin-specific warnings (and adding the necessary infrastructure to detect them) as the problem could be fixed in a future version of the plugin, or be more nuanced such as dependent on a particular setting (which I've seen with this kind of rest response manipulation) so we wouldn't want to flag a problem that might not exist based on presence alone. Instead, let's keep the error/messaging focused on what we know: the response from the backend returned a format different than expected which could happen for different reasons. We can then include to a get help link to our docs where we can reference known causes for this, such as plugin specific conflicts, settings, etc. Leaking plugin-specific implementation details into some kind of detection on our end will be fragile at best to maintain so let's fast forward past the trial and error there and stick to providing more objective future-proof feedback with added context + guidance via support.
Closing this issue out since it's already gone through the full cycle and the changes have already been reverted. @tofumatt please open a new issue for any follow-up here as we're essentially starting fresh.
Hello,
My name is Ivijan-Stefan, I'm author of the plugin and just saw this problem today, it would be good to look together where Transliterator causing problems and find some solution.
For first aid, you can turn off the "Force transliteration for WordPress REST API" option in the plugin, if you don't need it.
Thanks!
Hey @InfinitumForm, thanks for coming back to us. I can look at this at my next hackathon. I've sent you an email to the address on your website to work together.
Hey @InfinitumForm, I don't have time to work on this directly unfortunately as the issue is in your plugin rather than on Site Kit side. We've had a look though your plugins code though and the issue is in your transliterate_objects function in Global.php, the way you cast objects to arrays then back to objects will cause arrays within objects to be converted to indexed objects breaking the original API structure.
Thanks a lot for this, I will look into this problem and fix it. We just released a new version of the plugin a week ago, we finally switched from that mutant to a completely new code. I will fix the problems and solve. Thanks again!