Imce CCK Image 6.x-1.x-dev
IMCE 6.x-2.0-beta3
Drupal 6.17
Firefox 3.0 (Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.0.19) Gecko/2010033116 Red Hat/3.0.19-1.el5_5 Firefox/3.0.19)
For an Imce CCK image field, it appears that if I upload an image containing a space in its filename using IMCE, click on "Send to imceimage" and then attempt to save the node, I get a validation error of the form:
%name is not a valid image or has been deleted (url: %url)
where %name and %url are placeholders for the field name and image URL. In this case, the URL is of the form /blah/blah/blah/file%20with%20spaces.jpg.
(NB: I am then unable to rectify the situation without losing all other edits as the "Select Image" link on the Imce CCK image field then invokes a JavaScript error
Error: imceImage is not defined
Source File: javascript:imceImage.open('/imce',%20'0-field_imceimage')
Line: 1)
The "not a valid image or has been deleted" message appears to be coming from the imceimage_field() function in imceimage.module. A quick look at the code suggest that the _imceimage_image_to_filepath($url) function isn't converting a URL to a file path correctly, since occurrences of URL-encoded spaces (i.e. %20) in the URL should surely be converted back to spaces when converted to a file path?
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | 820522-11-rawurldecode.patch | 545 bytes | benclark |
| #1 | imceimage_urldecode.patch | 382 bytes | kelvinwong |
Comments
Comment #1
kelvinwong commentedTry this
Comment #2
makbeta commentedI've tested this fix, works like a charm. Thanks Kelvin.
Comment #3
Anonymous (not verified) commentedThanks, Kelvin. That patch does the trick.
(Sorry for taking so long to follow up on this one...!)
Comment #4
allartk commentedthanks !
Comment #5
donquixote commentedIs this still an issue in the 6.x-2.x branch?
Comment #6
cafuego commented$_SERVER['DOCUMENT_ROOT'] is not a safe value to use. If someone runs Drupal in apache with mod_vhost_alias, this variable contains nonsense data. Instead, use the return value from
cwd()which is always the Drupal site root.Comment #7
donquixote commentedOk, I agree this _imceimage_image_to_filepath() stinks.
There is another issue where we discuss the same (or closely related) problem.
#697174-20: imceimage.module produces invalid HTML (non-unique id attributes) in Lists and Front Page
but there it is totally off-topic.
So, let's have this as the major issue where we discuss the $url to $filepath conversion stuff.
A lot has happened on git recently, please have a look at the latest posts in the linked issue.
Comment #8
gregarios commentedI'm not sure about the solution to this, but spaces should never be allowed in a filename anyway in proper HTML syntax.
Comment #9
cafuego commentedSpaces are allowed in filenames, it's just that in URLs they should be properly encoded as %20.
What appears to be my problem is that files get stored in the database with an absolute path starting with a / and with special characters being encoded, ie:
/sites/default/files/test one.pngis stored as/sites/default/files/test%20one.pngOn display, that gets encoded *again* the passed to theme('imagecache') so I end up with imagecache trying to display a file called
/sites/sites/default/files/preset/sites/default/files/test%2520one.png, which of course fails quite badly.I can make all problems go away by removing the starting / from entries in the database and un-encoding the special characters.
My more automagic workaround is to fix the filepath in
hook_field($op = 'validate', ...)an to addhook_field($op = 'sanitize', ...). In both, I run the field values though this helper:That seems to do the trick. I should probably mention that this was not an issue in Drupal 6.16, but became a problem overnight when I upgraded the site to Drupal 6.25.
Comment #10
gregarios commentedHmmm... I like cafuego's solution to just strip down whatever kind of URL is found in the database and make it relative...
Comment #11
benclark commentedI recently had to patch this module and found that the _imceimage_fix_filepath() function worked just fine when I replaced it with cafuego's code in #9:
Maybe I'm missing something obvious about what this function is used for, but it seems as though $url is always going to be relative to the Drupal root, and by stripping off the leading slash and decoding the URL, we get a valid file path.
I'm attaching a patch just to help things along. Hope this helps!