Experiment: Add Gutenberg-compatible custom field placeholders for post content.

Aperta
  • Qualcosa non va?
#419 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@cbravobernal ci sta già lavorando.

Dal 27/4/2026.

  • #420 di @cbravobernal — chiusa senza merge

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

[Type] Enhancement

Summary

As a user, I want to reference custom field values directly
inside Gutenberg content using a token syntax like
[[my_custom_key]], so the field value is rendered inline in
paragraphs or other supported blocks.

User story

As a user, I want to be able to create custom fields on a post
and reference them in post content by writing [[my_custom_key]],
so I can reuse custom field values dynamically inside the editor
and on the frontend.

Problem

Users can create custom fields for posts, but they cannot easily
insert those values into Gutenberg content without manually
duplicating content or building custom blocks/templates.

A token-based approach would let users reference field values
inline while keeping the source of truth in the custom field
itself.

Proposed behavior

Support placeholder tokens in post content using this format:

  [[my_custom_key]]

When content is rendered, the token should be replaced with the
corresponding custom field value for the current post.

This should work in Gutenberg content, including inline usage
inside paragraph blocks and other compatible content areas.

Functional requirements
  • Allow users to reference any post-level custom field using
    [[field_key]] syntax.
  • Support usage inside Gutenberg-authored content.
  • Render the referenced field value inline within supported
    blocks, including paragraph content.
  • If a referenced field has no value:
    • do not display anything by default, or
    • provide a setting/option that lets the user choose whether
      to show or hide empty output.
  • The feature must degrade safely if:
    • the field does not exist
    • the field value is empty
    • the placeholder is malformed
Content and formatting requirements
  • Allow safe inline HTML from the field value so formatting such
    as:
    • bold
    • italic
    • other permitted inline markup
      can be rendered.
  • Invalid or malformed HTML in field values must not crash
    rendering or break the editor/frontend.
  • Output must be sanitized according to WordPress core standards.
Compatibility requirements
  • Must be Gutenberg compatible.
  • Must follow WordPress core development standards and plugin
    best practices.
  • Content must remain persisted in post content if the plugin is
    deactivated.
  • Plugin deactivation must not corrupt or remove saved post
    content.
  • If the plugin is deactivated, the raw placeholder text should
    remain in content unless an alternative fallback behavior is
    intentionally designed.
Acceptance criteria
  • Users can type [[my_custom_key]] into Gutenberg content.
  • On render, the placeholder is replaced with the matching custom
    field value for the current post.
  • Placeholder replacement works inside paragraph blocks.
  • Placeholder replacement works in other supported text-based
    content blocks.
  • Empty or missing field values do not produce PHP errors, JS
    errors, or broken markup.
  • Empty output is hidden by default, or a user-facing option
    exists to control whether empty output is shown/hidden.
  • Safe formatting HTML in field values is preserved where
    allowed.
  • Unsafe or malformed HTML is sanitized and does not crash
    rendering.
  • Deactivating the plugin does not remove or corrupt saved post
    content.
  • Implementation follows WordPress core coding, sanitization,
    escaping, and Gutenberg compatibility standards.
Out of scope
  • A templating language beyond simple [[field_key]] replacement
  • Cross-post or cross-object field references
  • Advanced conditional logic beyond empty-value handling
  • Full arbitrary HTML support without sanitization
Open questions
  • Should placeholder replacement happen:
    • only on frontend render,
    • in the editor preview as well,
    • or both?
  • Should users be able to insert placeholders through a UI
    picker, or only manually by typing?
  • Should empty-value behavior be:
    • global,
    • per placeholder,
    • or per block?
  • Which HTML tags should be allowed in rendered field output?
  • Should this support only text-like field values initially, or
    also formatted/WYSIWYG fields?
Lingua principale
PHP
Stelle
136
Fork
73
Merge medio
18h 21m
PR unite (30g)
21

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di WordPress/secure-custom-fields

Tutte le issue di WordPress/secure-custom-fields

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.