web_user_details Shortcode
El shortcode web_user_details muestra un mensaje para el visitante actual con sesión iniciada, con un mensaje opcional para invitados aparte. No selecciona otra cuenta ni utiliza el autor de la página.
Los atributos de abajo coinciden con los controles actuales del Page Builder y con la salida pública. Usa la sintaxis en bruto únicamente para contenido revisado que no pueda mantenerse mediante los controles visuales.
Uso
[web_user_details content_not_logged_in="Please sign in to see your account details." el_class="p-125"]Hello {user_name} {user_last_name}. Your email is {user_email}.[/web_user_details]Atributos
| Atributo | Predeterminado | Valores aceptados | Propósito |
|---|---|---|---|
content_not_logged_in |
Vacío | HTML básico seguro | Mensaje para visitantes sin sesión iniciada; vacío significa que no hay salida. |
el_id |
Vacío | ID HTML único | Ancla en el contenedor del componente poblado. |
el_class |
Vacío | Nombres de clase separados por espacios | Helpers del tema existentes en el contenedor; no se genera CSS. |
El mensaje con sesión iniciada es contenido incluido, no un atributo content. Admite {user_avatar}, {user_name} (nombre de pila), {user_last_name}, {user_email} y {user_login}. Los campos de texto también funcionan en destinos de enlaces, como mailto:{user_email}. Los avatares funcionan solo en el texto del mensaje y siguen la configuración de avatares de WordPress.
Los mensajes permiten HTML de publicaciones seguro, incluidos texto, imágenes, énfasis, listas y enlaces. El mensaje con sesión iniciada incluido también admite shortcodes del tema anidados y conserva sus imágenes, iconos y controles generados. Los campos de perfil se escapan antes de que se ejecuten los shortcodes anidados, de modo que un valor de perfil no puede ejecutar un shortcode. Los enlaces no seguros y el marcado ejecutable creado se rechazan. Los valores de perfil que falten permanecen vacíos.
El componente usa web-user-details y helpers existentes, sin ninguna hoja de estilos ni script dedicados en el frontend. No implementa un atributo device_visibility separado.
Privacidad y almacenamiento en caché
Los detalles del visitante se resuelven en el momento del renderizado, en lugar de guardarse en la página. WordPress y POM Cache omiten las solicitudes con sesión iniciada; cualquier proxy o CDN aparte también debe excluir las cookies autenticadas de WordPress y respetar las respuestas privadas/no-store. No sirvas HTML personalizado a través de una caché pública compartida.
El bloque de Gutenberg User Details usa el mismo renderizador y previsualiza detalles ficticios en el editor. Consulta Personalizar un mensaje con User Details.
Verificación
Compara la página con sesión iniciada y sin sesión. Comprueba los mensajes vacíos, los campos de perfil que falten, la configuración de avatares, los enlaces y los diseños estrechos. Un cambio de perfil debería aparecer en una solicitud autenticada nueva sin volver a guardar la página. Confirma que un visitante anónimo nunca reciba la respuesta personalizada de otro visitante.