digitalpoint
Well-known member
Maybe a bug, but more probably, you enabled the user group permission,
Do not track with Google Analytics for your user group (it’s off by default).
![[DigitalPoint] Better Google Analytics](/community/data/resource_icons/8/8752.jpg?1653152083){kind=icon}
[DigitalPoint] Better Google Analytics 1.1.2.3
- Thread starter digitalpoint
- Start date
Stuart Wright
Well-known member
Thank you. Set to No for the group but set to Yes for me in user level permissions.
The only way that could happen is by doing a blanket Yes for admin permissions for me at some point after Better Analytics was installed.
Which is unlikely, but the most feasible explanation.
Because I would never deliberately set that specific permission to Yes.
This solves a mystery going back more than a year.
Nice one
edit, fixed nginx with this code:
Date presets in the admincp do not function still. anyone else notice this? on 2 different sites/servers. one nginx, one litespeed
seeing this in the console:
Code:
location ~ ^/jc/gtm.js {
try_files $uri /index.php?$uri&$args;
}Date presets in the admincp do not function still. anyone else notice this? on 2 different sites/servers. one nginx, one litespeed
seeing this in the console:
Last edited:
digitalpoint
Well-known member
You don't normally need to do that unless you have an (arguably) poorly configured web server setup that is blindly intercepting .js requests without checking if the file actually exists or not.
The above will tell your web server to not intercept that specific request, but a better solution is to have your web server not intercept .js requests if the file doesn't exist in the filesystem.
Whatever section of your Nginx config is intercepting .js requests, it probably makes sense to utilize the
try_files directive to check if they actually exist. It's what you are doing in the above block, but you are only making that work for /jc/gtm.js... I can't think of a situation where you would need to do things like override cache-control (or other headers) for files that don't exist in the filesystem.TL;DR: if a file doesn't exist in the filesystem, you are better off passing that request along to XenForo (in all cases).
Disable debugging in your browser. Or more specifically, disable JavaScript source maps in your browser debugging settings. Also, Chartist is a XenForo thing, so if you want XenForo to start shipping with debugging source maps, you would need to ask them (again, chartist isn't coming from this addon, rather it's just using the charting library that XenForo ships with).
I'm using the standard nginx.conf file from the xf documentation.
There is not a jc/folder on my server, i cannot find a gtm.js file at all. So i'm not sure what's actually going on.
I disable the map option as above, no changes. It's always the past month. Every submit goes back one day.
View attachment Screen Recording 2025-10-15 155330.mp4
There is not a jc/folder on my server, i cannot find a gtm.js file at all. So i'm not sure what's actually going on.
I disable the map option as above, no changes. It's always the past month. Every submit goes back one day.
View attachment Screen Recording 2025-10-15 155330.mp4
digitalpoint
Well-known member
99.9% hour web server has a rule to intercept anything with .js extension.
Ya not sure… as I said, Chartist is part of XenForo.
digitalpoint
Well-known member
Not sure... are you using the latest version of XenForo? Looks like it was an issue that was fixed, but way back in XenForo 2.1. I'm not able to replicate it on my sites.
As far as the .JS thing, you can test to see if it's your web server or not by checking a random URL with a .js exension. For example:
This yields as XenForo error (not a web server error), so you know the web server routed the request to XenForo:
If you try your site with test.js, and you get a XenForo error, you know the web server is configured properly. If you get a web server error, the web server is NOT routing requests as it's supposed to.
Yes, i have 2.3.7.
test.js goes to nginx 404 page.
This is the exact file i have
https://xenforo.com/docs/xf2/friendly-urls/#nginx straight from xf resources, with the path changed to match mine. That's it.
going from XF charts that work, to this addon that don't, live.
no js errors thrown.
View attachment Screen Recording 2025-10-15 182649.mp4
XF's change onChange. this addon, i have to press the submit button. Something is missing js related.
test.js goes to nginx 404 page.
This is the exact file i have
https://xenforo.com/docs/xf2/friendly-urls/#nginx straight from xf resources, with the path changed to match mine. That's it.
going from XF charts that work, to this addon that don't, live.
no js errors thrown.
View attachment Screen Recording 2025-10-15 182649.mp4
XF's change onChange. this addon, i have to press the submit button. Something is missing js related.
digitalpoint
Well-known member
You have another part of your Nginx config that's affecting it. The XenForo config is additive to the rest of your Nginx config (meaning it adds to the config, it doesn't override everything else already there). The fact that the request never makes it to XenForo shows that the web server is deciding to intercept it and handle the request on it's own. If the web server was routing the request to XenForo, you'd see a XenForo error (like the link I posted above to this site). Probably best to talk to your server admin/whoever manages Nginx on the server.
...or just leave it if you don't care. I mean you have it working for this I guess. Personally, I'd try to fix the root of the issue rather than do one-off fixes for each URL though.
digitalpoint
Well-known member
The dropdown is a different thing… 2.3 compatibility issues. Fixed for next version.turns hat around HISys admin here.
I'm running centmin. I'll ping Eva on it to see if he has ideas.
Also, it does the same thing on the other site i'm working on , which is running litespeed with stock htaccess. The dropdown doesn't submit.
digitalpoint
Well-known member
Did you by chance instead a new version of PHP? Specifically one that now has Sodium support where your old version didn’t?
When the addon is installed, it generates an encryption key if Sodium is supported. If it’s not supported when it’s installed, the encryption key can’t be created.
If thats the case, the easiest thing to do would be to reinstall the addon. Or if you have CLI access, you can just rerun the setup for the addon.
digitalpoint
Well-known member
Well somehow your
baAnalyticsKey option went missing or got corrupt somehow (assuming Sodium was installed and working when you installed the addon). You can run this query to see what the value is:
SQL:
SELECT * FROM xf_option WHERE option_id = 'baAnalyticsKey' LIMIT 1;option_value should be exactly 32 characters (anything else will cause the problem you see).
digitalpoint
Well-known member
Another possibility would be some sort of corruption going on if you are using a cache for XenForo (for example Redis or Memcached) where options are being read from there rather than the database and it's returning incorrect data. That seems rather far fetched though... just throwing out random possibilities. Somehow, for whatever reason, the encryption key isn't 32 bytes when it's being used. 
digitalpoint
Well-known member
Yep, not sure... like I said, at the most basic level, the encryption key isn't 32 bytes when it goes to be used (for whatever reason). Don't know anything about your site or what other addons or server software you are running, so can't really offer much else as far as ideas as to why. If it was something widespread, you'd see it on your other sites and I'm sure someone else would be posting here about it. So whatever it is seems to be unique to that particular site somehow.
