Elementor's newer Home experience unifies WordPress admin navigation, and Elementor notes that mixed versions of Elementor Editor and other Elementor plugins can display duplicate menu sections. CSS that hides one menu or a role-editor rule may conceal the symptom while package versions, asset manifests, or registration hooks remain inconsistent. The fix needs a complete plugin-family inventory and a supported update or rollback set, followed by cache and role verification.
Use this when WordPress admin shows two Elementor sections, menu items move after an update, one role sees duplicates while another does not, or Core, Pro, Site Mailer, Ally, or add-ons were updated at different times.
Quick answer
Record the exact Elementor Core, Pro, and related Elementor plugin versions plus active add-ons and update timestamps. Check whether the duplicate began during a partial or failed update. Back up and stage the same package family, then update all supported Elementor plugins to compatible current versions or roll the family back to the last known-good set. Clear opcode, object, admin, CDN, and browser caches. Test administrator and editor roles, Elementor Home, Templates, editor launch, publish, and the public page. Remove temporary menu-hiding code after package parity is restored.
What to check first
- Export every Elementor and Elementor-related plugin name, version, activation state, update source, install path, and last update time.
- Review failed updates, maintenance mode, filesystem writes, duplicate plugin folders, opcode cache, object cache, and admin asset versions.
- Search theme, mu-plugin, role editor, white-label, and custom admin code for menu registration or removal hooks.
- Build one compatible package set on staging, then test administrator and editor menus before and after cache purge.
- Verify Elementor Home, Templates, editor, responsive preview, publish, public output, forms, and logs before production rollout.
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 |
|---|
| Aligned current set | Core, Pro, related plugins compatible | One unified menu |
| Mixed versions | Core current, related plugin old | Duplicate reproduced |
| Role difference | Administrator and editor | Expected capability-based items only |
| Rollback set | Last known-good family | One menu and editor pass |
Decision rule
Do not keep CSS or capability hacks as the primary fix. Close the issue when the supported plugin family is aligned and each role receives one coherent menu from the expected registrations.
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.
- Inventory the full Elementor package family
- Choose a compatible update or rollback set
- Remove duplicate package paths
- Purge executable and admin caches
- Test roles, editor, publish, and public output
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Inventory the full Elementor package family | Export every Elementor and Elementor-related plugin name, version, activation state, update source, install path, and last update time. | Elementor Core, Pro, and related plugins use a supported compatible set. |
| Choose a compatible update or rollback set | Review failed updates, maintenance mode, filesystem writes, duplicate plugin folders, opcode cache, object cache, and admin asset versions. | No duplicate plugin directory or stale admin asset remains. |
| Remove duplicate package paths | Search theme, mu-plugin, role editor, white-label, and custom admin code for menu registration or removal hooks. | Administrator and editor roles see the intended single menu structure. |
| Purge executable and admin caches | Build one compatible package set on staging, then test administrator and editor menus before and after cache purge. | Elementor Home, Templates, editor, publish, public pages, forms, and logs pass. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp plugin list --fields=name,status,version,update,auto_update | grep -Ei 'elementor|site-mailer|ally'
find wp-content/plugins -maxdepth 1 -type d -iname '*elementor*' -print
# Compare package and asset versions before clearing caches.
Production verification checklist
- Elementor Core, Pro, and related plugins use a supported compatible set.
- No duplicate plugin directory or stale admin asset remains.
- Administrator and editor roles see the intended single menu structure.
- Elementor Home, Templates, editor, publish, public pages, forms, and logs pass.
Why this usually happens
- Automatic updates complete for one Elementor package while another remains pending or fails.
- A duplicate or renamed plugin folder loads stale code beside the active package.
- Opcode, object, or browser cache retains old admin assets after files change.
- Custom menu-hiding code masks the symptom and later conflicts with the unified navigation.
Field notes
- Write the expected result before changing anything and keep one repeatable canary fixture for the full test window.
- Record exact versions and UTC timestamps because caches, retries, scheduled actions, and deployments can change the evidence between checks.
- Test the public browser path and the stored server-side result, not only an admin preview or isolated API response.
- Close the task only after the visible workflow, logs, stored record, and relevant downstream system agree.
Mistakes to avoid
- Changing production before recording the exact version, request, UTC time, fixture, and rollback point.
- Treating one successful browser view as proof while logs, stored records, background jobs, and downstream systems remain unchecked.
- Testing a different role, cache state, locale, form, order, device, or integration path from the one users actually reach.
- Leaving debug output, temporary exclusions, test accounts, broad permissions, or helper code active after the verification window.
What to tell the client or owner
Give the owner a concise evidence packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key logs, change made, rollback point, final result, owner, and next review date. Remove credentials and personal data before sharing it.
Questions teams ask during testing
Should I test this directly in production?
Start with read-only evidence and reproduce on staging when the change affects code, security, checkout, forms, indexing, or permissions. If production is required, use one named canary, a short monitored window, and a tested rollback.
How do I avoid a false positive?
Repeat the same fixture with the same versions, URL, role, locale, cache state, and downstream integration. Compare stored evidence and logs instead of relying on a visual impression.
What evidence should I keep?
Keep UTC time, exact versions, URL or record ID, expected result, actual result, relevant log lines, change made, rollback point, owner, and final verification. Redact credentials and personal data.
When should I escalate?
Escalate when the site is unavailable, security scope is unclear, checkout or lead capture is affected, several systems disagree, or the next action could destroy evidence.
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 align and verify Elementor updates.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references