Hi,
I have a link field that is correctly storing <front>. I've trawled through the module code a little and it is correctly being validated as LINK_FRONT. However, when the node is displayed, the link looks like this:
<a href="/%26lt%3Bfront%26gt%3B">Find out more</a>

I'm not sure why. Can anyone help please?

If you require any further info, please just let me know. I'm using D7.10

Matthew

Comments

mshepherd’s picture

mshepherd commented

If I change the field display format to be "URL, as link" (it was "Title, as link - default"), the URL is correctly displayed, but the link is as above:

<a href="/%26lt%3Bfront%26gt%3B">http://bewdley.illuminateweb.org.uk/</a>

dqd’s picture

dqd
Location London | N.Y.C | Paris | Hamburg | Berlin
commented
Category: bug » feature

mshepherd,

thanks for report. Actually you are right with it, but I would rather mark it as feature request since the special link <front> is more a menu link kind of thing than a field link scenario and is not supported yet in link module. Link field module supports internal links, that's true, but front is special and needs exceptions in the validation process, I think. YOu can work around this temporary by using /node, which has the same effect.

But your report is good to start taking a look on it. And maybe you or others can start providing ideas how to solve this? I would come back to it, when I am ready with all the other issues I still have to go thru'

thanks!

mshepherd’s picture

mshepherd commented

@Digidog - thanks for your reply, but I thought this was already a feature - the project page mentions twice that a link field will accept <front> as input:

...while <front> will convert into http://drupal.org and node/74971 into http://drupal.org/project/link

Anchors and query strings may also be used in any of these cases, including: node/74971/edit?destination=node/74972<front>#pager

dqd’s picture

dqd
Location London | N.Y.C | Paris | Hamburg | Berlin
commented
Category: feature » bug

@mshepherd: huh? ....oh, thanks for pointing out.... o.O
I really didn't know that (only the second part was in my mind) ... heh.
Ok then we should move it back to ...

dqd’s picture

dqd
Location London | N.Y.C | Paris | Hamburg | Berlin
commented
Status: Active » Closed (duplicate)
Issue tags: +field validation

Dear followers of this issue: But please read the project page info of link module for further validation issues. There is already an issue to collect and discuss all possible validation scenarios in general. That's why I will mark this one here as duplicate. I need all concentration inside the ONE and only discussion to move forward. After a D7 implementation we will provide a D6 backport.

Explanation: There are too many corner cases and validation wishes of users to implement them all serially one after the other. We would have a 40 lines cluttered settings form for validation methods only conflicting each other. I think, the right way is to find a maybe more complex but all embracing configuration method, which lets the admin better decide how and when to validate the url. Including a good description which helps to set it up.

sherakama’s picture

sherakama commented

Here is a little function to help with the output of those link fields...


function MYMODULEORTHEME_preprocess_field(&$vars, $hook) {
  global $language;
  $lang = $language->language;

  // If link field...
  if($vars['element']['#field_type'] == "link_field") {
    $field_name = $vars['element']['#field_name'];
    foreach($vars['element']['#object']->{$field_name}[$lang] as $k => $v) {
      if($v['url'] == "&lt;front&gt;") {
        if($v['attributes']['target'] == "user") { unset($v["attributes"]['target']); }
        $vars['items'][$k]["#markup"] = l($v['title'], "<front>", array('attributes' => $v['attributes'], 'html' => TRUE, 'language' => $language));
      }
    }
  }

}