Add "description" field

For our purposes we want to have the link's description as an alternate text. Complemented the patch from #1

Maybe it's better to have on line 731 of link.module file this code:

return l($element['#item']['display_title'], $element['#item']['url'], $element['#item'], array('attributes' => array('title' => $description)));

Having title tag instead of alt (which may not work).

I'm looking for this exact functionality, so I'd definitely be interested if you went forward with this.

I applied your last patch and the description input is there in the field but nothing is getting output when entered.

Has there been any follow-ups with this? I'm looking to add addition field to individual links and the above patches are the closes I've gotten to getting something to work.

Here is a reroll that applies against DRUPAL-6--2. I'm getting a notice on the field settings page:

notice: Undefined index: description in /Users/andrew/Documents/workspace/link/link.module on line 681.

For some reason, description isn't in the loaded field, but description_value is. I'll investigate further.

Seems like there's a lot of unrelated changes rolled into this patch. Why is the attr_title stuff in here?

A lot of the naming used here could use some work. It uses a lot of abbreviations which is not done in core but I guess that's up to the maintainer.

Also don't need to put patch in the title since we have a status field.

Agreed about the size (or documentation perhaps) of the patch. I'd like to get it working first and then do a thorough review to clean it up.

I figured out why it's not working; 'description' is a special key for CCK widgets and is unset in content_field_instance_expand(). I'll be uploading a patch that renames it soon.

Here is a patch that works at least at a basic level, and implements the following changes:

• Renames the 'description' database column to 'link_description' and changes all of the form elements as well to fix #14 above.
• Fixes the form validation for the link description
• Ensures that the link title attribute is still set if token is not installed

Some unresolved issues to figure out:

• Currently the default link description field is set to a maximum of 46 characters (same as the title). I think it makes more sense for the description field to be a textarea up to 1024 characters, and trimmed if needed for the title attribute.
• I still need to review the code for the title field and ensure it's all on-task for this issue.
• It'd be great if someone could test Views and Token integration.

This is exactly what I need. It looks good so far and seems to work in views, though I have only done a basic test for views.
When you say the field is set to max 46 characters, I guess I should assume you are talking about the size of the box in the form? Because it seems to save strings longer than that.
Thanks for putting this together.

Here's an update - I think this is close to being ready to be committed. This implements the following changes:

• Changes the Link Description to a textarea, and the database column to a big text.
• Removes all changes relating to the title attribute. I checked with ezufelt, and the title attribute is rarely useful for accessibility, and it's not worth it to mirror the description in the title attribute. If we want to integrate the attribute changes I suggest we do it in a followup issue.
• Fixes a few remaining code style and textual issues.

Just realized... will we need to do a manual install hook for upgrading existing installations?

This doesn't sound like it will be a problem for accessibility, but a couple of use-cases would be nice.

Link Purpose (In Context): WCAG 2.0 success criteria 2.4.4 is a level A priority and should be followed.
http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-refs.html

Link Purpose (Link Only): WCAG 2.0 success criteria 2.4.9 is a level AAA priority, we don't aim for this level in Core, but it is nice if you can achieve it without sacrificing functionality
http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-link.html

Our specific use case for the link description is being able to cite the source of the individual who submitted the link, as well as a date for when the link was added. As well, they will have a one or two sentence summary - pretty much a teaser, but done manually as the links are all off-site and done manually.

Thanks for the W3C links, I will read through them.

After reading Success Criteria 2.4.4 it looks like this patch does things backwards, as it's an anchor followed by a div containing the description. Would it be best to wrap the link in header tags?

Subscribing, greetings, Martijn

Just realized... will we need to do a manual install hook for upgrading existing installations?

Yes, we'll need an update hook. Happily, these are usually pretty simple to do.

After reading Success Criteria 2.4.4 it looks like this patch does things backwards, as it's an anchor followed by a div containing the description. Would it be best to wrap the link in header tags?

Header tags? Like <h6>? I'm not interested in doing that. If a particular site-owner wants to override the theme function, they can. Alternately, I suppose we could include another content formatter that does header tags, but I'm not seeing a need for that yet.

On the other hand, the question of having the description before or after the link sounds like something that could be handled with a simple radio button added to the information when the site owner creates or edits the field - give them the choice of 'Display the description before the link' or 'Display the description after the link' at that time, and handle it in the theme function.

I've applied the latest patch and there seems to be a minor problem. If I create a link field and set "Link Description" to "No Description", then under "Default value" a field still appears for the description and a warning

warning: implode() [function.implode]: Invalid arguments passed in /var/www/nk/cartalk/TRUNK/drupal/includes/form.inc on line 837.

occurs when you go to create a node or configure the link field.

This problem only happens when the "Number of values" is 1.

When this occurs, the field labels in "Default value" have the field name prepended, as show in the attached screenshot. This doesn't happen when you don't get the warning (i.e. when "Number of values" is greater than 1). I can't find in the code what is doing the prepending.

Subscribing. Thanks

I'd love to see something like this added to Link, especially the D7 port. I would be happy to test this feature in Link for D7 if anyone manages a patch.

This would be a great feature. Patch fails against 6.x-2.x-dev for me, though:

~sites/all/modules/link$ patch < 779942_description_field_17.patch 
patching file link.module
Hunk #5 FAILED at 231.
Hunk #6 FAILED at 347.
Hunk #7 FAILED at 424.
Hunk #8 FAILED at 437.
Hunk #9 FAILED at 470.
Hunk #10 succeeded at 309 with fuzz 2 (offset -196 lines).
Hunk #11 FAILED at 543.
Hunk #12 succeeded at 384 (offset -227 lines).
Hunk #13 succeeded at 417 (offset -227 lines).
Hunk #14 FAILED at 690.
Hunk #15 succeeded at 465 (offset -294 lines).
Hunk #16 succeeded at 478 (offset -294 lines).
7 out of 16 hunks FAILED -- saving rejects to file link.module.rej
patching file link.views.inc
Hunk #1 FAILED at 73.
1 out of 1 hunk FAILED -- saving rejects to file link.views.inc.rej

I'm working on a patch for the d7 port, I'll put it up tomorrow but I don't know how to do the database update part. I need to add a new column to the schema, i have it working if you do a fresh install but how does the code work if you want to update the table?

This is what the link.install file looks like with the new 'description' column, how would i make an update script for it?

// $Id: link.install,v 1.6.2.3 2010/12/10 01:24:48 jcfiala Exp $

/**
 * @file
 * Install file for the link module.
 */

/**
 * Implements hook_field_schema().
 */
function link_field_schema($field) {
  return array(
    'columns' => array(
      'url' => array(
        'type' => 'varchar',
        'length' => LINK_URL_MAX_LENGTH,
        'not null' => FALSE,
        'sortable' => TRUE
      ),
      'title' => array(
        'type' => 'varchar',
        'length' => 255,
        'not null' => FALSE,
        'sortable' => TRUE
      ),
	    'description' => array(
	      'type' => 'text',
	      'size' => 'medium',
	      'not null' => FALSE
	    ),
      'attributes' => array(
        'type' => 'text',
        'size' => 'medium',
        'not null' => FALSE
      ),
    ),
  );
}

/**
 * Implements hook_update_last_removed().
 */
function link_update_last_removed() {
  return 6001;
} 

a link to the D7 patch, any feedback would be appreciated.

http://drupal.org/node/1104118

Is there a patch for the dev release from 2011-Feb-25 ?

in the last image the Description is under the title and URL mine is printing to the right is anyone else having this problem?

I am using the CKeditor module and applied the patch and and noticed that the html tags were showing up as plain text on the . So I edited

 function theme_link_formatter_default($element) {
  $description = $element['#item']['link_description'] ? ' <div class="field-type-link-description">' . check_plain($element['#item']['link_description']) . '</div>' : '';

and

function theme_link_formatter_descbefore($element) {
  $description = $element['#item']['link_description'] ? ' <div class="field-type-link-description">' . check_plain($element['#item']['link_description']) . '</div>' . ": " : '';

to use check_markup() instead of check_plain() and now it displays properly. Not sure if this is a good/secure fix for all situations, but it fixed my problem.

I also noticed that for one of my content types I wanted link to have a description, and for another one I did not. On the create/edit form for the type I did not want link description to show up, it still showed up, but just as a regular text area, not a ckeditor type of text area. I'm guessing the reason the text area is showing has something to do with the interaction between the link module with this patch and ckeditor rather than just the patch, but I don't know - I haven't done any testing. I just decided to allow optional descriptions for both, rather than mess with it.

subscribe

I'm interested in this functionality. Is there a summary of what needs to be done in order to get this patch into an official 6.x build? I can test, debug, and modify the code if needed. I am not sure what's working and what's not. So a status summary or "to be done" list would be very helpful.

I can also work on porting this to D7.

-Mike

Mike, sorry, I honestly don't understand the way of inserting a description field inside of a link field discussed here. And a radio button if the field is above or below ?? Hell. Even this isn't flexible enough for a top50 module in a framework like Drupal. If you ask me, I would rather love to kick out another html markup, which is already in.

I don't understand why you all don't group fields around link field to combine them as much as you want? This is how it is meant to be. And not to put all field types hard coded together in one module. If I like a subtitle to the title of my node, I use another text field for that. If I want another description for my image field, I use another text field for that. This what the fields are meant to be for. A text field provides text, a link field provides a link. Combine them and you will have anything what you want. This is how it should be on a DRY webframework. If you want groups of values, use fieldgroup module.

thanks 4 understanding

@Digidog:

I'm not sure if I'm the 'Mike' you refer to in your comment, but if I am, I don't understand what you're talking about.

I'll check out 'fieldgroup' module. That's what's so cool about Drupal! Just install another module, and your problems are solved. Of course, that creates new problems, but nothing that can't be managed.

Hey @ mcurry:

I don't know if you are the Mike I spoke to, did you changed your username? Sorry if you don't understand what I am saying. I am not a native english, that's why my words sometimes get missunderstood. I am just curious about implementing all things into each other again and again, which isn't a good idea to keep things neat and clean and flexible.

That's what's so cool about Drupal! Just install another module, and your problems are solved. Of course, that creates new problems, but nothing that can't be managed.

Well, a feature is not a "problem", It is a "wanted tool", which needs to get maintained. That's why you are mostly faster with 2 little tools at hand than with one big tool ;-) And If you have 3 big tasks and try to manage them with 3 big tools which have overlapping sub-features in them, you probably will have 3-6 sub-features too much you don't need. :-)))

Hell. Even this isn't flexible enough for a top50 module in a framework like Drupal.

Look at pathauto in combination with token, or at Administration menu (1.x-series). Its performance in the administration section is scary (a few hundred ms delay). The fact that a module is popular doesn't tell you anything about its quality. It only tells you that it should cover an essential CMS feature.

I don't understand why you all don't group fields around link field to combine them as much as you want?

Our business requirement is to show the link description in the tooltip. Further we use multiple link values. If you can tell me a way to group this somehow with multiple fields and a field group, so that an non-geek can understand it, I am happy. For us it is important to show "Link Title", "Link URL" and "Link Description" in the SAME line, next to each other in the node edit form. I don't see another way than having a compound field composed of three text (fields).

This is how it should be on a DRY webframework. If you want groups of values, use fieldgroup module.

I understand that the objective of Drupal is to be flexible and extensible and have lego bricks (modules) which you just have to put together. IMHO it's still not that mature. That's why feature requests and harsh comments like this come up.

Eventually it'd be really nice to have this feature somehow included, or at least a feasible work around.

@Dididog thank you for being so active in maintaining this module and actually caring about the architecture of this module. I am however a bit confused about why you are so reluctant to add a much asked for feature that was part of the d6 release of the link module to begin with. The way i look at it this isn't a new feature people are asking about but they are simply asking for the description field that was part of previous versions to be placed back.

I am currently working on a project where i have to migrate from a D6 website to a D7 website. Migrating from a d6 link field to a d7 link field makes much more sense than migrating a d6 link field to a d7 fieldgroup.

Also i'm not sure if adding another module with its own tables and UI is a much better option than adding a column to an already existing database. Using a fieldgroup with a link field and an additional description textfield would only give you more database queries with resource consuming JOINS.

So again, i admire your work on the link module and your persistence in keeping this module clean. I do however feel that when there is a need from the community to add this functionality, you should.

Edit: instead of using the fieldgroup module i prefer using the field_collection module because it supports multiple. That however still gives you an extra module, extra tables and extra database queries to select the same amount of data.

Ok i think i have to take a few things back. One of my colleagues was kind enought to point me to my error. The D6 version of the module never provided the description field. In my current project that was built by another Drupal shop, the D6 version of the link module contains the description field. The module was not placed in the 'patched' folder neither did it have any information about the fact that is was indeed patched with the patch provided in this thread.

Again: I and others still don't see the logic of the request for another description field, nor for 6 or 7. A link in web has its standart way how it should be used and apart from it I really like the idea of adding requested features as long as they aren't already build in or already part of the Drupal installation (duplicate request). And the label field of the link module IS the description field you ask for. And to get a tooltip popup you regulary use the "title" attribute in the <a> tag which is also already there in link module and as it should be used and as it is set to standart from the W3C.

Any field apart from that has nothing to do with link in particular and is rather a wish or individual concept of how you want to place another field around the link, which is the job of the manage fields section in Drupal core and where you can place as many additional description fields of another description field as you like in the near of your link. To build in a text field into the link module while we have a Drupal text field already in core, does not make much sense and has nothing to do with "ignoring the wishes of some users" than rather being careful with all the code coming in, which is also "a wish of the community" ...

Feel free to provide a patch or more details on how this make sense and collect votes for it and we will discuss it further. I also would like to hear opinions of main contributors for link module like jcfiala, sun and others. Maybe I miss something and some features of D7 link module aren't available in the D6 version, what f.e. would make my suggestions about title/label field and title attribute field obsolete.

Thank you all for your efforts, but I'm sorry to say that the D6 version is no longer supported.