Closed (fixed)
Project:
Pdfview
Version:
5.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
11 Jan 2007 at 02:13 UTC
Updated:
19 Feb 2007 at 15:31 UTC
Jump to comment: Most recent file
Comments
Comment #1
robin t commentedThis looks like the report in http://drupal.org/node/76415 but for 5.0.
I have the same problem. Some added debug printout shows that it is _not_ the rewrite_image_url that's the problem. My custom debug URL rewrite just adds full path.
The complaint, however, is still the same:
This filepath is the original (before the rewrite). In "theme_pdfview_node" I have added a print:
The img tag has changed OK, but TCPDF complains about the original src..?
This happens both for pages and for book pages.
Any hints?
Comment #2
Egon Bianchet commentedTry to change
$pdf = theme('pdfview_html', $pdf, $node->body);to
$pdf = theme('pdfview_html', $pdf, $body);Comment #3
robin t commentedObvoiusly! I must have been tired and impatient last night. Of cause it works - doh!
This change should be comitted (if not already).
I will join the rewrite stuff test later (since I just hardcoded the path for now).
Comment #4
Egon Bianchet commentedThanks, I've committed the change
Comment #5
robin t commentedClose but no cigar.
In the "_pdfview_rewrite_image_url" function the call to base_path() returns '/', so the str_replace removes all '/'es!
The base_path returns the path relative to the document_root (which is / at my installation). That line is no good.
What's needed is a function to return the full path of the installation and prepend that just before the return.
Something like the below works for me but I lack the necessary insight into drupal to make it general.
Perhaps something like $base_url in the settings.php can be invented.
Comment #6
Egon Bianchet commentedThe $base_file_path role is played by K_PATH_IMAGES, inside the tcpdf configuration file.
Regarding the '/', I proposed this change to be tested http://drupal.org/node/76415#comment-164204 , but it looks like it's not working for everybody
Comment #7
robin t commentedYour proposal in the other issue looks sane and will only eat the first / in my case.
(I saw this earlier but forgot about it again. Sorry for the dupe)
However, I cannot get K_PATH_IMAGES to make any difference no matter what I set it to. That's why I ventured into the above.
I always get the same path in the error message.
Anything else I could try?
BTW, issue 76415 is tagged to be about 4.x. This was opened on 5.x. Do you want to keep this separate or should I take this to the other issue?
Comment #8
rubensans commentedAlso happens to me I have test to change the image path some times and happens the same.
Best Regards.
Comment #9
Egon Bianchet commentedI released the 5.x-1.0 version, it should fix the issues with base_path()
Comment #10
mjohnq3 commentedThanks. The latest version works fine so far.
Comment #11
mwpeters commentedI am getting same messages and failures on nodes containing images.
Text only pages are not great, but no errors.
I have installed the module under /sites/all/modules/pdfview...
My pictures are coming from within the /files... branch.
Any idea what I should I be using for the settings in the "tcpdf_conf.php"?
The file example file contains an example using a DOS/WIN style windows drive, but I'm operating off a shared Linux host. I started at root and provided the path back. This may have nothing to do with my image issues, but I'm not at all confident of these settings or what effect they are having.
Comment #12
Tobias Maier commentedhere comes my try to fix this
I hope it works
beside this it replaces tabs with whitespace (per coding standards)
Comment #13
Egon Bianchet commentedThanks for the effort Tobias, but I fail to understand what's the difference between your patch and the current approach ...
Comment #14
Tobias Maier commentedfirst of all
// for clarification: $GLOBALS['base_url'] = '/'
line 1 replaces '//' with ''
this means if
http://www.example.com/image.pnggets handed over"//" gets replaced (result:
http:www.example.com/image.png)line 2 looks if base_path = '/' and then it looks if the first sign is '/' but if the string is something like already a relative path or an absolute url it gets handed over to
$path = str_replace(base_path(), '', $path);which replaces in this case every '/' with '' (result:http:www.example.comimage.png)I don't think that the first line is necessary.
The other change solves the problem described above
Comment #15
Tobias Maier commentedhere comes the patch again,
this time I removed every unnecessary change
btw. the
is nearly the same line as
the existing one inside the if clause
base_path() http://api.drupal.org/api/5/function/base_path
Comment #16
mwpeters commentedThanks Tobias,
Your patch fix and explanation worked for me.
Something like this deserves to get rolled into a release.
Mark
Comment #17
Egon Bianchet commented$GLOBALS['base_url'] is something like
http://www.example.comorhttp://www.example.com/drupal... I strip it from the path because image nodes use absolute urls instead of realtive, to keep working in rss feeds. Sohttp://www.example.com/image.pngshould becomeimage.pngIs there a real world case where $GLOBALS['base_url'] could become == '/' ?
The problem with slashed occurred because i was stripping the base path ($GLOBALS['base_path']) without checking if it was == '/'. But the current version does that check, so how is
different from
?
Comment #18
Tobias Maier commentedsorry, I misread
$GLOBALS['base_url']I read
$GLOBALS['base_path']so please forget #15I fixed the patch
But at the same time you check if the first sign is '/' and if this is NOT the case you fall back to the function which is known not to work with
$GLOBALS['base_path']='/'so you have to check if base_path() = / and if this is true check again, if it is necessary to strip the first slash.
but if you do both checks at once you fall back to the else clause and the old function runs again
I hope you understood what I mean.
Comment #19
Egon Bianchet commentedOK, committed to HEAD, DRUPAL-5 and DRUPAL-4-7
Thanks!
Comment #20
(not verified) commented