v1.20.94

Login nativo del plugin

La pagina de acceso dependia de Elementor + el widget de login de
Members; al desactivar Elementor se quedaba en blanco, y activar "sitio
privado" en Members mandaba al login por defecto de WordPress.

• Nuevo shortcode [crm_login] -- formulario propio, no depende de
  Elementor ni de Members.
• Pagina "Acceso" autocreada (usa [crm_login] automaticamente si el
  ajuste de pagina de login esta vacio).
• auth_redirect() (nucleo de WordPress y "sitio privado" de Members)
  manda ahora a la pagina de acceso del CRM.
• Las paginas publicas por token (confirmar-pedido, plan-de-seguridad,
  validar-extra) y la propia pagina de login quedan excluidas del modo
  "sitio privado" de Members.

Revisa tras actualizar: en CRM -> Ajustes, comprueba el campo
"Pagina de login (ID)" -- dejalo en blanco para usar la nueva pagina
"Acceso" automatica, o pega [crm_login] en tu pagina de login existente
si prefieres conservarla.

v1.20.93

Fix: jQuery is not defined (tras desactivar Elementor)

jQuery solo se encolaba explicitamente en un par de paginas del CRM; el
resto dependia de que Elementor lo cargara de rebote. Al desactivarlo se
rompio "alta-de-cliente" (y potencialmente cualquier otra pagina del CRM
que no fuera una de esas dos). Ahora se encola siempre en el frontend,
sin depender de otros plugins.

v1.20.92

Menu hamburguesa en movil

La topbar del App Shell (administrator/crm_admin) tiene 9 enlaces -- el
scroll horizontal anterior no era descubrible en movil. Ahora, por debajo
de 720px, un boton hamburguesa despliega el menu a pantalla completa. En
escritorio y en el panel del instalador no cambia nada.

Flujo de proveedor

• Nuevo campo en la pagina publica de confirmacion del proveedor para que
  indique su propio numero de pedido -- se guarda y se muestra en la ficha.
• Opcional: crear tambien un pedido de compra real en Holded
  (purchase-orders) al notificar al proveedor, si hay un contacto de
  Holded vinculado en Ajustes. Se crea sin aprobar, para revisarlo antes
  en Holded.

v1.20.90

Fix critico: pagina en blanco en movil

hide_header_with_css_on_login_page() (acceso.php) ocultaba
".ast-header-break-point" pensando que era el contenedor del menu movil de
Astra. En realidad Astra pone esa clase en el por debajo del
breakpoint de cabecera - la regla display:none !important ocultaba la
pagina de login entera (que ademas es la home del sitio) en cualquier
movil. Confirmado en vivo y corregido: solo se oculta ".ast-mobile-header-wrap"
(el contenedor real del menu movil).

v1.20.89

Modulo de instalaciones completo (Fases 1-9)

• Fase 2: alta de instalacion desde un presupuesto aprobado de Holded.
• Fase 3: stock, aviso al proveedor Santoki y transicion automatica a "lista".
• Fase 4: panel del instalador, checklist previo, cierre con fotos por
  categoria (multi-subtipo), y generacion + aprobacion de un albaran de
  salida real en Holded al confirmar el checklist.
• Fase 5: partidas extra validadas por el CLIENTE via email (token de un clic).
• Fase 6: doble check de facturacion (pago del cliente automatico, compra al
  proveedor vinculada a mano) y badge de margen.
• Fase 7 (andamiaje): integracion con WhatsApp Business (Meta Cloud API),
  lista para activarse en cuanto haya credenciales de proveedor.
• Flujos y roadmap: diagramas y estado por fase, visibles en wp-admin y en
  /panel-de-control/.

Otros cambios

• Redireccion de login por rol (instalador a su propio panel).
• Agenda unificada para administrator/crm_admin (visitas + citas de instalacion).
• Endurecimiento de permisos en leads MK, notas y visitas; bloqueo de
  sincronizacion concurrente de Google Sheets.
• Reorganizacion de CSS e imagenes bajo css/ e img/.

Nota: no se habia publicado ningun Release desde v1.20.25 (16-17 ago) aunque
el codigo siguio avanzando por tags sueltos - el checker de actualizaciones
de WordPress prioriza el ultimo Release sobre los tags, asi que ningun sitio
detectaba las versiones intermedias. A partir de ahora, publicar un Release
en cada version es lo que realmente activa el aviso de actualizacion.

v1.20.25

Version de prueba del modulo de instalaciones

v1.20.24

• Leads MK ya no desaparecen al asignarlos desde crm_admin.
• Nueva trazabilidad de lifecycle MK: pendiente, asignado y trabajado.
• El lead pasa a trabajado cuando el comercial asignado guarda la ficha.
• La cola de Leads MK añade filtro por estado y mantiene visible el origen marketing.

v1.20.23 - Limpieza debug visitas

v1.20.23 — Limpieza: retirada de la instrumentación de debug de visitas

Bug del guardado de visitas resuelto en v1.20.22 (Members AdminAccess
desenganchado para acciones admin-post.php que empiezan por crm_).

Cambios

• Eliminado crm_visita_debug_early_dump y su hook en admin_init.
• Eliminado crm_debug_handler_state, crm_debug_wp_redirect_capture y el
  filter wp_redirect asociado.
• Eliminados los checkpoints $state['step'] dentro de
  crm_visita_handle_save.
• Eliminado el bloque que devolvía JSON cuando llegaba _crm_debug=1.

El handler crm_visita_handle_save queda con su lógica original limpia:
auth → nonce → input → permisos → create/update → wp_safe_redirect.

v1.20.22 - Fix: Members AdminAccess bloqueaba guardado visitas

v1.20.22 — Fix: Members AdminAccess bloqueaba admin-post.php para comerciales

Causa raíz

El plugin Members (Cory Miller / MemberPress) tiene un add-on "Admin Access"
que en admin_init redirige a home_url('/') a cualquier usuario no-admin que
toque /wp-admin/*, incluyendo admin-post.php. Esto rompía completamente el
guardado de visitas (y cualquier otro formulario CRM que envíe a admin-post).

Confirmado vía backtrace capturado por v1.20.21:

crm_debug_wp_redirect_capture
wp_redirect
Members\AddOns\AdminAccess\access_check  ← culpable
do_action('admin_init')

Solución

Nuevo hook crm_allow_own_admin_post_actions en admin_init con prioridad
PHP_INT_MIN + 1 (muy temprana). Detecta peticiones a admin-post.php cuya
acción empieza por crm_ y desengancha:

1. La función concreta Members\AddOns\AdminAccess\access_check vía
   remove_action.
2. Cualquier callback en el hook admin_init cuyo nombre incluya
   Members\AddOns\AdminAccess o members_admin_access (fallback defensivo
   para variantes futuras).

Resto del wp-admin sigue protegido para no-admin como antes.

Compatibilidad

• No afecta a sitios sin Members instalado (remove_action de hooks inexistentes
  es no-op en WP).
• No abre wp-admin a no-admin: solo permite el endpoint admin-post.php para las
  acciones del CRM, que ya verifican nonce + permisos en sus propios handlers.

v1.20.21 - Debug profundo: trace wp_redirect + checkpoints handler

v1.20.21 — Debug profundo: trace de wp_redirect + checkpoints en handler

Cambios

• Nuevo filter wp_redirect con prioridad 1 que intercepta cualquier redirect durante una petición con _crm_debug=1 o _crm_debug=trace. Devuelve JSON con:
  • location y status del redirect interceptado
  • backtrace completo (qué función disparó el redirect)
  • handler_seen (true si el handler de visita llegó a ejecutarse)
  • handler_step (último checkpoint alcanzado dentro del handler)
• crm_visita_handle_save instrumentado con checkpoints por fase: entered, before_check_admin_referer, after_check_admin_referer, after_input_parse, after_target_resolution, before_create, after_create (etc.).
• Permite distinguir si el redirect a home viene de: (a) lockdown, (b) check_admin_referer, (c) crm_visita_create, (d) wp_safe_redirect del handler, o (e) terceros (theme/otro plugin).

Cómo usar

Enviar el form normal con _crm_debug=1 adicional. El filter devolverá JSON con la primera redirección y desde dónde se originó.

Quitar todo el bloque debug tras resolver.