Use a Twig template for generating html output

I agree that having some control over the structure of the markup outputted would be really useful.
Here's a first attempt at adding a template - would love to get some feedback on this.
In particular, I'm unsure about whether I'm passing too much (or not enough) through to the template.

@bomoko the code seems to be okay for me, but let's see other opinions.
Thanks for your contribution.

Thanks so much for the feedback @marcvangend!
That's extremely useful.

Assigning this issue to myself - I'll submit a new patch with your suggestions ASAP.

Hi All

So I've made some changes to the patch as suggested by @marcvangend (thanks again).

1. I've bundled up all the attributes for the iFrame tag itself into the "attributes" variable.

2. I've removed the $options_link array from the iframe_iframe() - it was some code moved directly from the D7 version, and it adds the title to the link. If you look where it's being used in the current code, it's actually not doing anything (i.e Url::fromUri() doesn't actually recognize the structure of the data passed into it, and is essentially ignoring it). However, I've changed up the link that's generated in the twig template to do what that original code was trying to do, namely, add a "title" attribute to the link in the iFrame fallback text.

3. With regards to the embedding of the iframe_link variable as suggested in #4, it seems as though attempting to embed a variable generated by using the twig "link" function throws a warning - what seems to happen is that the render array for the link gets passed through to htmlspecialchars, rather than the rendered text. So I've gone with actually embedding the link in the string itself, and passing the appropriate variables in. This generates a translation string that looks as follows "Your browser does not support iframes, but you can use the following link: Link". Does this seem reasonable? Is there another approach I should be using?

Some notes/thoughts that I think might make sense to look at in other issues (since this is really about just getting a template working).
1 - I think that the code in iframe_iframe() can probably be simplified a little in places.
2 - The logic for the "class" attribute for the containing div and the iframe itself should be looked at (as it stands, it seems to attach itself both to the containing div and the iFrame - this is in the original code _and_ in my patch)
3 - The "fallback link" (the text and link between the iframe tags) is actually invalid html, according to the W3C validator. It might be a nice thing to add an option to either show/hide that text so that sites that need to pass the W3C validator _can_.

Patch #6 works fine. And this is a feature really useful

- we can easily override the template if necessary
- we can preprocess the theme function to add whatever we need
- easier maintenance
- use the twig power :-)

Looks like RTBC.

Unsanitized variables ({{ variable|raw }} in Twig templates or !variable in translation strings) are deprecated for Drupal 8 translations and won't work in latest 8.x Drupal versions. The translation API description is a little outdated.

For the use case, we may just add the HTML link tag to the translation string and make the link URL itself the variable. Unfortunately, the twig trans tag doesn't support that kind of variable yet. (core issue.) So we should use the t filter instead:

{{ 'A <a href=":url">link</a> example in a translation.'|t({ ':url': url }) }}

The above example matches the translation strings:

en: A <a href=":url">link</a> example in a translation.

de: Ein Beispiel-<a href=":url">Link</a> in einer Übersetzung.

Attached a new patch based on comments in #8.

And with some improvments.
- return directly the render array instead of render it.
- using the attribtes.class instead of the oprions array in the twig template
- added the fallback link into the variables passed to the template.

Source : https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Component%21Rend...

@variable: When the placeholder replacement value is:

A string, the replaced value in the returned string will be sanitized using \Drupal\Component\Utility\Html::escape().
A MarkupInterface object, the replaced value in the returned string will not be sanitized.
A MarkupInterface object cast to a string, the replaced value in the returned string be forcibly sanitized using \Drupal\Component\Utility\Html::escape().

$this->placeholderFormat('This will force HTML-escaping of the replacement value: @text', ['@text' => (string) $safe_string_interface_object));

Use this placeholder as the default choice for anything displayed on the site, but not within HTML attributes, JavaScript, or CSS. Doing so is a security risk.

So yes, using @link here is safe. It's how I understand this ^^
And the text used for the link is not a user input.

Edit: Hum. I have a doubt.

May be should be better to use:

$this
  ->placeholderFormat('<a href=":url">@variable</a>', [
  ':url' => $url,
  '@variable' => $variable,
]);

Back to <a href=":url">Link</a> used in the template.

Thanks

Great stuff, @marcvangend (and everyone else). Alas, the patch doesn't apply directly anymore.
I've rerolled it here, haven't added anything though - just getting it working.

For those looking for why this was removed from the latest version you can find the followup issue at https://www.drupal.org/project/iframe/issues/3099249

[deleted] - duplicate due to 500 error :(