HTML input field type

[x5hwuk7nc6jsudcc]

An HTML input field type would be very useful..

[lukecarbis]

@strayguevara We discussed this recently – adding a "code" field which used WordPress' built-in CodeMirror library.

We decided, though, that it could be confusing. What is the expected output of a code field? The plain code itself? The code once it's been processed server-side? The code wrapped in a <pre> tag? The code wrapped in a read-only syntax-highlighting CodeMirror instance?

Can you see how that might get complicated? Could you maybe describe the use case?

[x5hwuk7nc6jsudcc]

There is a built-in "custom HTML" Gutenberg block element, my expectation would be that an HTML input field would replicate this kind of functionality (i.e. the code is processed as if it were part of the document).

In terms of use case, I have a project right now where I want to allow the client to input SVG images in-line. Having a custom HTML input field would open up this possibility.

Another use case would be something like a MailChimp subscription form which I have in a footer block I've created. I don't necessarily want to hard-code the MailChimp snippet into my block because I want the client to retain control over updating or changing it if they require. A custom HTML input field would allow this.

[lukecarbis]

The SVG use case is interesting. I'd love to know more about how that block looks and works.

Would a MailChimp subscription form – why not: a) Use a MailChimp block b) Create the MailChimp block, and hardcode the javascript / HTML into your template (with a field for variables like the list ID)

[x5hwuk7nc6jsudcc]

The MailChimp snippet probably wasn't the best example, as in reality we would most likely break this down into finer variables, as you pointed out.

But perhaps I did want to do that. Why not allow HTML as an input field?

In terms of how it would look, it would probably look a lot like the textarea input field. And the end-user may drop something like this in:

<svg xmlns="http://www.w3.org/2000/svg" width="179" height="179" viewBox="0 0 179 179"> <g fill="#010002"> <path d="M138 138A69 69 0 0 1 20 89l15 15a2 2 0 0 0 3-4L19 82 1 100a2 2 0 1 0 3 4l12-12a74 74 0 0 0 125 50 2 2 0 0 0-3-4zM178 75h-3l-12 12A74 74 0 0 0 38 37v4h3c13-13 30-21 49-21 38 0 68 31 69 69l-15-14a2 2 0 0 0-3 4l19 18 18-18v-4z"/> </g> </svg>

[lukecarbis]

Is there any reason you couldn't simply drop the SVG code above into a textarea field? Or would an SVG work better with an image (or file) field, uploading the file itself, instead of the code?

Couple reasons why I'm personally not enthusiastic about this idea:

• Could be confusing for users (see my comment above)
• Simple workarounds already exist
• Extra code to maintain and support

Not to say it won't ever happen, just that I think there are other bigger priorities (such as #281). Still, I'm keen to hear additional opinions.

[x5hwuk7nc6jsudcc]

Is there any reason you couldn't simply drop the SVG code above into a textarea field?

The textarea field seems to strip all of the SVG code when we drop SVG code into it.

Or would an SVG work better with an image (or file) field, uploading the file itself, instead of the code?

The objective insofar as SVG is concerned is to have the SVG inline the document, rather than an additional HTTP request like an image. That's why dropping code in there seems the natural solution.

However if https://github.com/getblocklab/block-lab/issues/281 allowed uploading SVG files, then that would actually be an even neater solution, so long as we could do something like this in our template:

<div class="icon"><?php echo file_get_contents( block_field( 'svg-icon-1' ) ); ?></div>

[BenHarris]

@strayguevara the "SVG Support" plugin with the below code in your block works well

$svg_url = get_attached_file( block_field( 'icon', false ) ); 
if (substr($svg_url, -3) == 'svg') {         
  echo file_get_contents( $svg_url );
}
else
{
  echo '<img src="'.wp_get_attachment_url( block_field( 'icon', false ) ).'" />';
}

WordPress SVG support is the real problem here.

[bizop]

+1 for a dedicated html field.

From what I've seen the text field currently strips all HTML that is set in the "default" field for that block, which can be limiting.