Wrong `for` attribute on the label

As far as I can see from your code and my test installation in comparision: your label doesn't cover the input field you think of here. Your label is the label for the whole link field group as typed in manage fields, while your input (url) is one of 3 possible link module inputs (title, url, title attr.), but with a disabled label in this case.

That's why it looks like a wrong label for another input. (minor btw ... )

Same problem here.

Label: <label for="edit-field-website-und-0">Website </label>

Input: <input type="text" id="edit-field-website-und-0-url" name="field_website[und][0][url]" value="" size="60" maxlength="2048" class="form-text">

That's bad. It's not minor. All the labels in my forms work, except the link fields.

Why does it have these extra wrappers anyway? I've selected No title as Link title, so it should be an as-simple-as-possible form element with just a label and input IMO.

Full form element:

<div class="field-type-link-field field-name-field-website field-widget-link-field form-wrapper" id="edit-field-website">
	<div id="field-website-add-more-wrapper">
		<div class="form-item form-type-link-field form-item-field-website-und-0">
			<label for="edit-field-website-und-0">Website </label>
			<div class="link-field-subrow clearfix">
				<div class="link-field-url">
					<div class="form-item form-type-textfield form-item-field-website-und-0-url">
						<input type="text" id="edit-field-website-und-0-url" name="field_website[und][0][url]" value="" size="60" maxlength="2048" class="form-text">
					</div>
				</div>
			</div>
		</div>
	</div>
</div>

Better title.
Not resolved.

This is an old thread, but has anyone found a resolution for this issue? It still occurs. The mismatching attributes make these labels non-compliant with 508 standards. Here is the example occurring in my Link instance:

<div id="edit-field-workapp-website" class="field-type-link-field field-name-field-workapp-website field-widget-link-field form-wrapper">
	<div id="field-workapp-website-add-more-wrapper">
		<div class="form-item form-type-link-field form-item-field-workapp-website-und-0">
			<label for="edit-field-workapp-website-und-0">Website </label>
			<div class="link-field-subrow clearfix">
				<div class="link-field-url">
					<div class="form-item form-type-textfield form-item-field-workapp-website-und-0-url">
						<input type="text" class="form-text" maxlength="2048" size="60" value="" name="field_workapp_website[und][0][url]" id="edit-field-workapp-website-und-0-url">
					</div>
				</div>
			</div>
		</div>
	</div>
</div>

for="edit-field-workapp-website-und-0" in the label is not an exact match to id="edit-field-workapp-website-und-0-url" or name="field_workapp_website[und][0][url]" in the text input.

Has anyone found a fix for this? Perhaps a work-around function in template.php? This is also occurring in the File upload form input field, but perhaps a fix for one field type may be applicable to the other.

Thanks for any help or guidance with this issue,
Connie

It's a good thing to bring up, definitely, and we'll see what we can do, but we're wide open for patches from anyone who wants to volunteer some time.

I am no coder, but I'll have time to look into this sometime next week. We have to have 508 compliancy for this form, so I've got to find some solution.

Thanks!
Connie

I'm not sure this is the 'correct' method, but it works and it's clean and simple.

Patch (against dev (54e0639c94a35d6968f016d4dc949e217d5300d3)) attached.

Thanks rudiedirkx, although I used the function in my template.php file, renaming the preprocess to my theme name. It works, but like you I wonder if this is the correct way to do it. Here is the same code in your patch, but used in my template.php (where oncfacabartik is our theme name).

/**
* Implementation of template_preprocess_form_element_label().
*/
function oncfacabartik_preprocess_form_element_label(&$vars) {
  $element = &$vars['element'];
  if ('link_field' == $element['#type']) {
    if (isset($element['url']) && !isset($element['title'])) {
      // Link label directly to the URL field.
      $element['#id'] .= '-url';
    }
  }
}

I will also try this in other cases where the label values do not match the input values (in my case, the "file" field). Hope this helps others, and if anyone knows a better way to do this, please post it here.

Connie

That would work, but it's a Link bug, so it has to be a Link patch. I think this is the correct way.

Any Link people to review?

Okay, okay, I see it.

The problem is this: Link field has multiple labels, right? If you take a look at a link field with title and url, you'll see something like:

LInk Label

Title ... URL
(and then the fields for those.)

In that structure, Link Label says it's for "edit-field-link-und-0", and the Title is for edit-field-link-und-0-title and the URL is for edit-field-link-und-0-url. This works fine and makes sense.

But, when you only have the URL involved, the Title and URL aren't shown - so we just have Link Label and it still points to edit-field-link-und-0, which (as we've discussed above) is a bug for Link.

Ah!

Okay, I think this is fixed, but I need input on this. Feel free to shove this back to active / needs work if what I've done doesn't work.

Before, what was happening is the URL label on the field was being removed from the display. While digging through how the labels get generated, I discovered that you can set a title's display to 'invisible' - it still gets created, but it doesn't get displayed. I've now got the code setting this label to be invisible, so there's a label that points to the field.

If that's not good, please hash it out here with ideas on it. Also, if anyone knows of other fields which have two or more sub-fields and they collapse down to one like this, let me know so I can see how they handle this.

Thanks so much for your effort on this. A similar issue exists in the File field in Core. Core folks are hard at work on that issue here: http://drupal.org/node/1734716.

Connie

Huh. I'm amused that they fixed it by throwing an -upload at the end of the #id - that strikes me as a rough way to fix the problem.

Doesn't really help the Link module though, does it? It is fixed in Link? Can we have proof? =) A commit id or Repo Viewer URL? Thanks

Hiding the title this way is better, sure, but it doesn't actually solve the problem... At all. If the Link Title field is Static or Title No Title, the label points to a non-existing textfield. (Or technically more correct: the textfield's label doesn't exist anymore.)

Definitely not fixed. The attached patch from #8 (or alike) is required.

Let's quickly add the supposed fix from #8 in the dev branch for thoose who still need it.

I created a quick fix based on #8 but I'll close this issue now due to inactivity for 12 years and upcoming EOL of Drupal 7 in January 2025. While the project version for Drupal 7 will keep providing support for security issues and website breaking bug fixes for Drupal 7, we should try to minimize the open issues for Drupal 7 in the queue as much as possible. Thanks for the report and all the efforts in here. Feel free to re-open if you can provide a better fix or found an additional related problem which increases the issue priority to "Critical" here.