Create a "Link/Button" field

[angrybrad]

Created by: Ryan (rswhite@gmail.com) on 2015/06/27 22:53:39 +0000
Votes at time of UserVoice import: 3

---

Sometimes on a page it's necessary to give the client the option to add a button and/or customize button text, url, if the url should pull from an existing entry, if url should open in new tab, add a button class via a dropdown, etc.

Right now, you can easily do this with a Matrix block and restrict it to a max 1 block, but then the user has to "add the block" and it seems like an unnecessary step. Also, if you're needing to add a customizable link/button inside a matrix field, you can't add ANOTHER matrix field, so you'd have to create all those fields individually. It would be cool to see some way of grouping all of these things together into one field and just choose all the details you want associated with the link/button.

[angrybrad]

Posted by Judd Lyon (jl@juddlyon.com) on 2016/01/28 20:46:03 +0000

---

This is a requirement on virtually every CMS-powered site. Linkit is great but not yet 2.5 compatible. It would be ideal not to rely on a third party add-on and have this be native functionality.

[angrybrad]

Posted by Kaspar (bonjour@kasparallenbach.ch) on 2015/03/11 14:14:49 +0000

---

The LinkeIt plugin is your friend: https://github.com/fruitstudios/LinkIt

[brandonkelly]

I could see us adding a generic Link field once #1662 is implemented.

[jsunsawyer]

Is this still something you're considering?

[brandonkelly]

@jsunsawyer it’s a possibility down the road, but definitely not a priority for us right now.

[bfopma]

@brandonkelly we've used LinkIt heavily in our projects; with recent conversation in Discord about LinkIt ceasing to be under active development, is there opportunity to revisit this as a built-in fieldtype in Craft?

I'm not sure if this pain point is exclusive to us, but we've both relied heavily on LinkIt and have been burned by it during Craft upgrades. A first party link fieldtype would be a very welcome addition. Thank you for considering.

[Mosnar]

I wanted to poke this discussion since we're coming up on the Craft 4 release and there's no longer a stable release available for a "Link" field. This is definitely the biggest roadblock that will be holding us back from upgrading to Craft 4 (and was also the biggest roadblock holding us back from upgrading to Craft 3).

My opinion is that a native link field should be a high priority given the crucial role it plays in every website and the lack of a well-maintained third-party alternative.

[pixelmachine]

I think it's worth mentioning a year and a half after the last response @brandonkelly that both Linkit and Link field are both back in semi-abandoned states. Neither has seen even a bugfix update in nearly a year and bug reports and PRs go mostly unresolved.

They both work (with caveats) and maybe they'll get an update for Craft 5 at some point but a first party solution would be very welcome at this point.

I'm not sure about others but we use a lot of link fields on our projects and it's a shame to have an unreliable foundation for a fairly common function. It looks like the two plugins have an install base of around 43k people so there's definitely demand there.

[bfopma]

A huge +1 on this one. This is a significant concern for us as we look ahead to Craft 5. If the developers of Typed Link (or LinkIt) decide not to update their respective plugins we are going to have a very difficult upgrade path.

Is there a possibility for Craft to formally adopt one of these, similar to the Feed Me acquisition?

[piotrpog]

@bfopma would be great if this plugin was adopted.

[brandonkelly]

It’s definitely on the nice-to-have list, but I can’t promise we’ll have a native link field in v5.

You can check out Verbb’s Hyper plugin, which is quite good, and provides a migration path for Typed Link Field, LinkIt, and Link.

[leevigraham]

+1 for https://verbb.io/craft-plugins/hyper/features

[cherrykoda]

I was about to make a new issue, but found this one. So I'll paste my details here instead.

A large portion of the community was relying on https://plugins.craftcms.com/typedlinkfield which is no longer being maintained. The remaining plugins available are 3rd party and cost money, but customers expect a link field that can handle entry/url/email/tel as a native CMS field. Other CMS platforms that compete with Craft CMS offer it, and its a standard in familiar UIs across apps, platforms etc.

Minimum Viable Solution:
A link field that handles choosing an entry, a URL, and option to open in new window

Best Solution:
MVS in addition to:
limiting the entry sections available to choose from
Assets Picker

"Extra":
noref/nofollow option on the link
aria support
Users Picker

[alexanderloewe]

@mfell

No, you do that once (per Builder)

Either you need a block with conditions
Or you build several BlockTyes in the 2nd variant.

You can then reactivate these as child blocks anywhere with a mouse click.

But none of the variants is a perfect solution

[mfell]

@alexanderloewe yepp ... your're right, thanks :)

But I agree ... none is a perfect solution.
At the moment, I think the best solution is just Hyper. (With a lot of stomach pain.)

[mfell]

@brandonkelly Dear Brandon, you are very busy with Craft 5.0.x I guess? May I ask if there is a chance for a core solution in Craft 5.x? If so, it would be nice to know for planning.

[thupsi]

@alexanderloewe While I agree that things can be improved, and you have every right to voice your concerns, it seems to me you are a bit harsh. The new features in Craft 5 are regarded by many, myself included, as huge steps forward in content modeling and editing. I, you, and others may think of a myriad ways to take this even further, but P&T have a finite amount of resources and they are pretty much developing non-stop. Heck, Brandon is doing commits every 5 minutes, even on weekends. Let's not forget that they are human beings, not robots 🤖. Burnout being a thing, especially in this industry, let's not contribute to it. Peace 😊

[alexanderloewe]

@thupsi: It's not a criticism of people, but rather of the priorities set for the Craft CMS project, which in the end will be carried by all developers - who choose this platform for themselves - and their customers.

I have been using Craft CMS for 9 years, and unfortunately some problems that were already known 9 years ago have not really been implemented as many developers would like. I haven't expressed my opinion here on Github for many years, but after talking to many developers who see similar things to me, I want to express it here.

I would like the P&T team to be more responsive to the wishes of the developers. Because at the end of the day, Craft CMS is one of the best systems for what we use it for every day. But it could be even better. If we were to draw more on concepts here and there that have already been tried and tested many times. Even if not all P&T developers like them.

All the more reason for me to hope that the P&T team is successful, because we enjoy using the product they build.

[khalwat]

I agree that some kind of a link field (integrated with CKEditor) should be in core, primarily because it's a fundamental field type that is important to many Craft CMS builds.

There's already a URL field type baked in:

...but it's a little limited in scope, and doesn't allow linking to content in Craft.

Being able to create self-referencing links to content is so important to SEO and to UX for many sites, I feel that expanding the URL field to encompass the ability to link to arbitrary elements (and add links in Rich Text Fields) is important to the content authoring experience.

[mfell]

Yes ... but you mentioned it: It's too limited in scope / function.

[splendidrob]

Been exploring Craft 5 and options for this today and come up with a solution that for my needs at least works really well, just as good as the Link Field plugin and fully native. Many thanks to @thupsi and @stephanedemotte above who guided me in this direction! Gotta say I am loving how flexible the data structure is in Craft 5, its so much neater and lets you work more in a modular fashion within Craft itself similar to how we want to build out front end structures...Thanks so much for the update!

1: Create the entry type

I made an entry type of "Button" with the required fields:

• Drop down for linkType with options: none, url, entry and asset
• The title for the button text
• A toggle field for 'open in new tab?'
• The fields for a 'Url', 'Entry' and 'Asset' - these had conditionals applied so they will only show depending on the link type selected in the dropdown.
• A second drop down for optional styling (btn--primary btn--secondary etc)
• Some additional fields for colours (we have global colours for all buttons and now we can add optional overrides within the entry type, this is super useful!)

2: Create the field

I then created a matrix field "buttons" with a max of 2 so that we can output the "button" entry type wherever we want with a maximum of two buttons, generally a primary and secondary (I left this selectable with a dropdown but you could specify this in the code)

We now have a super flexible "link" entry type that can be used either directly in entries or as a field inside other entry types or another matrix field.

Here are a couple of code examples for outputting (i've removed lots of other include settings for clarity) Built these quickly today so could probably be tidied up a fair bit:

default.twig main page entry:

{% include '_includes/cp.hero' with {
    buttons: entry.buttons,
  } %}

cp.hero.twig include:

{% set buttons = buttons ?? null %}

<section class="hero>
      {% if buttons | length %}
          {% for cta in buttons.all() %}
            {% include '_includes/cp.cta.twig' with {
              cta_type: cta.linkType,
              cta_text: cta.title,
              cta_ext_url: cta.externalLink,
              cta_entry: cta.entries.one(),
              cta_asset: cta.asset.one(),
              cta_newtab: cta.toggle,
              cta_classes: cta.buttonStyle == 'primary' ? 'btn w-100 w-auto@pw' : 'btn btn--secondary w-100 w-auto@pw',
              cta_bg_clr: cta.buttonBackgroundColour,
              cta_bg_hvr_clr: cta.buttonRolloverBackgroundColour,
              cta_txt_clr: cta.buttonTextColour,
              cta_txt_hvr_clr: cta.buttonRolloverTextColour,
            } %}
          {% endfor %}
      {% endif %}
</section><!--/hero-->

cp.cta.twig our call to action or button include:

{% set cta_type = cta_type | default('none') %}
{% set cta_text = cta_text | default('View' | t) %}
{% set cta_newtab = cta_newtab ?? null %}
{% set cta_classes = cta_classes | default('btn') %}

{% set cta_bg_clr = cta_bg_clr ?? null %}
{% set cta_bg_hvr_clr = cta_bg_hvr_clr ?? null %}
{% set cta_txt_clr = cta_txt_clr ?? null %}
{% set cta_txt_hvr_clr = cta_txt_hvr_clr ?? null %}

{% set cta_ext_url = cta_ext_url ?? null %}
{% set cta_entry = cta_entry ?? null %}
{% set cta_asset = cta_asset ?? null %}
{% set cta_url = cta_url ?? null %}

{% if cta_type == 'url' %}
  {% set cta_url = cta_ext_url %}
{% elseif cta_type == 'entry' %}
  {% set cta_url = cta_entry.url %}
{% elseif cta_type == 'asset' %}
  {% set cta_url = cta_asset.url %}
{% endif %}

{% if cta_url != 'none' %}
  <a href="{{ cta_url }}"
      {% if cta_newtab %}target="_blank"{% endif %}
      class="{{ cta_classes }}"
      style="
        --btn-bg-clr: {{ cta_bg_clr ? cta_bg_clr : branding.buttonBackgroundColour }};
        --btn-rollover-bg-clr: {{ cta_bg_hvr_clr ? cta_bg_hvr_clr : branding.buttonRolloverBackgroundColour }};
        --btn-clr: {{ cta_txt_clr ? cta_txt_clr : branding.buttonTextColour }};
        --btn-rollover-clr: {{ cta_txt_hvr_clr ? cta_txt_hvr_clr : branding.buttonRolloverTextColour }};
      "
  >
    {{ cta_text }}
  </a>
{% endif %}

Having gone through this process I can see why P&T don't have a super high priority for this as its definitely possible to build something way more flexible. Downsides obviously this is no use for old sites that already use the link field plugin! Currently we aren't able to update most of our old sites as nearly all link data is stored in the typed link field and this would require us going through and re-doing all the link content which is not viable. But for new sites this seems a good option moving forward and has enabled me to ditch a bunch of plugins - no need for supertable or neo etc anymore...

Hope this helps someone out and open to any suggestions as to how to improve!

In use directly in an entry:

In use inside a matrix field:

[CreateSean]

This is an interesting approach and I might adapt it, but I would still prefer a native field with options from P&T

[alexanderloewe]

On some projects, we use a similar setup. Well done!

[alexanderloewe]

@CreateSean We too ;)

[alexanderloewe]

I Instead of a link field, I would rather suggest something like an entry field, which does not have a type limit. So you could mix elements such as an entry, an asset or a product from Commerce in a «MultiType» field and output these contents in whatever form you want. This would solve more than one problem.

Yes, you can't map an external URL, an e-mail and a telephone kink with it, but everything else.