Add Custom HTML block description and use sandbox for preview

[westonruter]

For the Custom HTML block, see #1386.

Amends #1597 by adding a block description for the Custom HTML block to align with new Custom HTML widget in 4.8-alpha: https://github.com/WordPress/wordpress-develop/blob/2744e29fd3f0fb17485290d2bf827f21292a92c3/src/wp-includes/widgets/class-wp-widget-custom-html.php#L38

Also adds list of common HTML tags that are disallowed when the user cannot unfiltered_html, similar to the Custom HTML widget: https://github.com/WordPress/wordpress-develop/blob/2744e29fd3f0fb17485290d2bf827f21292a92c3/src/wp-includes/widgets/class-wp-widget-custom-html.php#L124-L135

To test, try accessing Gutenberg with a user having an author role.

I'm not certain that exporting the allowed HTML tags and the current user's unfiltered_html capability by amending them to the wp.editor global is the best way to go about this.

Also, and this is probably for a separate issue, I should think that the preview should actually enforce the constraints to remove the disallowed HTML? This is probably also closely related to the need to sandbox the previewed HTML in an iframe so that document.write() calls can be previewed properly.

[westonruter]

There, now thanks to #1392 there is a proper sandbox to put the custom HTML into, and this means that document.write() will work as expected. It doesn't yet strip out illegal HTML, however.

[westonruter]

Note the issue of content being clipped in the sandboxed iframe is addressed in #1688.

[westonruter]

Rebased to include sandbox improvements from #1688. Former HEAD was c1f14c2.

[westonruter]

@mtias any further changes needed here?

[gziolo]

@westonruter this one needs rebase. @mtias can you check this one?

[jasmussen]

Love this, it seems like a solid improvement over #2917. Perhaps we can take the first paragraph of that ticket, and add the allowed tags below that?

[aduth]

Can we merge this in with other editor settings? I'm thinking we need a scalable solution here.

gutenberg/lib/client-assets.php

Lines 790 to 793 in 1cea1fb

	$editor_settings = array(
	'wideImages' => ! empty( $gutenberg_theme_support[0]['wide-images'] ),
	'colors' => $color_palette,
	);

The withEditorSettings higher-order component was created to avoid having the component directly reference the window global:

https://github.com/WordPress/gutenberg/tree/master/blocks/with-editor-settings

[westonruter]

I absolutely agree. The withEditorSettings was not available at the time I wrote this, I believe.

[aduth]

• Can we be formatting this data from the server to be in a more useful shape? i.e. would we always be expecting to call Object.keys and if so, pass from the server as array_keys ? Not sure how likely it is we'd do anything with the allowed attributes and could avoid increasing the size of the page by including only what's used.
• The cache assignment here reminds me of a since-removed document about props in state, which is more to the point of: rather than splitting the source of truth, merely generate this rendering on the fly. Since allowedPostHtml is not a prop and is not likely to change, this may not be an issue, but could still be seen as an over-optimization to split the logic as we've done here.

[westonruter]

Can we be formatting this data from the server to be in a more useful shape?

Actually it is useful as it is. The data consists of keys for the HTML tags, and then the values are objects that indicate the attributes that are allowed for each element. It's the same structure as: https://github.com/WordPress/wordpress-develop/blob/1eda9654da06715798cbf911372c0c13e5baf7ca/src/wp-includes/kses.php#L53-L416

[westonruter]

@jasmussen @aduth @mtias Actually the Custom HTML widget has improved significantly since it was introduced in 4.8.1. Now the widget incorporates CodeMirror and leverages the HTMLHint linter with a custom Kses rule to contextually inform users of illegal tags if they are actually used, preventing them from saving until they fix the illegal (or malformed) HTML. This is naturally way better than listing the tags that are not allowed. It also ensures that the invalid HTML is not silently stripped from the field when they try saving:

The list of disallowed tags is now exported from the server as part of the call to wp_enqueue_code_editor(). I'm working on a dev note for this now.

I won't have time until December to work on an enhanced Custom HTML block to make use of the new code editor APIs in 4.9-beta, but if someone wants to work on it now it would be valuable for validation of the new code editor APIs in 4.9. You can refer to the Custom HTML widget JS. I'm available to answer any questions and provide support, but I won't be able to own it due to 4.9 release responsibilities.

[noisysocks]

I'm taking over this as part of #4348.