Include URL in description field of a checkbox (form)

How can I insert a URL in the description text of a checkbox? I tried markdown such as [/privacy](privacy) but also HTML, such as <a href="/privacy" target="_blank">privacy</a>, both don’t work.

@AquaL1te, I figured you wouldn’t be the first… So I searched on the repo of the Form plugin and found the following: Markdown in form label to add page link.

So it can be done. It has been mentioned in the docs, but not very overt.

      type: checkbox
      markdown: true
      label: 'I have read the [privacy](/privacy?target=_blank) statement'

Same goes for property description

But wait there is more…

  • It has been implemented in the Form plugin, however, some themes override field templates. For example, Quark overrides the checkbox.html.twig template and did not implement the markdown option. Confusing…
  • If the theme does override checkbox.html.twig, you’ll have to override that template yourself in a child theme. To output the Markdown label, use something like:
    {{ field.label|t|markdown }}
  • The default styling of the checkbox provided by the Form plugin might need some css tweaking to get it nicely aligned.
1 Like

Thanks! This works great! However, when the data.txt.twig is loaded, it shows the markdown in the “thankyou” page and in the email.

I guess this is because of the line {{- field.label|t|e }}: {{ string(value is iterable ? value|json_encode : value) ~ "\n" }} in /plugins/form/templates/forms/default/data.txt.twig. It probably should include a field.label|t|markdown.

But changing that as a test didn’t change the outcome. I also think it may not be wise to enable it. Because it may allow []( in emails.

What do you think? Is there a way to just fix this one markdown line from the checkbox?

@AquaL1te, data.txt.twig is being used for saving the form into a text file. For html the template data.html.twig is being used.


  • Use the description property with Markdown instead of the label.
  • Add |markdown filter to data.html.twig, but…
    • This will cause layout issues because the html generated from the markdown is wrapped inside a paragraph <p>.
  • Add a condition to data.html.twig and test if field is ‘privacy’ and output other constant value as label for field.
1 Like

How would this work exactly? I cannot find this description property in the docs. Just adding it doesn’t seem to do anything.

            label: 'Have you read our [privacy statement](/privacy-verklaring) and do you agree?'
            description: 'test'
            type: checkboxes
            markdown: true
                agreed: 'I''ve read it and I agree'
                required: true
                message: 'Privacy policy'

@AquaL1te, Can’t see what “Just adding it doesn’t seem to do anything.” should look like…

But this is what your field definition looks like in my site:

Description ‘test’ is clearly visible.

I admit, it is poorly documented. It’s open source, so please update the docs.

By the way, what makes you choose using field type checkboxes instead of checkbox. You’re only using a single option.

1 Like

It was a cache issue :nerd_face: Sorry for being unclear. But there was no change when I added the description property before.

When using checkbox it’s indeed more suited for the task. But then markdown support is gone. Cleared the cache, but whatever I do, the [privacy statement](/privacy-verklaring) remains in the checkbox text rather than a URL.

I would be happy to update the docs. But the description property is not clear to myself yet. It adds a subtext, which is nice, and it has support for markdown. But it doesn’t change the body of the sent mail or successfully sent the email page. The description field seems to be only used in the contact form as a subtext. But not anywhere else, correct? It’s also not used in data.html.twig, so that does make sense.

So I guess your last suggestion would then be the only workable solution. By overriding data.html.twig in my custom theme and then add a conditional for the privacy field.

If I could do some Python stuff like this in Jinja, I could solve it easier.

>>> import re
>>> inline_markdown = re.compile(r'\[([^\]]+)\]\(([^)]+)\)')
>>> text="Heb je onze [privacy verklaring](/privacy-verklaring) gelezen en ga je akkoord?"
>>> links = dict(inline_markdown.findall(text))
>>> print(links)
{'privacy verklaring': '/privacy-verklaring'}

And then select the key from that dict.

I’ve solved it now with this.

{% block field_label %}
{% if index == 'privacy-policy' %}
    {% if grav.language.getLanguage != 'nl' %}
        <strong>Have you read our <a href="/privacy-verklaring">privacy statement</a> and do you agree?</strong>
    {% else %}
        <strong>Heb je onze <a href="/privacy-verklaring">privacy verklaring</a> gelezen en ga je akkoord?</strong>
    {% endif %}
{% else %}
    <strong>{{ field.label|t|e }}</strong>:
{% endif %}
{% endblock %}

@AquaL1te Your original question has been solved. Using Markdown, a URL can be generated in both ‘label’ and ‘description’ of the online form.

Usually, when a question has been solved, for follow up questions a new post should be created with its own suitable title.

But then markdown support is gone. Cleared the cache, but whatever I do, the [privacy statement](/privacy-verklaring) remains in the checkbox text rather than a URL.

Gone where? Are you still talking about the form? Have a look at my previous reply why the URL might not appear in the form.

The description field seems to be only used in the contact form as a subtext. But not anywhere else, correct?

That might be true, I haven’t looked at it. But why would one want to add a description into the thankyou page and email? The description is to provide extra info about the question, which shouldn’t be needed in a summary of the entered values.

If you want the URL being included in the thankyou page and email you can:

  • Use the label and fix the data.html.twig template to process Markdown on the label
  • Or, edit the data.html.twig template and add the description field to the output.

If I could do some Python stuff like this in Jinja, I could solve it easier.

Why are you bringing Python into this post? Does it add anything I should know but fail to see?

NB. Don’t use hardcoded translated strings into Twig. That’s what language.yaml is for in combination with filter |t.

1 Like

In the thankyou page. And indeed best is probably to solve it in the data.html.twig. I brought up the Python stuff because in Ansible there quite some tricks similar to Python in Jinja (there are also some Ansible functions in there of course). Was just poking around how to do it in Python and then checked if Jinja could do something similar. But that doesn’t seem to be the case.

I’ll have a look at language.yaml, thanks for the suggestions!

Sorry, but I keep messing around.

This is the languages.yaml I’ve created for my custom theme.

        PRIVACY_STATEMENT_QUESTION: "Have you read our <a href=\"{{ base_url ~ '/privacy-verklaring' }}\">privacy statement</a> and do you agree?"
        PRIVACY_STATEMENT_QUESTION: "Heb je onze <a href=\"{{ base_url ~ '/privacy-verklaring' }}\">privacy verklaring</a> gelezen en ga je akkoord?"

I then modified my custom data.html.twig with this:

{% block field_label %}
{# Custom fields #}
{% if index == 'privacy-policy' %}
    <strong>{{ 'THEME_TZM.PRIVACY_STATEMENT_QUESTION'|t|markdown }}</strong>
{% else %}
    <strong>{{ field.label|t|e }}</strong>:
{% endif %}
{# Enf of custom fields #}
{% endblock %}

Which as a result does not expand the {{ base_url }} variable. It looks like this Have you read our <a href="{{ base_url ~ '/privacy-verklaring' }}">privacy statement</a> and do you agree?.

I’m probably missing something I could’ve found in the docs, I tried to Duck for it, but can’t find something.

@AquaL1te, As suggested before, it is a good habit to open a new post for a new question.

This is a question about implementing translations and has got nothing to do with "Include URL in description field of a checkbox (form)"

The forum is not only an easy tool for questioners to get their problems solved, it is also about building a knowledge base where others can easily find an answer to their questions. Burying separate topics inside a thread does not help.


Once this has been fixed in the Quark theme I’ll use this.