DESCRIPTION:
· I have a local drupal instalation for testing purposes on http://localhost:8080/DRUPAL/
· when I enable user picture support and add a pisture to user the standard theme function generate malformed relative URL, e.g.:
<img src="8080/DRUPAL/files/pictures/picture-1.gif" alt="admin's picture" title="admin's picture" />
(where you see the port 8080 as a part of the relative URL)
SOLUTION: (?)
· the file_create_url create absolute URL (on line 4 of the function theme_user_picture)
· but the theme_image function expect relative URL (in return there is joined base_path() with $path which does not make sense for absolute URL in $path variable
· if I put somethink like this:
$picture = str_replace( $GLOBALS['base_url'] . '/', '', $picture);
before if (isset($picture)) {
in the function theme_user_picture everything seems to work well
(I mean redefine it in the theme, I did not directly change the code of drupal).
Comments
Comment #1
magico commentedI do not know if this has something to do with another issue that was filled about a problem with the parsing of the port within the URL...
Comment #2
heine commentedThis should have been fixed in 4.7.4.
Comment #3
magico commented@alladjex: could you please confirm with the 4.7.4? Thanks
Comment #4
EvanDonovan commentedI have experienced this same issue (or a very similar one) on Drupal 5.7. The user pictures are being output with a full path, instead of a relative one. This causes a conflict with the CDN module, which expects relative paths. If I add the code suggested by the original poster,
$picture = str_replace( $GLOBALS['base_url'] . '/', '', $picture);, the problem is resolved.I don't know why the file_create_url function, which generates an absolute path, is actually necessary in this case. Since I am using a private download method, I should be able simply to use
$picture = $account->picture.After I made the change from the file_create_url to $account->picture, the user pictures showed up fine again with CDN integration active.
Comment #5
dave reidThe original issue has been fixed in 5.x. In response to #4, it's easy to convert the picture URL to a relative one. Marking as won't fix.