Drupal 6.x and CCK FileField Path Issue

I'm using Drupal 6.x with the CCK FileField module. I'm not using Clean URLs, PathAuto, or the out-of-the-can Path module. I'm having problems understanding why a CCK FileField "filepath" array value keeps having the word "node" prepended to a URL when a var_dump doesn't...

Here's some code to better illustrate my issue:

Code:

---

...
if($node->foobar_files[0][view]){
  foreach($node->foobar_files as $k){
      var_dump($k['filepath']);<-------------------------------------------------------------------- Doesn't have the word "node".
      print '<li><a href="'.$k['filepath'].'" title="'.$k['filename'].'">'.$k['filename'].'</a></li>';<----------- DOES have the word "node".
  }
}
...

---

How can the same variable be displaying / generating different values like this? Would this be an HTACCESS issue? apache.conf? Preprocessing from template or something?

Help is appreciated. This is driving me nuts... I'll post back if I find a fix... Chances are, it's just something stupid that I'm overlooking or whatever...

Okay, I'm closer to understanding what's going on here: the links I've output only include the word "node" when I use CLEAN URLS. SO, this begs the question: how can I theme CCK FileField URLs regardless of using Clean Urls? Seems like the approach I used *should* work, but clearly, it's not.

Yeah, the bootloader or some other part of core is prepending the url before it gets to the screen.

What is it that you want to do?

Hi Andrew.

Long story short, I just want my freaking links to work without having to worry about whether clean urls is turned on or off.

Here's what I resorted to using:

Code:

---

if($node->field_foobarfiles[0][view]){
  print $node->field_foobarfiles[0][view];
}

---

Rough, right? I mean, it works whether clean urls is turned on or off, but it's not really helping me loop through the object / array. Maybe I don't have to worry about it since this type of node only attaches 1 file, but in the future, this might be something to think about... I dunno.

PHP Code:

---

foreach($node->field_foobarfiles as $field) {
  printf('<li>%s</li>',$field['view']);
} 


---

Wouldn't that work for printing a list of files?

In cck the 'view' is created using a theming function associated with a field formatter. The answer to actual question probably lyes within the formatters or tracing code starting there.

The formatting theme functions are located within the file /filefield_formatter.inc. Considering the formatters are theming functions there could possibly be some preprocessing vodoo going on some where also.

oddz, that code seems to be working perfectly now... Doing exactly what I wanted. (Tested it by adding your code, saved it on the server, then went to the respective node and turned off Clean Urls... Then went to edit the node, saved it, then went back to the page where the URL was. Clicked on it, and bam, it worked. Then I went back to Clean Urls, turned it on again, went back to the node to edit and save it, then went back to the link and again, it still worked!)

Strange experience...

Well here is the thing – this:

PHP Code:

---

if($node->foobar_files[0][view]){
   foreach($node->foobar_files as $k){
      var_dump($k['filepath']);<-------------------------------------------------------------------- Doesn't have the word "node".
      print '<li><a href="'.$k['filepath'].'" title="'.$k['filename'].'">'.$k['filename'].'</a></li>';<----------- DOES have the word "node".
   }
} 


---

Is using raw data values. However, 'view' is probably using modified alterations. Not to mention a hook can exist to intercept and change the values before the theming formatter is called. So some where within that entire process something is getting changed. It might be within the file field module itself or outside it because of the preprocessing hooks made available for every theming function.

The 'view' for a field value will *always contain the rendered output based on the selected formatter for the data which the field contains. When a default formatter does not provide the intended result that is when you should create your formatter. However, in this case it looks like that isn't necessary.

That makes sense to me. I was thinking that there had to be an outside hand in all this because I didn't have any HTACCESS or template.php code that could be doing it and I knew I wasn't doing it within the theme file...

Thanks for the insight into this. I'll keep that formatter lesson in my mind for the future, too. :)