After an Elementor 4.2.2 update, a custom addon can show the same top-bar control twice, attach duplicate click handlers, or register in one locale but not another. The visible duplicate may come from legacy and current editor hooks both running, the module bundle loading twice, a hot-reload or popup lifecycle, an addon bootstrap executing for two editor frames, or stale cached assets mixing versions. Hiding one copy with CSS leaves duplicate code and side effects active.
Use this for custom Elementor addons and integrations that add top-bar buttons, menus, panels, dynamic tags, form actions, or editor modules and behave differently after the 4.2.2 update.
Quick answer
Instrument the addon bootstrap and registration callback with a stable integration ID, module version, editor frame, locale, hook name, call count, DOM count, and stack trace. Load a clean editor with Elementor and Elementor Pro version parity, then compare the current hook path with any legacy fallback. Remove the duplicate registration source or add an idempotent guard at the integration boundary. Purge generated assets and CDN cache only after the code path is corrected.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
| Fresh editor | Current hooks | One registration |
| Legacy fallback | Compatibility path | Current path does not repeat |
| Second locale | Translated bundle | Same integration identity |
| Cached old asset | Version mismatch | Detected and purged after code fix |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
| Capture the registration lifecycle | Record Elementor core and Pro versions, WordPress version, addon commit, site locale, user locale, experiment state, editor type, and generated asset version. | Module load, registration callback, DOM control, and handler counts remain one per editor context. |
| Identify repeated hook or bundle | Instrument module load, hook subscription, registration callback, control insertion, handler attachment, iframe creation, and editor teardown with counts. | English and non-English user locales produce the same integration identity and behavior. |
| Add a stable idempotent guard | Test the addon alone, with default theme, across current and legacy editor paths, and with cache, optimization, and translation bundles cleared. | Elementor core, Pro, addon, generated assets, and CDN copies have version parity. |
| Align versions and rebuild assets | Compare English and non-English user locales because distinct bundles or translated initialization can reveal a second path. | Save, preview, navigation, and repeated editor sessions do not recreate the duplicate. |
What to check first
- Record Elementor core and Pro versions, WordPress version, addon commit, site locale, user locale, experiment state, editor type, and generated asset version.
- Instrument module load, hook subscription, registration callback, control insertion, handler attachment, iframe creation, and editor teardown with counts.
- Test the addon alone, with default theme, across current and legacy editor paths, and with cache, optimization, and translation bundles cleared.
- Compare English and non-English user locales because distinct bundles or translated initialization can reveal a second path.
- Open, close, navigate, save, preview, and reopen the editor while confirming one integration ID, one DOM control, and one handler.
Field notes
- Write the expected result before making a change and keep one repeatable canary fixture.
- Record versions and timestamps because release, cache, and delivery behavior can change between tests.
- Use one canonical owner page for each query family and give every supporting page a distinct task.
- Close the incident only after the public workflow and the downstream record both pass verification.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
console.count('addon:topbar:module-load');
console.count('addon:topbar:register');
console.table({
integrationId: 'agency-control',
addonVersion: 'git-a91',
userLocale: document.documentElement.lang,
domCount: document.querySelectorAll('[data-addon=agency-control]').length
});
Why this usually happens
- The addon subscribes to both an older editor hook and its replacement.
- The same compiled module is enqueued under two handles or frames.
- A registration callback runs on each navigation without teardown or a stable guard.
- Core and Pro or origin and CDN serve mismatched asset versions.
Decision rule
Do not use CSS to hide a duplicate control. Release only when one intended lifecycle registers one stable integration, attaches one handler, cleans up correctly, and remains single across locale and navigation changes.
Production verification checklist
- Module load, registration callback, DOM control, and handler counts remain one per editor context.
- English and non-English user locales produce the same integration identity and behavior.
- Elementor core, Pro, addon, generated assets, and CDN copies have version parity.
- Save, preview, navigation, and repeated editor sessions do not recreate the duplicate.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Capture the registration lifecycle
- Identify repeated hook or bundle
- Add a stable idempotent guard
- Align versions and rebuild assets
- Retest navigation and locale paths
Mistakes to avoid
- Changing production files, recipients, hooks, cache settings, or update policy before preserving the failing request and current configuration.
- Treating one warning, one successful test, or one dashboard status as a complete diagnosis without checking the next system in the path.
- Testing with a different account, order state, form embed, locale, plugin version, or cache state than the real failure.
- Publishing a new broad answer when an established owner already exists, which splits internal links and creates query overlap.
Questions teams ask during testing
Can I run this directly on production?
Read-only inspection is often appropriate on production when access is controlled and output is redacted. Make backups first, test state-changing steps on staging, define rollback, and schedule any production change for a monitored window.
How do I avoid a false positive?
Match the exact installed version, locale, request, order, form, role, cache state, and integration path. Repeat the same fixture after the fix and keep evidence from both runs.
What evidence should I keep?
Keep UTC time, site and plugin versions, request or record ID, command, expected result, actual result, relevant logs, configuration snapshot, change, rollback point, and final verification. Redact secrets and personal data.
When should a specialist take over?
Escalate when checkout, customer email, lead capture, security, payment state, production updates, or several plugins are affected, or when the safe next step is unclear. A short evidence packet saves time and limits guesswork.
What to tell the client or owner
Give the site owner a concise evidence packet containing the affected workflow, exact versions, UTC test time, fixture or record ID, expected and actual result, logs, change made, rollback point, final verification, owner, and next review date. Remove passwords, tokens, payment details, and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP debug the Elementor addon lifecycle.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references