0

When I add a custom HTML block that only includes form elements e.g. form, input, textarea, etc, WordPress appears to be stripping these wholesale.

Similarly, if I add a SVG icon that is part of a theme e.g. GeneratePress, WordPress appears to also remove this.

Why is WordPress filtering these and what solutions/options do I have?

7
  • 1
    Why? Security. Options? Augment the array that WP uses to filter (via wp_kses functions) them out of content. These should help: ben.lobaugh.net/blog/201762/… and wp-mix.com/wordpress-basic-allowed-html-wp_kses
    – jdm2112
    Jan 12 at 5:47
  • @jdm2112 - Thanks. I figured as much although shouldn't these be permitted/allow based on a role and/or capability? Or if I've misunderstood, doesn't this have the potential of breaking Gutenberg block plugins that include a libraries of SVG icons for example or form plugins?
    – Motivated
    Jan 12 at 6:29
  • 1
    the tags you can insert into post content are limited for security reasons for most users, if you want to insert forms and embeds you should embed them via OEmbed or use shortcodes/custom blocks to insert arbitrary HTML. The HTML block isn't a way to put any HTML in a post, it just gives you the opportunity to insert HTML that's valid in a post that you've constructed yourself. Some administrators on some sites have the unfiltered_html capability which bypasses this, but this carries major security problems and is not advised (and would get stripped out if a non-admin updated it )
    – Tom J Nowell
    Jan 12 at 11:09
  • @TomJNowell - Do you mean that if I wish to add a custom form I've crafted, I should be creating a block for it? If yes, that's for effort than value since it takes me 5 minutes to create a valid HTML5 form that posts data to an external API. It seems that if I don't use wp_kses_allowed_html, it strips out content from themes and plugins. For instance, with some themes, there is an option to add SVG icons from a predefined library they include. When adding these, it strips it out when saved. I would thought filters such as these would have a significant impact on themes and plugins.
    – Motivated
    Jan 12 at 19:11
  • 1
    Also add_shortcode isn't too difficult: add_shortcode( 'yourform', 'name_of_a_function_that_returns_your_html_as_a_string' )? There are lots of ways to put a form in a page or post, putting raw HTML with form tags scripts inputs etc is near the bottom of the list when it comes to safety security and practicality, even though it might be super convenient to you
    – Tom J Nowell
    Jan 13 at 0:30

1 Answer 1

2

Why is WordPress filtering these

Because it's a major security hole. WordPress sanitises your posts content to a whitelist of tags and attributes on save. When the posts content is displayed additional filters ( the_content ) are used to convert features into their final markup. E.g. by swapping out shortcodes, rendering dynamic blocks, taking OEmbed URLs and swapping them out for their embed HTML codes, etc.

The exception is in non-multisite self-installs where the administrator may have the unfiltered_html capability. This is a very dangerous capability that bypasses the security, e.g. you can insert unbalanced tags that cripple your site, or bitcoin miners and malware. Also anybody who isn't an admin that opens this post and saves will strip it all out.

and what solutions/options do I have?

Literally any API other than what you did:

  • custom shortcodes
  • filters
  • templates
  • custom blocks
  • custom widgets ( or even the custom HTML widget )

But not raw form html and javascript executing in the posts content.

The easiest is probably a shortcode, e.g. shortcode-plugin.php:

<?php
/**
 * Plugin Name: I'm a plugin yay
 */

add_shortcode( 'yourshortcode', function( $atts ) : string {
    ob_start();
    ?>
    <form>
        ....
    </form>
    <?php
    return ob_get_clean();
} );
5
  • Thanks for the suggestions, ideas and example. If a shortcode is the easiest solution, why is the HTML block available?
    – Motivated
    Jan 13 at 8:42
  • as I said in the comments further up, the HTML block does not do what you think it does. It is not a raw unprocessed HTML block that lets you insert anything you want. Blocks have HTML output, and that output gets processed by filters, this block lets you control what that HTML output is, but that doesn't mean it doesn't get processed by filters. Your expectations for the HTML block os inaccurate, it only behaves the way you expected it to behave when a user has the unfiltered_html capability, and there is no method of making an exception just for that block.
    – Tom J Nowell
    Jan 13 at 9:50
  • e.g. if I wanted to insert a paragraph with a particular arrangement of tags and attributes I could do that with the custom HTML block, perhaps this would let me insert a shortcode in a tag attribute, or maybe I prefer to type my tags out manually? Or maybe I'm a super admin with the unfiltered_html capability? There are lots of reasons I might want a custom HTML block that don't involve using forbidden/dangerous tags, some of which are purely personal preference, some people like writing HTML instead of WYSIWYG.
    – Tom J Nowell
    Jan 13 at 9:55
  • The same is also true of the classic editor, anybody could have gone to the text view and inserted form and script tags, but unless they had unfiltered_html it would get stripped out on save. That doesn't meant the text view was only for adding form/script tags, lots of people used it for other things even with the filtering. The HTML block is the equivalent of that text view without the constraints of having to conform the markup to match block validation
    – Tom J Nowell
    Jan 13 at 9:58
  • Excellent answer, as always Tom. This is the WordPress way.
    – jdm2112
    Jan 14 at 4:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.