| Project: | Attachment |
| Version: | 4.6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
Situation: Drupal 4.6.1 installed on a Windows 2000 Advanced Server box, MySQL 3.23.47-max and PHP 4.3.11.
First of all, I'm new to Drupal.
I had some trouble with the db_rewrite_sql() function used in many places in some modules. Drupal always complained that this function didn't exist. I simply removed the call from the module source file (couldn't find help for a better way).
My problem with the attachment module is that I've uploaded a (zip) file with a story node.
The attachment filelist display works perfectly well and the url seems correct.
This is the attachment url that is displayed with my short article:
http://www.devinfo.net/index.php?q=http://download.devinfo.net/active/0/...
If I directly type this url in my browser: http://download.devinfo.net/active/0/bisql.zip, then it works perfectly. Alas, the full url above does not (tried with IE and Firefox).
Actually, the downloadable zip file is not on the same domain as the drupal site, but this is not the problem, it was previously setup on the same domain but didn't also work.
Also, I'm absolutely sure that this is not an access right misconfiguration.
Is there something I forgot to setup or install, or is this a Drupal issue ?
Comments
#1
I have just installed the module and can verify this bug is happening to me too.
I'm running on a Linux Fedora server - not that it makes any difference to the code ;-)
#2
The problem is because filemanager module is returning absolute paths to files, and then attachment module is trying to disply the absolute link too.
The call is on line 339 of attachment.module:
module_invoke('filemanager', 'url', $attachment['fid'])I've amended the attachment.module to use a different function of the filemanager API. A suitable patch is attached.
dis: if you want a working attachment.module and can't be arsed with patches, email me direct (via drupal contact form) and i'll send the fixed module over to you.
#3
Hi Budda,
Thanks for the patch, I was looking at this also.
If I may adda a little modification in you patch :
<?php$row[0]['data'] = module_invoke('filemanager', 'l', $text, $attachment['fid'], FALSE, $attrib, TRUE);
?>
You invoke
filemanager_lwith$workingparameter to FALSE. IMHO, this should be TRUE. The problem is when you preview a node and you just add an attachement, the file is still in working directory, but with a FALSE argument,filemanager_lwill display you the link to active directory, which would return you a "page not found" error if you try to click it.#4
@ Dis :
I think you have a conflict version between Drupal and your modules.
I think you're stuck with a 4.5.x Drupal core version (which doesn't have the
db_rewrite_sql()fucntion) and you put some 4.6 modules which use it.Consider upgrading Drupal core to 4.6.1 ;)
#5
(Sorry for my late answer but the followup notifications just automatically reached my spam folder. This happened at the ISP level; not under my control...)
Thank you very much budda , it works for me too now !
tostinni, thank you too, I applied your changes too.
Also I'll check for an eventual version mismatch between my Drupal core and my installed modules (I was sure to have triple checked them at install time, but now doubt invades my mind).
Kind regards.
#6
The previous patch (attachmenturl.patch) didnt work for me,
perhaps because I use 4.6.2 or a filename problem.
Here's a new patch (against 4.6.2) based on the previous one
that include the little modification proposed by tostinni
and that seems to work well.
I set a critical priority, because that module is not usable
if urls are wrong.
#7
Applied the original patch. Calling the filemanager with FALSE was correct. When displaying a link to the browser it should always be the active link. Otherwise people will acidently embed a working URL that goes away upon proper submission of the node. The preview code inside the attachment module automatically switches URLs behind the scene to make previews use the right versions.
#8
#9
As I can see in the CVS [1], you made a small mistake while applying the first patch.
You didnt replace the bad line
$row[0]['data'] = l($text, module_invoke('filemanager', 'url', $attachment['fid']), $attrib);
but simply added the correct line below the bad one, resulting in having the following in attachment.module:
$row[0]['data'] = l($text, module_invoke('filemanager', 'url', $attachment['fid']), $attrib);
$row[0]['data'] = module_invoke('filemanager', 'l', $text, $attachment['fid'], FALSE, $attrib, TRUE);
I guess this was a mistake. Could you fix this in the 4.6 module, please ?
[1] CVS : attachment.module 1.7.2.1 (Drupal 4.6, 2005-10-28)
http://cvs.drupal.org/viewcvs/drupal/contributions/modules/attachment/at...
#10
the fix only partially works for me.
It writes the file link as http://website.com/active/0/bisql.zip, but on my server it needs to be :
http://website.com/files/active/0/bisql.zip
The 'files' part is being removed. If I use the original code, I get the same issue as the original poster did.
Also, it seems that the 'description' field isnt being printed. Why is it there? Can you search on it?
Thanks,
V
#11
The patch that fixed this bug seems to add a correct line under the wrong one, instead of replacing it, as I noted in comment #9.
And both lines are present in current CVS head. I assume this is a bug, not a feature, right ?
The module looks like it works (with the 2 lines), but I dont know it there are (bad?) side effects.
No reaction for 3 months, so I reopen the bug to get this fixed or at least know for sure that *not* removing the bogus line was intentional (both in 4.6 and HEAD cvs versions).
#12
The second occurance of $row[0]['data'] overwrites the first $row[0]['data'] line. So nothing bad will happen. It isn't needed though, so delete the first (original) line.