Variables en plantillas: fg, glb y pseo explicados

La mayoría de los plugins de campos personalizados de WordPress ofrecen dos formas de mostrar un valor: un shortcode o una llamada a una función PHP en un archivo de plantilla. Ambas funcionan, pero ninguna encaja bien en un caso que aparece constantemente cuando empiezas a reutilizar contenido en todo el sitio: un valor al que hay que aplicar un filtro (pasarlo a mayúsculas, darle formato numérico, asignarle un valor por defecto si está vacío) dentro de un maquetador o de una plantilla que edita alguien que no es desarrollador.

Las variables son un pequeño lenguaje de expresiones creado justo para cubrir ese hueco. La sintaxis es {{ namespace.path | filter }} y es deliberadamente limitada: nunca se ejecuta PHP dentro de ella, solo un conjunto fijo de espacios de nombres, filtros y funciones. El motor forma parte del plugin gratuito.

Los espacios de nombres

Toda variable empieza con un espacio de nombres que indica de dónde procede el valor:

• glb: Global Data, los valores de todo el sitio que defines una vez y reutilizas en todas partes: teléfono, dirección, horario, enlaces a redes sociales.
• fg: el valor de un campo de un grupo de campos para el objeto actual; fg.products.price lee el campo price del grupo products en la entrada actual.
• wp: la entrada, el término y el usuario con sesión iniciada actuales, por ejemplo wp.post_title.
• sys: fecha, hora y datos del sitio, por ejemplo sys.year o sys.site_name.
• woo: el producto actual de WooCommerce, siempre que WooCommerce esté activo.
• src: valores que tu propio código aporta con wpmcf_make_context().
• pseo: la fila de datos y la página que hay detrás de una página generada. Está disponible en las plantillas de SEO programático de los planes de pago, como pseo.src.<source>.<column>.

También existe fn, que no es un dato, sino que llama a una función integrada como fn.concat().

{{ glb.phone }}
{{ fg.products.price | number(2) }}
{{ wp.post_title | upper }}

Filtros

Un filtro transforma un valor después de leerlo, mediante el carácter de barra vertical: {{ value | filter }}, y puedes encadenar varios. Los filtros disponibles cubren las transformaciones que surgen en plantillas reales, entre ellos upper, lower, slug, trim, truncate, replace, number, round, date, date_format, default, join, length, json y escape. Un filtro desconocido deja el valor sin cambios, así que una errata muestra el valor sin procesar.

default merece una mención aparte, porque marca la diferencia entre una plantilla que no muestra nada en silencio y otra que muestra algo razonable: {{ fg.products.discount | default('No discount') }} recurre al texto indicado cuando el campo está vacío, en lugar de mostrar un espacio en blanco. Todos los filtros y funciones, con sus argumentos y resultados, se enumeran en filtros y funciones.

Expresiones condicionales

El lenguaje incluye comparaciones, &&, || y un operador ternario para casos sencillos de una cosa u otra:

{{ fg.products.stock > 0 ? 'In stock' : 'Sold out' }}

Esto cubre el caso habitual (cambiar entre dos etiquetas según una comparación) sin necesitar un lenguaje de plantillas completo. No hay bucles, ni asignaciones, ni operadores aritméticos, así que no es, intencionadamente, una herramienta de scripting de propósito general. Cuando necesites calcular algo, hazlo en PHP y pásalo con src. Un bloque que no se puede evaluar se muestra como una cadena vacía, de modo que la página sigue renderizándose.

Por qué aquí no se ejecuta PHP

El motivo de que las variables existan como un lenguaje aparte y restringido, en lugar de "escribe un fragmento de PHP", es la seguridad. Un maquetador o una plantilla generada por IA no es un lugar donde convenga que sea posible ejecutar código arbitrario, sobre todo cuando intervienen editores de contenido, clientes o plantillas de páginas generadas. Las variables solo pueden llamar a los filtros y funciones de una lista de permitidos explícita, e incluso fn.option() (la función para leer una opción de WordPress) se limita a una lista corta de nombres de opciones, como blogname, en lugar de poder leer cualquier cosa de wp_options.

Conviene conocer dos protecciones más. Los campos de contraseña y las variables de contraseña siempre se muestran vacíos. Y un valor almacenado solo ejecuta expresiones cuando su autor es de confianza: en una entrada, significa que el autor puede usar HTML sin filtrar, de modo que un colaborador no puede hacer que una entrada muestre otro campo escribiendo {{ }}. La página de seguridad enumera cada regla y el filtro que la ajusta.

La lista completa de lugares está en dónde funcionan las variables.

Salida más allá de las variables

Las variables son una de las tres formas de obtener un valor de Mass Custom Fields. Las otras son los shortcodes ([wpmcf_field group="product" field="price"] y [wpmcf_global key="phone"], utilizables en cualquier maquetador que ejecute shortcodes) y una API PHP para el código de temas y plugins: wpmcf_get_field(), wpmcf_the_field(), wpmcf_has_field() y wpmcf_get_global() para Global Data. Cuál elegir depende de dónde estés: variables dentro de un maquetador o de una plantilla de página generada, shortcodes en un maquetador que solo acepta shortcodes y la API PHP cuando escribes código de tema directamente. Consulta shortcodes y la referencia de espacios de nombres.

Conclusión

Un lenguaje de expresiones seguro es una herramienta más limitada que PHP, y es a propósito. {{ namespace.path | filter }} permite leer un valor, darle formato, asignarle un valor por defecto y elegir entre dos opciones, que es la gran mayoría de lo que una plantilla necesita en realidad, sin abrir la puerta a ejecutar código arbitrario en contenido que otras personas, o un proveedor de IA, podrían acabar editando.