WYSIWYG

The WYSIWYG field drops the full TinyMCE editor, the same rich-text editor WordPress has shipped for years, into a custom widget’s panel. Editors get bold, italics, lists, links, headings, and the visual/text tab switch they already know. Your widget receives formatted HTML ready to print. Inside the Master Addons Widget Builder, this is the field for content regions where a plain Textarea would flatten the formatting out of the text.

The connection is one token. Print {{ your_field_name }} in the HTML panel and the stored markup renders there, filtered through wp_kses_post, so the formatting survives while unsafe tags are stripped. No extra filters, no escaping gymnastics.

What the WYSIWYG field does #

• Renders the TinyMCE rich text editor in the widget’s Elementor panel, with the Visual and Text tabs.
• Stores the editor’s output as an HTML string.
• Prints that HTML through {{ your_field_name }}, passed through wp_kses_post on output.
• Keeps formatting intact: paragraphs, bold, italics, lists, links, and headings all render.
• Supports dynamic values, so the content can come from dynamic tags where the setup provides them.

First widget? The Widget Builder overview covers the editor basics this page builds on.

Before you start #

• WordPress with Elementor installed and active.
• Master Addons for Elementor installed and active. New to the plugin? See the installation guide.
• A custom widget open in the Widget Builder editor. Our example is a team member card widget with a WYSIWYG field named member_bio holding each person’s formatted biography.

How to add a WYSIWYG field #

Drag the WYSIWYG field from the fields panel into a section under the Content tab, the natural home for long-form content. Its options open on the left once it lands.

WYSIWYG field options explained #

The option list stays small because the editor itself carries the complexity:

• Label: the text shown above the editor in Elementor, for example “Member Bio”.
• Name: the unique identifier your templates refer to. Letters, numbers, and underscores only, for example member_bio.
• Default: the starting content, and it can include markup. A short formatted paragraph shows editors what the region is for and proves the formatting works.
• Dynamic: the field accepts dynamic values, so content can be wired to dynamic tags instead of typed by hand.

Connect the WYSIWYG field with its token #

The WYSIWYG field is a token field. One token in the HTML panel places the whole content region:

<article class="tm-card">
  <h3 class="tm-name">{{ member_name }}</h3>
  <div class="tm-bio">
    {{ member_bio }}
  </div>
</article>

On output, the value passes through wp_kses_post, the filter WordPress applies to post content. The tags TinyMCE produces, paragraphs, strong and em, lists, links, headings, images, are all on the allowed list, so what editors format is what renders. Anything unsafe that sneaks in through the Text tab, like a <script>, is stripped.

Watch out: do not add |raw to a WYSIWYG token out of habit. The plain token already renders the formatting, because wp_kses_post allows the markup TinyMCE writes; |raw only removes the safety filter without changing what a normal bio looks like. If the output looks escaped rather than rendered, the cause is elsewhere, not a missing filter.

Wrap the token in a container with a class, as in the example, and style the region from the CSS panel:

.tm-bio p { margin: 0 0 0.75em; }
.tm-bio a { color: inherit; text-decoration: underline; }

Use the WYSIWYG control in Elementor #

Add your custom widget to a page in Elementor, or reload the editor if the page was already open. The field renders as a full TinyMCE editor in the panel: toolbar on top, Visual and Text tabs in the corner, Add Media where the setup allows it.

Editors write and format exactly as they would in a post: select text, bold it, add a link, start a list. The preview updates as they type, showing the content styled by the widget’s CSS.

When a bio renders oddly, check the Text tab before you blame the widget. Content pasted in from Word or Google Docs often carries stray spans and inline styles, and they are all visible there. Cleaning the markup in the Text tab usually fixes the layout on the spot.

Common use cases #

• Bios and profiles in team, author, and speaker widgets.
• Long descriptions in service, product, and feature cards where a heading or list belongs inside the text.
• Testimonial bodies that need emphasis and line breaks preserved.
• Footnotes and disclaimers with inline links to policies.
• Any client-edited text region where formatting matters and the client should never see HTML.

Tips for working with the WYSIWYG field #

• Print the plain token. {{ member_bio }} renders the formatting as-is; |raw adds risk without adding capability here.
• Style through a wrapper class. Target .tm-bio p, .tm-bio ul, and friends in the CSS panel rather than hoping the editor output arrives pre-styled.
• Set a formatted Default. A bio with a bold name and one link doubles as a live example of what the field supports.
• One WYSIWYG per content region. Give the intro and the fine print separate fields instead of asking editors to manage both inside one editor.
• Choose the lighter field when you can. A single unformatted line belongs in a Text field; reach for WYSIWYG when paragraphs, lists, or links are genuinely part of the content.
• Expect kses on output. Custom tags outside the post-content allowed list will not survive, by design. Pasteable raw snippets are the Code field‘s job.

Frequently Asked Questions #

Wrapping up #

The Widget Builder WYSIWYG field gives editors the writing experience they already know and gives you a single sanitized token to place in the markup. Content people format bios and descriptions visually; the widget renders them safely and styles them through its own CSS. For pasteable raw snippets use the Code field, and for repeating formatted blocks combine WYSIWYG with the Repeater field. Explore the rest of the Master Addons widgets and extensions, and see the pricing page for what each plan includes.