Matthias Kittsteiner

epiphyt

WordPress offers several (contact) form plugins, but most of them are not up-to-date anymore when it comes to creating forms. Form Block tackles this problem by utilizing the block editor’s power. It enables you to create a form effortlessly within the block editor itself, which makes the process of creating a form much more enjoyable and similar to creating other types of blocks. This innovative approach to form creation ensures that Form Block stands out from other WordPress form plugins.
Note: This plugins requires the PHP extension <a href="https://www.php.net/manual/en/book.dom.php" rel="nofollow ugc">“Document Object Model” (php-dom)</a>.
<h4>Features</h4>
<ul>
<li>Fully support of the block editor</li>
<li>Built with accessibility in mind</li>
<li>Create forms with an unlimited number of fields</li>
<li>Select from a wide variety of field types</li>
<li>Use a predefined form or start from scratch</li>
<li>Store form submissions in the WordPress backend</li>
<li>Integrated honeypot for spam protection</li>
<li>Integrated knowledge base for field types</li>
<li>Client-side and server-side validation</li>
</ul>
<h4>Getting started</h4>
<ol>
<li>Add the “Form Block” block anywhere you want to enable a form in your block editor.</li>
<li>Select a predefined form or start from scratch.</li>
<li>Add/Edit/Remove fields to your form as you like. You can select from input, select and textarea fields.</li>
</ol>
After submission, the form data will be sent to the email address you have set in the settings.
<h4>Coming soon</h4>
There is much more planned for Form Block. Here is a small selection of features that are coming soon:
<ul>
<li>Flood Control</li>
<li><a href="https://wordpress.org/plugins/antispam-bee/" rel="ugc">Antispam Bee</a> integration</li>
<li>Custom date picker</li>
<li>More customization options</li>
</ul>
<h4>Pro version</h4>
There is also a Pro version of Form Block available. It offers additional features, such as:
<ul>
<li>Extended server-side validation</li>
<li>Custom recipient(s) for each form</li>
<li>Custom form action</li>
<li>Upload via drag and drop</li>
<li>Storing files in WordPress instead of attaching them to an email</li>
<li>Global defined consent checkbox</li>
<li>Field dependencies</li>
<li>Advanced functionality for accessibility</li>
</ul>
You can find more information at <a href="https://formblock.pro/en/" rel="nofollow ugc">https://formblock.pro/en/</a>.

Form Block


Just tried out this simple Form Block plugin and it's awesome – every block in the editor should be like this. Making a contact form is super easy. You just install it, add the block in the editor, pick the pre-made contact form, and you’re done. Editing the fields is a breeze, and it even includes a GDPR checkbox automatically. It works right away, sending the info to the WP admin email without any extra setup. The free version is perfect for beginners.


Effortless Contact Form Plugin, Easily Used as Block, GDPR Compliant

Block Form is a really great plugin that makes it easy to create fantastic forms. We will definitely use it frequently for new projects and replace other form plugins in older projects.

Great Plugin

An extensive yet user-friendly form block.

Marco Almeida | Webdados

Naked Cat Plugins

This plugin aims to ensure that any language change in a page’s content is indicated to assistive technologies at the container block level, helping a website comply with WCAG guidelines.
This feature is available on the core block editor only at a text formatting level after code from <a href="https://wordpress.org/plugins/lang-attribute/" rel="ugc">Jb Audras plugin “Lang Attribute for the Block Editor”</a> was merged into core. The objective of this plugin is to provide the same functionality at a container block level (Group – including all its variants, Columns, Cover, and other specific block types) so that the language applies to all child elements, no matter the kind of content inside.
The plugin also supports setting the language at the page or post level, both on the blocks and the classic editor. When an entire page is written in a different language than the website’s default, you can override the HTML <code>lang</code> and <code>dir</code> attributes for that specific page directly from the Document Settings sidebar, without needing to wrap everything in a container block. 
For even broader coverage, the plugin supports setting the language at the template level in the Site Editor (Appearance → Editor → Templates). A language set on a template is automatically applied to all pages and posts using that template, unless a specific language is set at the individual post or page level — in which case the post-level setting takes precedence. 
This plugin is heavily inspired by the Jb Audras plugin (including this readme file). The development started at WordCamp Europe 2025 Contributor Day, by Marco Almeida from <a href="https://profiles.wordpress.org/nakedcatplugins/" rel="nofollow ugc">Naked Cat Plugins</a> / <a href="https://profiles.wordpress.org/webdados/" rel="nofollow ugc">Webdados</a>, and the help from <a href="https://profiles.wordpress.org/welcher/" rel="nofollow ugc">Ryan Welcher</a> on the code side and <a href="https://profiles.wordpress.org/alh0319/" rel="nofollow ugc">Amber Hinds</a> on the accessibility compliance side.
For more context: this plugin helps you to make your website compliant with the Web Content Accessibility Guidelines (WCAG) success criteria:
<ul>
<li>3.1.1 – Language of Page: The default human language of each web page can be programmatically determined. Use the template-level setting when all posts or pages sharing a template are in the same language, or the page-level setting when an entire page or post is written in a language other than the website or template default.</li>
<li>3.1.2 – Language of Parts: The human language of each passage or phrase in the content can be programmatically determined. Use the block-level setting when only specific sections within a page are in a different language.</li>
</ul>
The purpose of these success criteria is to ensure that user agents can correctly present content written in multiple languages.
Keep in mind that you should set the <code>lang</code> and <code>dir</code> attributes only on a container block or page if the content is written in a language different from the one set globally on your website.
As per Web Content Accessibility Guidelines:
This enables user agents and assistive technologies to present content according to the presentation and pronunciation rules of that language. This applies to graphical browsers, screen readers, braille displays, and other voice browsers.
Both assistive technologies and conventional user agents can render text more accurately if the language of each passage of text is identified. Screen readers can use the language’s pronunciation rules. Visual browsers can display characters and scripts appropriately.
This is especially important when switching between languages that read from left to right and languages that read from right to left, or when text is rendered in a language that uses a different alphabet. Users with disabilities who know all the languages used in the Web page will be better able to understand the content when each passage is rendered appropriately.
That’s not just good for accessibility. It’s also great for SEO. Search engines like Google can better understand your content when languages are clearly defined. That means improved indexing and potentially better rankings.
Banner photo by <a href="https://unsplash.com/@hannahwrightdesigner?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash" rel="nofollow ugc">Hannah Wright</a>.
<h3>Supported block types</h3>
<ul>
<li>Group (<code>core/group</code>): Group contents together and set a language for them</li>
<li>Columns (<code>core/columns</code> and <code>core/column</code>): Organize content into a set of columns and set a language for all the columns or a specific column</li>
<li>Cover (<code>core/cover</code>): Set the language to all the contents inside a cover block</li>
<li>Navigation (<code>core/navigation</code>): Create full navigation menus in different languages</li>
<li>Submenu (<code>core/navigation-submenu</code>): Set a different language on a sub-section of your menu (for example, if you have the default language pages on the first level and a sub-menu with pages in another language)</li>
<li>Page List (<code>core/page-list</code>): List all the pages on your website that are written in a different language and created as a child of the main page of that language</li>
<li>Content (<code>core/post-content</code>): Set the post content on a custom template to a different language</li>
</ul>
<h3>Features</h3>
<ul>
<li>Set the language and text direction at the template level in the Site Editor: a “Template Language” panel lets you define the default language for all pages and posts using that template, which is automatically applied unless overridden at the individual post or page level</li>
<li>Set the language and text direction for an individual page or post, both on the blocks and classic editor: a “Page Language” panel in the Document Settings sidebar overrides the HTML <code>lang</code> and <code>dir</code> attributes for that specific page, taking precedence over any template-level setting</li>
<li>Add <code>lang</code> and <code>dir</code> attributes to Group, Columns, Cover, and other specific WordPress Blocks, mentioned above</li>
<li>Show visual outline around blocks that have a language attribute set – For easy identification of blocks you have already set to a different language during your editing process, only for Administrators and Editors, and if enabled in Settings – Writing</li>
</ul>

Language Attribute for Container Blocks and Pages/Posts

Add lang and dir attributes to Group, Columns, Cover, and other specific WordPress Blocks, Templates, or to specific Posts/pages.

Form Block vs Language Attribute for Container Blocks and Pages/Posts