I was having an issue with a View I was using where I was outputting one CCK field that was rewritten as a link via another CCK field via the token. However, some changes came about where the CCK link field was not required, so it got removed from a few nodes. When this happened, the View still rewrote the field with a link, but it was a link to the root. Since we can't use PHP in the "Rewrite the output of this field", I wasn't really sure how to change this. I ended up changing some code in line 626 of views/handlers/views_handler_field.inc:

Before:

$value .= l($text, $path, $options);

After:

if (!empty($path)) {
  $value .= l($text, $path, $options);
} else {
  $value .= $text;
}

This works in my case because I didn't want the link to show if the token was blank. However, I can imagine (maybe) that some people would actually still want the link to show up. Hence, my feature request is some kind of control, probably a checkbox right under "Output this field as a link", that would allow for the value not to be rewritten as a link (effectively what I did in my code) if the link ends up being blank. Just thought I'd bring it up in case anyone else ever had this problem, and to see if this was a reasonable feature.

Comments

merlinofchaos’s picture

Hmm. Is there any value to actually having a blank link? Because I can't think of any. I'm not sure you can use this feature to properly make anchors right now, which is the only use case I can think of.

BillyMG’s picture

Version: 6.x-2.7 » 6.x-3.x-dev
Status: Active » Needs review
StatusFileSize
new1.91 KB

Well, you don't get a completely blank link. Since the path is run through the url() function, you get a base link to the site root, more or less. As such, some people may desire this functionality (can't imagine why). Since it's relatively minor either way, I've made a patch that adds a simple checkbox that should do the trick. By default it remains unchecked, and does the normal behavior. However, if it is checked and the path ends up being empty(), it will drop the link part and keep the content. Pretty minor, but it worked well for me.

merlinofchaos’s picture

Let's take out the checkbox; it seems pretty pointless. 99.9% of the users will never want it to just randomly link to the front page of the site, and that .1% (if even that much) that does can theme it to work that way.

BillyMG’s picture

StatusFileSize
new753 bytes

Well, I don't really see the harm in adding functionality like that checkbox, even if almost no one would have a reason to use it. It could also be easily inversed so the checkbox negated the condition, so checking it off would just always use the link, regardless of whether it was empty or not. This would change the default behavior, but still allow someone to have their empty links if they want it, without having to worry about theming it (seems no reason to put extra work on the user if the functionality is as simple as a few lines that were already written). Regardless, here is a full patch that does the same thing as my code in the first post, which is just to check if the link is blank and change the output accordingly.

merlinofchaos’s picture

Well, generally the harm is that the UI already has a LOT of options. Adding options that are basically useless is just one more piece of data to confuse a user. It's true that, individually, it may not be a big deal, but they add up which is why I am being kind of stiff about it. The Views UI is already quite hard for people who don't really know what they are doing.

BillyMG’s picture

Makes sense. Well, the simple patch is provided in #4. Thanks for all your quick responses on this, even if it is a very minor issue, and thanks for all of your hard work on Views, which really makes Drupal shine.

stborchert’s picture

StatusFileSize
new887 bytes

Same result, different way of implementation. After applying my patch only the given text is returned by render_as_link (without prefix or suffix).

Don't know atm which one is better, but diversity is always a plus :)

merlinofchaos’s picture

Status: Needs review » Fixed

I like #7 better since it shortcuts unneeded processing and saves a few cycles. Minor, perhaps, but this is an area where performance is already poor. Committed to all branches and I credited both of you.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.