Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.What I found is that theme_user_picture() was passing an absolute url (e.g. "http://example.com:8080/files/pictures/pic.jpg") as $path to theme_image(), which then returned something like "<img src="8080/files/pictures/pic.jpg" alt="somebody's picture" title="somebody's picture" />". Of course, the image could not be found with such src value.
The problem was that theme_image() was prepending $path with base_path() (e.g. "/"), thus passing "/http://example.com:8080/files/pictures/pic.jpg" to check_url(), which then truncated the url to "8080/files/pictures/pic.jpg" because "/http:" is not a valid protocol.
This patchs prevents theme_image() from modifying $path when it is an absolute url.
I'm not sure this is the right thing to do, though. Maybe theme_user_picture() should never send an absolute url to theme_image() ?
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | user.theme_user_picture.patch | 758 bytes | harry slaughter |
| theme_image.patch | 762 bytes | David Lesieur |
Comments
Comment #1
killes@www.drop.org commentedis this still valid?
Comment #2
cmb commentedThis code solved my user picture problem after upgrading to 4.7.0. base_url() was concatinating to $path and creating URLs that begin with "//.." instead of just using $path when it was the right choice. The patch may not work for anyone but it worked on my test site.
Ben
Comment #3
David Lesieur commentedI re-tested and 4.7.0 still has the bug. The patch still applies and it still fixes the problem.
Comment #4
drummI would rather go with fixing theme_user_picture() than covering up the symtom.
Comment #5
drummComment #6
neclimdulWell, I'm not sure this fix isn't the proper fix. However, if it isn't, then theme_image should cleary define $path as requiring a relative path. This could cause a completely seperate issue if someone where to implement a seperate image server for some images on their drupal.
Furthermore, since we need the logic of file_create_path() for where the user's image is stored. I'm hesitant to change the behavior of this to return relative urls as it could cause inumerable bugs throught other modules. However not changing means that we have to start stripping information out of file_create_path which, to me, is defeating the purpose of having a function to abstract the logic.
Finally, some basic input validation shouldn't hurt theme_image. In fact it should make it more useful. If you look at image.module you'll notice that it seems to have created its own theme_image_display() function to work around this behavior.
Comment #7
kcouch commentedThis patch didn't work in my case. The issue seems to be with the check_url() function and having a port number (other than 80). When I remove the check_url() function from theme_image() then everything is fine.
Comment #8
kcouch commentedJust commenting out the check_url() function may cause issues depending on other modules you have installed. I think a better fix is now posted here: http://drupal.org/node/72095
Comment #9
harry slaughterproblem seems to be theme_user_picture() is creating a full URL where it should be a relative URI.
this causes theme_image() to break since it's expecting the relative URI.
I think theme_image should probably check its $path arg to ensure it's not a full URL, but ultimately I suppose you're supposed to call it correctly in the first place :)
this patch applies to 4.7.3
Comment #10
harry slaughterawaiting review
Comment #11
Rok Žlender commentedThis is related to the problem I describe here http://drupal.org/node/73087 . This problem is still present in head version of drupal.
Comment #12
drummI think we need to keep file_create_url() to account for private files possibly being enabled at admin/settings/file-system.
Comment #13
killes@www.drop.org commentedfixed by a commit from Steven
Comment #14
(not verified) commented