Variablen in Templates: fg, glb und pseo erklärt

Die meisten WordPress-Plugins für benutzerdefinierte Felder bieten zwei Wege, einen Wert auszugeben: einen Shortcode oder einen PHP-Funktionsaufruf in einer Template-Datei. Beides funktioniert, eignet sich aber schlecht für einen Fall, der ständig auftritt, sobald Sie Inhalte seitenübergreifend wiederverwenden: ein Wert, auf den ein Filter angewendet werden muss – in Großbuchstaben, als Zahl formatiert, mit Standardwert bei leerem Feld – innerhalb eines Page Builders oder eines Templates, das jemand ohne Entwicklerkenntnisse bearbeitet.

Variablen sind eine kleine Ausdruckssprache, die genau diese Lücke schließt. Die Syntax lautet {{ namespace.path | filter }} und ist bewusst eingeschränkt: Es wird nie PHP ausgeführt, sondern nur eine feste Menge an Namespaces, Filtern und Funktionen. Die Engine ist Teil des kostenlosen Plugins.

Die Namespaces

Jede Variable beginnt mit einem Namespace, der angibt, woher der Wert stammt:

• glb – Global Data, die websiteweiten Werte, die Sie einmal festlegen und überall wiederverwenden: Telefonnummer, Adresse, Öffnungszeiten, Social-Media-Links.
• fg – ein Feldwert einer Feldgruppe für das aktuelle Objekt: fg.products.price liest das Feld price der Gruppe products im aktuellen Beitrag.
• wp – der aktuelle Beitrag, der aktuelle Begriff und der angemeldete Benutzer, zum Beispiel wp.post_title.
• sys – Datum, Uhrzeit und Website-Angaben, zum Beispiel sys.year oder sys.site_name.
• woo – das aktuelle WooCommerce-Produkt, sofern WooCommerce aktiv ist.
• src – Werte, die Ihr eigener Code mit wpmcf_make_context() übergibt.
• pseo – die Datenzeile und die Seite hinter einer generierten Seite. Sie steht in Templates für Programmatische SEO in den kostenpflichtigen Plänen zur Verfügung, als pseo.src.<source>.<column>.

Außerdem gibt es fn, das keine Daten liefert, sondern eine integrierte Funktion aufruft, etwa fn.concat().

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

Filter

Ein Filter wandelt einen Wert nach dem Auslesen um, und zwar mit dem Pipe-Zeichen: {{ value | filter }}. Sie können mehrere Filter verketten. Die verfügbaren Filter decken die Umwandlungen ab, die in echten Templates vorkommen, darunter upper, lower, slug, trim, truncate, replace, number, round, date, date_format, default, join, length, json und escape. Ein unbekannter Filter gibt den Wert unverändert weiter, sodass ein Tippfehler den Rohwert ausgibt.

default verdient besondere Erwähnung, denn es macht den Unterschied zwischen einem Template, das stillschweigend nichts anzeigt, und einem, das etwas Sinnvolles anzeigt: {{ fg.products.discount | default('No discount') }} greift auf den angegebenen Text zurück, wenn das Feld leer ist, statt eine leere Ausgabe zu erzeugen. Alle Filter und Funktionen samt Argumenten und Ergebnissen finden Sie unter Filter und Funktionen.

Bedingte Ausdrücke

Die Sprache kennt Vergleiche, &&, || und einen ternären Operator für einfache Entweder-oder-Fälle:

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

Das deckt den häufigen Fall ab – anhand eines Vergleichs zwischen zwei Beschriftungen wählen –, ohne dass eine vollständige Template-Sprache nötig ist. Es gibt keine Schleifen, keine Zuweisungen und keine arithmetischen Operatoren; sie ist also absichtlich kein universelles Skripting-Werkzeug. Wenn Sie etwas berechnen müssen, berechnen Sie es in PHP und übergeben es mit src. Ein Block, der sich nicht auswerten lässt, wird als leerer String ausgegeben, damit die Seite weiter gerendert wird.

Warum hier kein PHP läuft

Variablen sind eine eigene, eingeschränkte Sprache und kein „schreiben Sie einfach ein PHP-Snippet“, und zwar aus Sicherheitsgründen. Ein Page Builder oder ein KI-generiertes Template ist kein Ort, an dem beliebige Codeausführung möglich sein sollte, erst recht nicht, wenn Redakteure, Kunden oder generierte Seiten-Templates beteiligt sind. Variablen können nur die Filter und Funktionen aus einer expliziten Allowlist aufrufen, und selbst fn.option() – die Funktion zum Lesen einer WordPress-Option – ist auf eine kurze Liste von Optionsnamen beschränkt, etwa blogname, und kann nicht beliebige Einträge in wp_options lesen.

Zwei weitere Schutzmaßnahmen sollten Sie kennen. Passwortfelder und Passwortvariablen werden immer leer ausgegeben. Und ein gespeicherter Wert führt Ausdrücke nur aus, wenn sein Autor vertrauenswürdig ist: Bei einem Beitrag bedeutet das, dass der Autor ungefiltertes HTML verwenden darf, sodass ein Mitarbeiter mit Schreibrechten einen Beitrag nicht ein anderes Feld ausgeben lassen kann, indem er {{ }} eintippt. Die Sicherheitsseite listet jede Regel und den Filter auf, mit dem sie sich anpassen lässt.

Die vollständige Liste der Einsatzorte finden Sie unter Wo Variablen funktionieren.

Ausgabe jenseits von Variablen

Variablen sind einer von drei Wegen, einen Wert aus Mass Custom Fields auszugeben. Die anderen sind Shortcodes – [wpmcf_field group="product" field="price"] und [wpmcf_global key="phone"], nutzbar in jedem Page Builder, der Shortcodes ausführt – sowie eine PHP-API für Theme- und Plugin-Code: wpmcf_get_field(), wpmcf_the_field(), wpmcf_has_field() und wpmcf_get_global() für Global Data. Welchen Weg Sie wählen, hängt davon ab, wo Sie arbeiten: Variablen in einem Builder oder einem generierten Seiten-Template, Shortcodes in einem Builder, der nur Shortcodes akzeptiert, und die PHP-API, wenn Sie direkt Theme-Code schreiben. Siehe Shortcodes und die Namespace-Referenz.

Fazit

Eine sichere Ausdruckssprache ist absichtlich ein engeres Werkzeug als PHP. {{ namespace.path | filter }} deckt das Lesen eines Werts, seine Formatierung, einen Standardwert und eine einfache Entweder-oder-Auswahl ab – und damit den weitaus größten Teil dessen, was ein Template tatsächlich braucht –, ohne die Tür zur Ausführung beliebigen Codes in Inhalten zu öffnen, die andere Personen oder ein KI-Anbieter am Ende bearbeiten könnten.