trueqap

Hi Milos,

Thank you for your response, but unfortunately none of the suggestions are applicable to my situation. Let me explain why, along with technical evidence from the Elementor 3.34.2 source code. My Test Environment (Reminder)

• Fresh WordPress installation (not an upgrade)
• Elementor 3.34.2 only – no other plugins
• Default theme – no third-party theme
• Data Sharing: OFF (default setting)

Why Your Suggestions Don’t Apply 1. “Caching / CDN”

“Sometimes cached scripts from before the update continue to load”

This is a fresh WordPress installation. There is:

• No previous Elementor version to cache
• No CDN configured
• No browser cache (first visit after install)

On a fresh install, there are no “old scripts” that could be cached. 2. “Plugins or theme integrations”

“Some third-party Elementor addons or themes may include legacy Elementor code”

My test has:

• Only Elementor installed – zero other plugins
• Default WordPress theme – no third-party theme

With only Elementor installed, there is no third-party code that could be responsible. The Mixpanel code is bundled directly in Elementor’s own common.js file. 3. “Staging / old script remnants”

“Check if your site is running old versions of Elementor JS/CSS”

This is a fresh installation – the /uploads/elementor folder was created by this very installation. There are no “remnants” because no previous version was ever installed. 4. “Incorrect version or update issue”

“Confirm that Elementor is fully updated”

I explicitly stated version 3.34.2 in my original report. This is not an update issue – the problem exists in the current version’s source code. Technical Evidence From Elementor 3.34.2 Source Code

I’ve examined the actual source code. Here’s what I found: Evidence 1: Hardcoded Mixpanel Token

File: elementor.php (lines 47-49)

if ( ! defined( 'ELEMENTOR_EDITOR_EVENTS_MIXPANEL_TOKEN' ) ) {
    define( 'ELEMENTOR_EDITOR_EVENTS_MIXPANEL_TOKEN', '150605b3b9f979922f2ac5a52e2dcfe9' );
}

This token is always defined, regardless of the Data Sharing setting. Evidence 2: Token is Always Sent to JavaScript

File: core/common/modules/events-manager/module.php (line 46)

$settings = [
    'can_send_events' => $can_send_events,
    // ...
    'token' => ELEMENTOR_EDITOR_EVENTS_MIXPANEL_TOKEN,  // Always included!
    // ...
];

Even when can_send_events is false, the Mixpanel token is still passed to the JavaScript configuration. Why expose this token to the client-side when tracking is disabled? Evidence 3: Mixpanel Library is Always Bundled

File: assets/js/common.js

The full Mixpanel library (~10,000 lines of code) is bundled into common.js and loaded on every admin page, regardless of whether tracking is enabled.

While the code does check canSendEvents() before initializing Mixpanel:

if (!this.canSendEvents()) {
    return;
}
_mixpanelBrowser.default.init(...)

The library itself is still downloaded and parsed by every user’s browser, adding unnecessary overhead for users who have opted out. Evidence 4: No Cleanup When Users Opt Out

This is a critical issue. The sessionStorage entries (mp_tab_id_mixpanel_*, mp_gen_new_tab_id_mixpanel_*) are created when tracking is enabled. However, when a user disables Data Sharing, there is no cleanup code to:

• Remove existing sessionStorage entries
• Clear the Mixpanel state
• Delete any previously stored tracking data

This means if tracking was ever enabled (even briefly, perhaps during onboarding), the data persists indefinitely. Evidence 5: Enabled by Default for New Sites

File: core/common/modules/events-manager/module.php (lines 63-66)

'new_site' => [
    'default_active' => true,
    'minimum_installation_version' => '3.32.0',
],

The editor_events experiment is enabled by default for all new sites since version 3.32.0. Combined with the lack of cleanup on opt-out, this is concerning. Evidence 6: Potential Bypass During Onboarding

File: assets/js/onboarding.*.bundle.js (line 3471)

if (isTrackingOptedInConnect) {
    elementorCommon.config.editor_events.can_send_events = true;
}

There appears to be code that can set can_send_events = true during the onboarding/connection flow. This could potentially initialize Mixpanel even if the user hasn’t explicitly enabled Data Sharing in settings. My Questions

1. Why is the Mixpanel token always passed to JavaScript, even when Data Sharing is disabled?
2. Why is the full Mixpanel library bundled for all users, instead of lazy-loading it only when needed?
3. Why is there no cleanup mechanism when users disable Data Sharing?
4. Can Mixpanel be initialized during onboarding before the user has a chance to review the Data Sharing setting?
5. Why was this Mixpanel integration not mentioned in any changelog?

Summary

Milos, with respect, the issue is not with caching, third-party plugins, or old remnants. The concerns are with Elementor’s implementation:

• Mixpanel token is hardcoded and always exposed to client-side JavaScript
• Mixpanel library (~10,000 lines) is bundled and loaded for all users
• No cleanup exists when users opt out
• The experiment is enabled by default for new installations
• Possible tracking initialization during onboarding flow
• None of this was documented in the changelog

I would appreciate a technical response from the development team addressing these specific points, rather than generic troubleshooting suggestions.

Thank you for your time.

References:

• WordPress.org thread: https://wordpress.org/support/topic/usage-tracking-even-when-data-sharing-is-off-3-34-0/
• Elementor version: 3.34.2
• Files examined: elementor.php, core/common/modules/events-manager/module.php, includes/tracker.php, assets/js/common.js, assets/js/onboarding.*.bundle.js

• This reply was modified 2 months, 4 weeks ago by trueqap.
• This reply was modified 2 months, 4 weeks ago by trueqap.