When showing an uploaded file as a link, the path is stored in the global object property $this->options['alter']['path']. This causes all the files appearing in the view to have the same link (the last written one). This patch replaces use of the global variable by returning the data directly as a HTML link.

Maybe this is not the right way and should instead be done in a "render method" ?

CommentFileSizeAuthor
#19 views_handler_field_upload_fid.inc_.txt1.96 KBnevets
#5 views-378724-upload-link.patch1.47 KByrocq
views_upload_link.patch586 bytesyrocq

Comments

yrocq’s picture

yrocq commented
Status: Active » Needs review
merlinofchaos’s picture

merlinofchaos commented
Status: Needs review » Needs work

That's not a global. All fields should be able to use that alter, otherwise checking the 'rewrite output' won't work either, so this is not the proper solution.

yrocq’s picture

yrocq commented

I tested the patch with a lot of different options (Rewrite output, Output this field as a link, Trim,...) and I didn't encounter any issue. By "global", I meant that the $this->options['alter'] table is associated to the handler, not to the data. IMHO, changing this information while rendering the data is a bad thing. For example, the following lines in the current code of the views_handler_field_upload_fid class :

  function render_link($data, $values) {
    if (!empty($this->options['link_to_file']) && $data !== NULL && $data !== '') {
      $this->options['alter']['make_link'] = TRUE;
      $this->options['alter']['path'] = file_create_url($values->filepath);
    }
    return $data;
  }
}

will behave exactly the same way as if the user had checked the box "Output this field as a link" in the field options, and had entered an arbitrary file url (the url of the uploaded file of the last row of the view result) as a link. I don't understand this logic. This code is not necessary for the "Rewrite the output of this field" and the "Output this field as a link" options to work + it breaks the "Link this field to download the file" option.

merlinofchaos’s picture

merlinofchaos commented

It *is* necessary for the 'rewrite this field' while using it as a link to the file.

yrocq’s picture

yrocq commented
StatusFileSize
new views-378724-upload-link.patch1.47 KB

OK. I didn't understand that the problem with the patch occurs when both the "Rewrite the output of this field" and "Output this field as a link" options are selected. I wrote a new patch which returns the field as a link only if "Output this field as a link" and "Trim this field to a maximum length" haven't been set (trimming the link can cause problems even if "Field can contain HTML" is checked).

Another solution would be to create a new token containing the full path of the file ([upload_fid] only contains the file name). With this method, we could keep the current version by inserting the token in the alter table like this :

function render_link($data, $values) {
  if (!empty($this->options['link_to_file']) && $data !== NULL && $data !== '') {
    $this->options['alter']['make_link'] = TRUE;
    $this->options['alter']['path'] = '[upload_full_path]';
  }
  return $data;
}

I also realize that if we created this new token, we would have the possibility to just remove the option "Link this field to download the file", because this feature would be implementable with the option "Output this field as a link".

What do you think about that ?

yrocq’s picture

yrocq commented
Status: Needs work » Needs review
Jim Ruby’s picture

Jim Ruby commented

subscribe, please can you let me know when this is decided and I could try and apply the patch, my first time doing this so i'll learn as I go.
Thank you

lilou’s picture

lilou commented

subscribe to

arnd’s picture

arnd commented

subscribing

mariagwyn’s picture

mariagwyn commented

I recently ran into this error, I think after my last upgrade of Views. On my install, it is NEW. I have a view set-up which lists nodes and their attached file, linking directly to the file for download (only ONE file for each node), and this has been working just fine.

I just added a display to this view, listing a set of nodes that have more that one file attached. I set it up the same as previous displays, simply linking to the downloaded file. In this display, the lists of files for ALL nodes and ALL the attached files link to ONE file. The files appear listed correctly, each with their own title, but are linked to a single file. The file happens to be the first one I uploaded today, but not the first one listed in the view.

I am not sure if this helps, but once this is settled I can upload the patch (or even test now if that would be helpful). It just seems strange behavior since this features was working fine previously, and is still working on displays not created with the most current Views update.

Branjawn’s picture

Branjawn commented

Just want to add that I am having a same or similar problem.

I made a content type of PDF to give a title, teaser, and then upload a pdf.

I then made a view to display the title and link to attached file on a page.

Visually, it displays exactly like I want it. But all attached file links are the same.

Subscribing :o)

my page: http://www.carolinaunmanned.com/?q=pdfdoclist

merlinofchaos’s picture

merlinofchaos commented

Just to check, have you tried this with the current -dev? This is particularly important if you're using the table style.

Branjawn’s picture

Branjawn commented

I just downloaded VIEWS today, so it is the latest available.

FrankT’s picture

FrankT commented

Could anybody tell me if the patch provided in #5 is ready to be used?

Branjawn’s picture

Branjawn commented

I hope this issue hasn't been forgotten. It's a pretty big deal! All my links are the same, not good!

texasgopher’s picture

texasgopher commented

I am also having the same problem. I thought it was just me. I hope this can get fixed soon.

FrankT’s picture

FrankT commented

...as I do not have too many views and there was no database change I switched back to 2.2 now, no problems so far...

Branjawn’s picture

Branjawn commented

Agreed, switching back to views-6.x-2.2 fixes problem.

nevets’s picture

nevets commented
StatusFileSize
new views_handler_field_upload_fid.inc_.txt1.96 KB

I found the source of the problem and have a "band aid" people can use.

The problem is the class views_handler_field_upload_fid is using pre_render to set up the attachments and optionally link them. It does this for all data rows at once over writing the previous link information. It's code is loosely based on how the node links a title to it's node. There is a major difference in that for nodes there is a one to one mapping of node to title, on the other hand nodes can have many attachments so views built in code for handling links will not work.

My band aid version of the removes pre_render() from the class, adds render() to the class and restructures render_link() to return an actual link (if needed). To use this solution place the file under views/modules/upload.

I call this a band aid because I am unsure if this an appropriate solution.

Jim Ruby’s picture

Jim Ruby commented

If I want to go back to views version 2.2, how hard is it and what can I do so I do not mess up my current views?

If this might be fixed soon then I can wait.

Thanks

crbassett’s picture

crbassett commented

@nevets Thank you for that file. It fixed it for me as well. I appreciate your help. You coders do what I can never do, and for that I am very grateful.

FrontBurner’s picture

FrontBurner commented

subscribing having same problem.

ato10’s picture

ato10 commented

@nevets If I check 'Rewrite the output of this field' the link disappear

nevets’s picture

nevets commented

From my understanding that makes sense (I think 'Rewrite the output of this field' takes over rendering of the field).

mariagwyn’s picture

mariagwyn commented

@nevets: I uploaded the file into views>handlers>views_handler_field_upload_fid.inc, to no avail. Should I put this somewhere else? It was the only folder that looked right, but there was no such file in the folder. I also tried "rewrite output...." No luck.

This is pretty important to me since it killed about half of my views. Any help appreciated.

Thanks,
Maria

nevets’s picture

nevets commented

Did you put it in views/modules/upload? Are you running the latest (non-dev) version of views? The file was tested against 6.2.3.

petrescs’s picture

petrescs commented

subscribing, having same problem

zila’s picture

zila commented

subscribe
@nevets patch basically working, without using the Output rewrite option (thx. nevets :)

wrburgess’s picture

wrburgess commented

subscribing, same problem for all views

mariagwyn’s picture

mariagwyn commented

@nevets: OF COURSE I had it in the wrong place! Uploaded correctly, works. Many many thanks!!!

Can this get committed to next version of views? Kinda important feature...
m

oseldman’s picture

oseldman commented

subscribing, having same problem

Ouphfta’s picture

Ouphfta commented

same issue here, only fixed for me by going back to v2.2

mbiddlecombe’s picture

mbiddlecombe commented

subscribing

shaisachs’s picture

shaisachs commented

nevets - No idea if this is the right approach, but it works for me, in the one view I've tested it with. Thanks!

k3vin’s picture

k3vin commented

subscribing

eric_a’s picture

eric_a commented

I looked at the differences in views/modules/upload between between 6.x-2.2 and 6.x-2.3 and decided to try to revert just this folder rather than completely reverting to views 6.x-2.2 as discussed in #10, #17, #18, #20, #32. Works for me...

gregarios’s picture

gregarios commented

subscribing

This doesn't seem to be limited to just uploaded files links. But, when you link to something other than a file, like a node, it totally breaks them.
This appears to be the same problem as the one I am having with views links in this issue: http://drupal.org/node/420230

Branjawn's links on his example page look exactly like my Blog Author list page. Eagerly awaiting a fix.

kierduros’s picture

kierduros commented

Just another person eagerly awaiting the resolution of this issue.

merlinofchaos’s picture

merlinofchaos commented
Status: Needs review » Fixed

Fixed in -dev.

Status: Fixed » Closed (fixed)

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