neve/appearance-update identity.logo_media_id updates custom_logo but header logo (logo_logo) is unchanged

Abierto
  • ¿Algo no está bien?
#4,678 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
55/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
php, wordpress
Área
frontend

Línea de trabajo

Read inc/abilities/appearance_update.php around apply_identity(), then inspect the custom_logo filter in header-footer-grid/Core/Components/Logo.php and its initialization in header-footer-grid/loader.php. First verify whether the filter is registered during an ability call in a REST request, then check whether logo_logo updates for the same, light, and dark variants. Done when the header displays the selected attachment and the ability reports the result accurately.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug-report bug-report-triage

Summary

Calling the Neve appearance-update ability with identity.logo_media_id set to a valid image attachment reports success (updated: custom_logo, no warnings), but the header logo shown on the site does not change.

Expected: the visible Neve header logo uses the new image.
Actual: the Neve logo component's own setting keeps the old attachment, so the header still shows the old logo.
Impact: the logo cannot be changed through the ability, and no warning is returned.

Customer context

  • Product / area: Neve appearance-update ability (identity block), called via the Easy MCP AI plugin 2.3.0
  • Version: Neve version not provided
  • Environment: Ability invoked through an MCP/REST context, not the Customizer
  • Integration / third party: Easy MCP AI
  • Reported error / symptom: custom_logo updated; logo_logo ({light,dark,same}) keeps the old ID
  • Impact: Header logo unchanged

Reproduction notes

Reported steps: call the appearance-update ability with identity.logo_media_id set to a valid attachment ID, then inspect the logo_logo theme mod and the header. Not reproduced locally. Whether the logo sync filter is registered in the ability call context is unverified.

Diagnosis

Conclusion

The ability's identity handler writes only the custom_logo theme mod. Neve's header logo component keeps its own logo_logo mod, which is normally synced from custom_logo by a filter. The customer's observation is consistent with that filter not running in the ability context. This is inference; runtime was not reproduced.

Where this likely occurs
  • inc/abilities/appearance_update.php — apply_identity() approx. lines 607-622: calls set_theme_mod('custom_logo') and reports 'custom_logo' as updated; it does not touch logo_logo.
  • header-footer-grid/Core/Components/Logo.php — constructor approx. line 96 registers the pre_set_theme_mod_custom_logo filter; update_logo_theme_mod() approx. lines 155-164 writes logo_logo.
  • header-footer-grid/loader.php approx. line 58-60: the HFG main object is created on after_setup_theme.
Engineering notes

The sync depends on the Logo component having been instantiated and its filter registered before the ability runs. Whether that happens in REST/ability requests was not verified. No warning is emitted when the visible logo is not updated.

Test coverage status

No relevant coverage was found during inspection for logo_media_id in the ability tests.

What to verify or explore next

May be worth verifying whether the filter is registered during an ability call on a REST request, and the resulting logo_logo value. Worth checking the same=true and dark variants.

Unknowns / follow-up

Neve version and the site's header builder state are unknown.

Confidence

Confidence: 60/100

Only the Neve logo report is supported by code: the ability writes only custom_logo while the rendered logo reads a separate mod. The other four are unconfirmed: WPML needs third-party runtime evidence, the tool description is intentional, the session guard is working as designed, and the wp_update_page path never sends status.

Source: automated in-product feedback — easy-mcp-ai, 2026-10-28
Generated by bug-report-triage (ID: bug-report-triage_6ae2d79682e0c2.61501712)

Lenguaje dominante
PHP
Estrellas
307
Forks
89
Merge medio
3 d 8 h
PR fusionados (30 d)
18

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Codeinwp/neve

Todos los issues de Codeinwp/neve

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.