I try to add item image, the caption and credits are contained - but the image is not saved (no error msg as I can see). When clicking "image" in the Item, I see the caption/credit, but no Image, just the upload field + browse button once more as if no image had been uploaded. All settings worked very well running locally using xampp.

After uploading first image (after installation), the media/k2/items/cache folder is populated with 6 files (the different sizes). The names are _Generic.jpg, _L.jpg, _M.jpg etc. All these are without the prefix - leading me to believe there are some function that generates prefix that does not work?
The media/k2/items/src folder has not been generated - I do this manually (+ chmod 775) and try adding another picture (through the Item -> add Image) - but all this does is to replace the pictures under media/k2/items/cache (and nothing is put in /items/src). So again - this leads me to believe that the generate prefix function (before _Generic.jpg etc) is broken somehow....

I have also tried very small pictures (in regards to another similar error her)... to no help..

Can anybody help me with this?

My settings:
Joomla 1.5.13
k2 v2.0.0
Simple Image Gallery PRO v2.0.4
WebServer: Apache/1.3.41 (Unix) PHP/5.2.9 mod_throttle/3.1.2 FrontPage/5.0.2.2635 mod_psoft_traffic/0.2 mod_ssl/2.8.31 OpenSSL/0.9.7a mod_macro/1.1.2
GD Support: enabled (version: bundled (2.0.34 compatible) ) FreeType version: 2.3.7

Hi. This is weird. The prefix is generated by the id of the item so this should not be empty! Are you still getting this error?

Hi Lefteris - thanks for your reply.
Yes, I am still experiencing this - it is very strange (and quite frustrating :). The _Generic image keeps being written over, but no prefix is added.
I see from my local installation (xampp) that the prefix is a rather long and cryptic string so I guess there is a function that generates that string on the basis of the item id (I found no connection between image and item in the database). Could it be that that function uses some kind of generator that has "special" needs for certain settings on my server (random generator, file-permission for temp storage etc)?

No there is no special requirements for this to work. Please check that the folders are writable and try to create a new item with an image. Please let me know if you get the same error.

Hi,
made sure that media-folder (and alle sub-directories/folders) has permission 775.
I also did the same for the images-folder under root. (I use FileZilla to set permissions)

The result is the same - the _Generic file is overwritten with the new image, but no prefix is added and it does not show up in the image.

Thank you very much for helping me - do you have any other suggestions as to what I should try?

Hi again. Did you tried to create a new item? Please check that you can create a new item. The prefix is generated by the item's ID. What version of MySQL are you using?

Hi Lefteris,
yes I am able to create new items - and the id for the item is created (looks correct).

Database Version: 5.0.77-log
Database Collation: utf8_general_ci
PHP Version: 5.2.9
Web Server to PHP interface: cgi-fcgi
Joomla! Version: Joomla! 1.5.13 Stable [ Wojmamni Ama Baji ] 23-July-2009 04:00 GMT

Hi again. This is very weird. The routine that generates the prefix uses php's md5() function. It seems that for some reason php's md5() fails. Is it possible that this function is disabled by the server configuration? I suggest that you do some further research on this as i cannot reproduce this bug and no one else has reported something similar in the past.

I too have this problem, all folder permissions are ok, but images don't upload - the server is configured ok to use md5 - any updates on this issue?

Lefteris Kavadas said:Hi again. This is very weird. The routine that generates the prefix uses php's md5() function. It seems that for some reason php's md5() fails. Is it possible that this function is disabled by the server configuration? I suggest that you do some further research on this as i cannot reproduce this bug and no one else has reported something similar in the past.

Are you having exactly the same issue? Or your images aren't uploading at all? Did you get any files in the directory media/k2/items/cache?

Dave Arnesen said:I too have this problem, all folder permissions are ok, but images don't upload - the server is configured ok to use md5 - any updates on this issue?
Lefteris Kavadas said:Hi again. This is very weird. The routine that generates the prefix uses php's md5() function. It seems that for some reason php's md5() fails. Is it possible that this function is disabled by the server configuration? I suggest that you do some further research on this as i cannot reproduce this bug and no one else has reported something similar in the past.

Just for information:
I Checked md5 on my server by creating a simple php page and trying echo md5("hello"), and that worked. So it seems like md5 is configured properly on my server.

Hi Lefteris,
The caption and credit are saved with the content item, but no image is displayed.

I've looked in the folder and there are no files in the cache directory, although it is writeable and I have even tried with 777 permission.

Thanks!
Dave

Lefteris Kavadas said:Are you having exactly the same issue? Or your images aren't uploading at all? Did you get any files in the directory media/k2/items/cache? Dave Arnesen said:I too have this problem, all folder permissions are ok, but images don't upload - the server is configured ok to use md5 - any updates on this issue? Lefteris Kavadas said:Hi again. This is very weird. The routine that generates the prefix uses php's md5() function. It seems that for some reason php's md5() fails. Is it possible that this function is disabled by the server configuration? I suggest that you do some further research on this as i cannot reproduce this bug and no one else has reported something similar in the past.

Hi Lefteris and Dave (or anybody else with a suggestion :),
do you have any suggestions as to how I could debug this problem? I can not find any errors in the logs (maybe I have not been able to turn them on properly), and no other error-indication shows up when uploading image.

Btw, when using RokStories with a "regular" inline image (which I can see in the article), the image is not displayed as the big feature picture. The RokStories "arrows" on each side of the big picture is there, but no picture - just the loading-placeholder is shown instead of the image on the site.

I have also tried reinstalling several times :)

Could encoding be a cause? UTF-8 ?

I'm kind of stuck here ... any help would be appreciated :) Thanks

Yeah still no progress for me, I also can't see any errors in the server logs but nothing is being uploaded to the k2 image directory.

Regarding RokStories; have you got the latest version of this from RocketTheme? I know they have recently released upgrades of some modules to make them k2 compatible, not sure if they have done for RokStories.

Dave

Rolf Erik Paulsen said:Hi Lefteris and Dave (or anybody else with a suggestion :), do you have any suggestions as to how I could debug this problem? I can not find any errors in the logs (maybe I have not been able to turn them on properly), and no other error-indication shows up when uploading image.

Btw, when using RokStories with a "regular" inline image (which I can see in the article), the image is not displayed as the big feature picture. The RokStories "arrows" on each side of the big picture is there, but no picture - just the loading-placeholder is shown instead of the image on the site.

I have also tried reinstalling several times :)

Could encoding be a cause? UTF-8 ?

I'm kind of stuck here ... any help would be appreciated :) Thanks

I tried installing the previous version v1.0.2 Beta..... and the image upload worked !

All of a sudden, I found that I had two k2 directories under media... one "k2" and one "K2". In UNIX/Linux world... these are two completely different names... whereas on my XAMPP installation (Windows) where everything works - they are not :)

I then tried reinstalling the v2.0.0, and saw that it operated with "k2". I manually tried to rename the folder to "K2", but all that happened during image upload was that a new "k2" folder was generated with a subfolder for "items/cache" containing the _Generic.png files.

But this leads me to a question.... has anybody managed to get v2.0.0 to run in a Unix/Linux environment where file- and directory names are case sensitive?

Can there be an inconsistency in the code when performing operations (md5 ?), where the folder name "k2" is used to store files - but then the md5 command is run on a file in the "K2" folder (or some other combination to that effect?)

It seems like it might be a problem with the case sensitivity running k2 under UNIX/Linux. The image upload worked fine in previous version of k2. The issue might be the name of the k2 directory; if k2 and K2 are both used in the code ?

Has anybody managed to get item image upload to work under Unix/LInux?

After a lot of debugging, I have managed to locate where the code fails... and a way around it..

class.upload.php in /administrator/components/com_k2/lib returns 'incorrect_file'.
This only happens for the first original file that is to be saved under the /src folder, this also causes the file-name to not be generated (returned) correctly. The /cache images are saved correctly, but without file-name which is not returned from the original file.

For the first file, this is the metadata inside class.upload.php process() method:
this->file_src_mime: audio/x-mod

In the following process-method loop check for mime values:This produces the following log:
checking 0 => image/*

For the other generated files _Generic.jpg, _L.jpg etc... about twenty mime-values are looped through, but only one for the first...

By bypassing the mime-check I get the upload to work correctly... but not the best solution...
Again, I reiterate that the original code works fine on my xampp server on my windows machine.

Does that help you guys that work with this code? Do you have any idea as to why the mime-check fails (I try uploading both .png and .jpg files).

I have the same problem. I found that in the src folder the image was upload there but in the cache folder there are no other prefix image added.

I've checked the folder's permission which is writable(running on a mac with Cmd+I function).

Please help...

Thank you!

Hi. The class that K2 uses for uploading is class.upload.php by Colin Verot. As it appears mime detection fails in some systems. Maybe the new version (0.28) of class.upload.php resolves this issue. We have to make some further research on this.

Hi. Can you please attach one image file that fails?

Rolf Erik Paulsen said:After a lot of debugging, I have managed to locate where the code fails... and a way around it..
class.upload.php in /administrator/components/com_k2/lib returns 'incorrect_file'.
This only happens for the first original file that is to be saved under the /src folder, this also causes the file-name to not be generated (returned) correctly. The /cache images are saved correctly, but without file-name which is not returned from the original file.

For the first file, this is the metadata inside class.upload.php process() method:
this->file_src_mime: audio/x-mod

In the following process-method loop check for mime values:This produces the following log:
checking 0 => image/*

For the other generated files _Generic.jpg, _L.jpg etc... about twenty mime-values are looped through, but only one for the first...

By bypassing the mime-check I get the upload to work correctly... but not the best solution...
Again, I reiterate that the original code works fine on my xampp server on my windows machine.

Does that help you guys that work with this code? Do you have any idea as to why the mime-check fails (I try uploading both .png and .jpg files).