craft-linkfield icon indicating copy to clipboard operation
craft-linkfield copied to clipboard

Link field falling back to "(No link)" when no URL is entered for the "URL" link type

Open sidm1983 opened this issue 3 years ago • 8 comments

Hi,

So I have been testing version 2.0.0-rc.1 of the typed link field plugin. I have noticed the following behaviour:

If I choose the "URL" link type and enter a custom text but don't actually enter a URL like this:

image

When I save the entry, it reverts to the "(No link)" link type like this:

image

Which would be fine, except when I then query it via GraphQL, I get the following results:

"linkTo": {
  "ariaLabel": null,
  "customText": "Visit our site",
  "target": null,
  "title": null,
  "type": "url",
  "url": null,
  "element": null
}

As you can see, I still get back the result as if it has saved the "URL" link type with the correct custom text and null URL, instead of everything being null or empty.

Further to this, if I now just save the entry again without making any changes, it re-saves the "(No link)" link type again properly and this time the GraphQL result is correct, like this:

"linkTo": {
  "ariaLabel": null,
  "customText": null,
  "target": null,
  "title": null,
  "type": "",
  "url": null,
  "element": null
}

I would expect that if not entering a URL when selecting the "URL" link type falls back to the "(No link)" link type, then it should be immediately saved as a blank entry in the database as well. This behaviour is happening for all link types and not just the "URL" one.

Also, ideally, instead of falling back to the "(No link)" option, it would be great to make the link field throw a validation error (and prevent entry save) if the CMS author selects a "URL" link type and doesn't enter the URL.

Currently, it is very easy for a CMS author to miss the fact that they forgot to enter a URL and that the field just fell back to "(No link)" without warning. It would be much clearer if the author is prompted with a validation error message that tells them they have missed something.

What do you think about this? If you agree, then please also apply this new behaviour to all the other link types as well. If not, it would be great to at least get the above GraphQL/database saving issue fixed.

Please let me know what you think when you get a chance. Thank you so much.

sidm1983 avatar Mar 22 '21 03:03 sidm1983

Hm, yes, the entry "(No link)" is more of a cosmetic thing than a real technical construct. We introduced this link type to make the forms more readable in the control panel, as it's more clear than an empty link field.

I don't like the idea of the raising an error here. I think we can assume that an editor is smart enough to know that he has to enter a url / select an entry for the link field to contain something. From the perspective of an editor, I do not see an issue here and I would say it is working as intended. If a field is required we do raise an error, so this would only happen if a field has been left empty.

The current implementation is invoked quite lately in the field rendering process which leads to the quirky save behavior. That's not intended and I think we should fix that, the values should be set to null after the first save.

sebastian-lenz avatar Mar 23 '21 19:03 sebastian-lenz

Thank you! I will keep an eye out for the quirky save behaviour fix.

Also, here are my thoughts on the falling back to the "(No link)" option.

I don't like the idea of the raising an error here. I think we can assume that an editor is smart enough to know that he has to enter a url / select an entry for the link field to contain something. From the perspective of an editor, I do not see an issue here and I would say it is working as intended. If a field is required we do raise an error, so this would only happen if a field has been left empty.

I agree that the editor is smart enough, but it is not really about that. As human beings, we often get interrupted or distracted by someone coming to talk to us, or an incoming email, phone call or text message. These types of interruptions or distractions make it really easy to lose focus and lose track of your work and forget that you've selected the "URL" link type but haven't actually put in the URL like you initially intended before you were interrupted/distracted. At this point, if the editor decides to hit save thinking they have completed everything, the entry save will be successful and they will then be taken back to the entries listing page. They won't even realise that their link field has been defaulted back to "(No link)". This is the problem I have with this fallback behaviour. The user is not informed that the fallback has happened and the entry saves successfully anyway.

I know that this is not the end of the world and it is easy for the editor to fix this eventually if they realise their mistake (there is a chance they may not realise their mistake for a long time). However, I guess I am thinking that it is better to save the editor from his/her mistake sooner rather than later. In my mind, if you have selected the "URL" link type, that should make the URL text field mandatory (and marked with a red asterisk just like other mandatory fields in Craft) and whether you enter an invalid/incomplete URL like http://google. or you leave it completely blank, both of those scenarios should be considered invalid URLs. From my own experience, I was expecting it to show me an error and was definitely not expecting it to completely change the value of the link type dropdown because I left the URL text box blank and not actually inform me about it (i.e. a mistake/omission in one HTML form field is now affecting the behaviour of the entire link field without any notice or warning to the user).

Another way to look at it is to compare it to a contact us form on any website. The email field on a contact us form is usually mandatory, so whether you leave it blank or enter an invalid email address, you typically get a message reminding you to enter a valid email address in order to submit the form successfully. People are trained to expect this type of validation error message even if they've left the field blank and not just if they entered an invalid email address. Imagine the confusion it would cause if the contact us form only showed you an error message when you entered an invalid email address and for the scenario where you left it blank, it showed you a thank you message but without actually saving/sending the contact us form details and didn't inform you about it. You would happily move on thinking that your contact us form details have been received by the website, whereas that is not the case and no one will actually get back to you.

I feel like the above analogy is similar to what the link field is doing by just defaulting to the "(No link)" option (and not informing the editor) when the "URL" link type is selected and no actual URL is supplied. This is totally unexpected behaviour.

I think the invalid URL scenario and the blank URL scenario should both be considered input errors and the user should be shown a validation error message in both scenarios.

To cut a long story short, when a form field on any HTML form is mandatory, it will typically display a validation error message when the field is left empty or if the user enters an invalid value. Testers will usually do these two tests when testing a mandatory form field. It is an expected pattern that all mandatory form fields follow. I feel like this fallback behaviour in the link field and not validating blank URLs breaks away from the established behaviours that people have come to expect with mandatory form fields.

What do you think about this perspective? Looking forward to hearing your thoughts on this. Thank you.

sidm1983 avatar Mar 24 '21 14:03 sidm1983

Another way to look at it is to compare it to a contact us form on any website. The email field on a contact us form is usually mandatory, so whether you leave it blank or enter an invalid email address, you typically get a message reminding you to enter a valid email address in order to submit the form successfully.

That's my point and you basically contradict yourself. If the link field is marked as mandatory or required, we already raise an error and force the user to enter something. If the field is optional, users should be able to leave it empty. The sole intend of the no link option was to make the fields easier and faster to read.

sebastian-lenz avatar Apr 14 '21 20:04 sebastian-lenz

That's my point and you basically contradict yourself. If the link field is marked as mandatory or required, we already raise an error and force the user to enter something. If the field is optional, users should be able to leave it empty. The sole intend of the no link option was to make the fields easier and faster to read.

I am aware that the link field forces the user to enter something if the link field is marked mandatory. I am not contradicting myself at all. I guess what I am saying is that when the link field is not marked mandatory and the user has selected the 'URL' option from the dropdown list, then at that point, in my opinion, the URL text box (or entry/asset selector field) should become momentarily mandatory as the user has now selected that they want to enter a URL by selecting it from the dropdown which should make the URL textbox mandatory (i.e. conditionally mandatory based on the selection of the dropdown). This way it is clear and the user can decide for themselves, upon getting a missing value error message, whether they meant to enter a URL and just forgot or whether they really meant to go back to the "(No link)" option.

My main point is that the current behaviour of defaulting to "(No link)" without informing the user that this has happened is not very intuitive and I certainly wasn't expecting it the first time it happened to me. I actually didn't realise that had happened because the entry saved successfully and Craft CMS went back to the entry listing page. It wasn't until I tried to load that entry on the front-end that I realised the URL was missing and that the field had reverted to the "(No link)" option by itself when I went back to check the entry in the control panel.

Having said that, I do see your point as well. With the current behaviour, it is convenient that it reverts back to "(No link)" if the user doesn't supply all the info, but the downside is that there is a chance it is not what they were expecting.

With what I am suggesting, it makes it clear to the user what the issue is without silently defaulting, but the downside here is that the user has to take some action to correct the problem themselves once they see the error message about the URL value being mandatory because they selected the "URL" option from the dropdown list. Both behaviours are valid, but I prefer this one because then there is no chance for any misunderstanding and the data saved always matches the user's intent and expectation.

I guess there different schools of thought on this type of stuff. Happy for you to leave the behaviour as is if you don't agree with what I have said above.

Regardless of what you decide about the above behaviour, it would still be great to fix the quirky save behaviour I described in my original post above.

Thank you for your time and patience for hearing me out. I really appreciate it. 🙂🙏🏽

sidm1983 avatar Apr 18 '21 08:04 sidm1983

I am quite impressed that you took so much time to explain your position here, thanks for the insights. However, I still don't like the idea of raising an error in that situation. In past versions, before we've introduced the "No link" entry in the dropdown, editors where able to leave the input fields empty (if the field was not required) to indicate the state "no link". And basically this is how it still works. And I want to keep the rate of possible errors low.

You are also the first to bring up this topic, so I kind of have to assume that the current behavior is okay for other users? Give me some time to think about it, but currently I am happy with the old behavior.

Yet, I've just created a path that will ensure that the fields are correctly set to null once the empty state is entered.

sebastian-lenz avatar May 05 '21 20:05 sebastian-lenz

@sebastian-lenz thank you for the save behaviour fix. I really appreciate it. Looking forward to testing it out in version 2.0.0-rc.2 (or whatever the next release version is) 🙏🏽👍🏽🙂

sidm1983 avatar May 09 '21 13:05 sidm1983

I'm running into a related problem (on 2.0.0-rc.1) where if you have a URL field and change it to "no link", it deletes the URL but not the custom text. I would expect the custom text to get set to null as well.

It's a very niche problem, I assume, but it's causing bugs for us! Any chance of a fix?

KatieMFritz avatar Mar 09 '22 19:03 KatieMFritz

I got the same problem on 2.1.4, the field without link but has custom text cannot be saved (Changed to "no link"), and any existing those fields will finally disappear after several saves

ce2cs avatar Nov 22 '22 21:11 ce2cs