Summary
Neve palette colors remain visible in Elementor's global-colors collection, but an individual Neve color lookup returns global_not_found. The individual endpoint is expected to return the selected Neve palette color so Elementor can retain declarations that reference it. Instead, CSS regeneration omits color-bound declarations, which can remove button, border, and section colors from the frontend while the editor still looks correct.
Customer context
- Product / area: Neve Elementor compatibility, global colors REST integration
- Version: Neve 4.2.13; Neve Pro Addon 3.2.11
- Environment: WordPress 7.1.2; PHP 8.5.9; LiteSpeed; MariaDB 10.6; child theme active
- Integration / third party: Elementor 4.3.1 with Elementor Pro 4.3.0; also reported with Elementor 3.34.4 and Elementor Pro 3.34.3
- Reported error / symptom:
/elementor/v1/globals/colors/nvprimaryaccent returns 404 with global_not_found, while the globals collection includes nvprimaryaccent
- Impact: Regenerated Elementor CSS omits declarations bound to Neve global colors, causing visible frontend styling loss. A child-theme filter was reported as a working temporary workaround.
Reproduction notes
Reported reproduction:
- Use Neve 4.2.13 with Elementor and assign Neve global colors to Elementor controls.
- Request
/wp-json/elementor/v1/globals and observe the Neve colors in the collection.
- Request
/wp-json/elementor/v1/globals/colors/nvprimaryaccent and observe HTTP 404 with global_not_found.
- Regenerate Elementor files and data.
- Inspect the generated Kit CSS and frontend; declarations bound to the Neve global are absent while hardcoded values remain.
The customer reports the same result after rolling Elementor back from 4.3.x to 3.34.x. Local end-to-end reproduction was not performed; source and release-history inspection confirm the failing Neve branch.
Diagnosis
Conclusion
The defect is confirmed in Neve. For a single Neve color route, Elementor::alter_global_colors_front_end() returns any incoming WP_Error before it inspects whether the requested ID belongs to Neve. The customer observed Elementor returning global_not_found for that ID, so the Neve response-construction path is unreachable. Commit 38126e48a6b9b5d7a4532b555dec9a7c28a77b95, released in 4.2.12, introduced this early return; 4.2.11 lacks it and 4.2.13 retains it, establishing a regression.
Where this likely occurs
- Elementor global-color REST compatibility:
inc/compatibility/elementor.php — Elementor::init() lines 61-73 registers both REST-response filters when Elementor is active.
- Single-color resolution:
inc/compatibility/elementor.php — Elementor::alter_global_colors_front_end() lines 142-179 returns at lines 143-145 on any WP_Error, before matching known Neve IDs at lines 147-169 and constructing the palette response at lines 171-178.
- Globals collection:
inc/compatibility/elementor.php — Elementor::alter_global_colors_in_picker() lines 190-231 independently adds Neve palette colors to /elementor/v1/globals, explaining why collection and individual lookups disagree.
- Regression history: commit
38126e48a6b9b5d7a4532b555dec9a7c28a77b95 added the error guard and tests; it is contained in tags v4.2.12 and v4.2.13, but not in v4.2.11. CHANGELOG.md lines 5-19 records the 4.2.12 Elementor error-response change.
Engineering notes
The 4.2.12 change closed issue #4559, where a WP_Error from the collection endpoint caused a fatal call to get_data(). The newly reported behavior concerns the separate single-color callback: an error can be the expected upstream response for a Neve-injected ID unknown to Elementor, while Neve owns the mapping and palette value. The inspected integration lives entirely in the free Neve theme; no matching handler was found in Neve Pro Addon. Elementor source is not present in the workspace, so its CSS-generator behavior is supported by the customer's endpoint observations, generated-CSS comparison, and working workaround rather than local dependency inspection.
Test coverage status
tests/test-elementor-compatibility.php contains unit coverage for both REST callbacks. TestElementorCompatibility::test_global_colors_front_end_passes_through_wp_error() lines 52-61 uses a rest_forbidden error and requires all single-color errors to pass through. TestElementorCompatibility::test_global_colors_front_end_overrides_color() lines 78-91 only verifies substitution when the incoming response is already successful. The suite does not cover a global_not_found response for a known Neve-owned color ID. The targeted PHPUnit file could not be run because phpunit is unavailable in the environment.
What to verify or explore next
- Reproduce the individual lookup and CSS regeneration with Neve 4.2.11, 4.2.12, and 4.2.13 against the reported Elementor version pairs.
- Exercise the existing Elementor compatibility PHPUnit suite with
global_not_found for a known Neve ID, an unknown ID, and authorization-related errors.
- Confirm whether all built-in and custom Neve palette IDs follow the same individual-lookup path.
- Verify CSS output for controls referencing Neve globals after Elementor's
Regenerate Files & Data workflow.
Unknowns / follow-up
- Elementor's internal single-global resolution and CSS-generation source was not available in the workspace.
- The report demonstrates the failure for
nvprimaryaccent; the remaining built-in and custom IDs were not runtime-tested here.
Confidence
Confidence: 98/100
The reported 404 is directly explained by a Neve 4.2.12 guard that returns Elementor's error before Neve resolves its own color ID; git history proves the behavior was introduced after 4.2.11 and remains in 4.2.13. No matching open issue was found.
Source: HelpScout #3461723835
Generated by bug-report-triage (ID: bug-report-triage_6ab54922aa1192.25004359)
Summary
Neve palette colors remain visible in Elementor's global-colors collection, but an individual Neve color lookup returns
global_not_found. The individual endpoint is expected to return the selected Neve palette color so Elementor can retain declarations that reference it. Instead, CSS regeneration omits color-bound declarations, which can remove button, border, and section colors from the frontend while the editor still looks correct.Customer context
/elementor/v1/globals/colors/nvprimaryaccentreturns 404 withglobal_not_found, while the globals collection includesnvprimaryaccentReproduction notes
Reported reproduction:
/wp-json/elementor/v1/globalsand observe the Neve colors in the collection./wp-json/elementor/v1/globals/colors/nvprimaryaccentand observe HTTP 404 withglobal_not_found.The customer reports the same result after rolling Elementor back from 4.3.x to 3.34.x. Local end-to-end reproduction was not performed; source and release-history inspection confirm the failing Neve branch.
Diagnosis
Conclusion
The defect is confirmed in Neve. For a single Neve color route,
Elementor::alter_global_colors_front_end()returns any incomingWP_Errorbefore it inspects whether the requested ID belongs to Neve. The customer observed Elementor returningglobal_not_foundfor that ID, so the Neve response-construction path is unreachable. Commit38126e48a6b9b5d7a4532b555dec9a7c28a77b95, released in 4.2.12, introduced this early return; 4.2.11 lacks it and 4.2.13 retains it, establishing a regression.Where this likely occurs
inc/compatibility/elementor.php—Elementor::init()lines 61-73 registers both REST-response filters when Elementor is active.inc/compatibility/elementor.php—Elementor::alter_global_colors_front_end()lines 142-179 returns at lines 143-145 on anyWP_Error, before matching known Neve IDs at lines 147-169 and constructing the palette response at lines 171-178.inc/compatibility/elementor.php—Elementor::alter_global_colors_in_picker()lines 190-231 independently adds Neve palette colors to/elementor/v1/globals, explaining why collection and individual lookups disagree.38126e48a6b9b5d7a4532b555dec9a7c28a77b95added the error guard and tests; it is contained in tagsv4.2.12andv4.2.13, but not inv4.2.11.CHANGELOG.mdlines 5-19 records the 4.2.12 Elementor error-response change.Engineering notes
The 4.2.12 change closed issue #4559, where a
WP_Errorfrom the collection endpoint caused a fatal call toget_data(). The newly reported behavior concerns the separate single-color callback: an error can be the expected upstream response for a Neve-injected ID unknown to Elementor, while Neve owns the mapping and palette value. The inspected integration lives entirely in the free Neve theme; no matching handler was found in Neve Pro Addon. Elementor source is not present in the workspace, so its CSS-generator behavior is supported by the customer's endpoint observations, generated-CSS comparison, and working workaround rather than local dependency inspection.Test coverage status
tests/test-elementor-compatibility.phpcontains unit coverage for both REST callbacks.TestElementorCompatibility::test_global_colors_front_end_passes_through_wp_error()lines 52-61 uses arest_forbiddenerror and requires all single-color errors to pass through.TestElementorCompatibility::test_global_colors_front_end_overrides_color()lines 78-91 only verifies substitution when the incoming response is already successful. The suite does not cover aglobal_not_foundresponse for a known Neve-owned color ID. The targeted PHPUnit file could not be run becausephpunitis unavailable in the environment.What to verify or explore next
global_not_foundfor a known Neve ID, an unknown ID, and authorization-related errors.Regenerate Files & Dataworkflow.Unknowns / follow-up
nvprimaryaccent; the remaining built-in and custom IDs were not runtime-tested here.Confidence
Confidence: 98/100
The reported 404 is directly explained by a Neve 4.2.12 guard that returns Elementor's error before Neve resolves its own color ID; git history proves the behavior was introduced after 4.2.11 and remains in 4.2.13. No matching open issue was found.
Source: HelpScout #3461723835
Generated by bug-report-triage (ID: bug-report-triage_6ab54922aa1192.25004359)