Elementor single-color endpoint returns global_not_found for Neve palette colors
I maintainer di solito rispondono entro 1 giorno
Valutazione
Questa issue non è ancora stata valutata.
Descrizione
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/nvprimaryaccentreturns 404 withglobal_not_found, while the globals collection includesnvprimaryaccent - 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/globalsand observe the Neve colors in the collection. - Request
/wp-json/elementor/v1/globals/colors/nvprimaryaccentand observe HTTP 404 withglobal_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 anyWP_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
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_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_foundfor 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 & Dataworkflow.
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)
- Lingua principale
- PHP
- Stelle
- 307
- Fork
- 88
- Merge medio
- 1g 6h
- PR unite (30g)
- 10
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di Codeinwp/neve
-
bug-report bug-report-triage customer report regression
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
I maintainer di solito rispondono entro 1 giorno
-
feature-request-triage
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
I maintainer di solito rispondono entro 1 giorno
-
feature-request-triage
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
I maintainer di solito rispondono entro 1 giorno
-
customer report feature-request-triage
Difficoltà 4/5 3-5 giorni Idoneità per principianti 52/100
I maintainer di solito rispondono entro 1 giorno
-
customer report feature-request-triage
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di Codeinwp/neve
Issue simili
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
sync-en
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 2 giorni
-
[Area] REST API [Type] Documentation Good First Issue
Difficoltà 1/5 1-3 ore Idoneità per principianti 90/100
WordPress/presence-api#584 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100