Image upload bug - ezimage datatype code mess?

Next topic

Author	Message
Denitsa M.	Tuesday 17 November 2009 8:54:42 am Hi, in most recent testing and debug we found that the latest stable base version for 4.1 with changes into ezimage datatype codes is causing images not to be uploaded/viewed correctly in public or adm site. The removed code in storeObjectAttribute() method in ezimagetype script created a bug here and no images can be uploaded correctly and under the correct path in storage unless we put back this piece of code (without reverting the other changes in script). The latest code caused OE, ezmultiupload and common publish of images not to function properly( returning "Original alias not found, other aliases cannot be created without it" error ), and the images uploaded were placed not under storage/images, but under storage/images-versioned and because of it - not considered published. Is this a real bug, or has something to do with settings, or anything else ..? Another fix besides putting back the old code into storeObjectAttribute() method? Thanks Deni Iguana IT - http://www.iguanait.com
Francisca Hernández	Thursday 19 November 2009 2:46:26 am Hi, The problem came with this change http://lists.ez.no/pipermail/sdk-svn/2009-October/018413.html in 4.1 and 4.2. this only happens when you upload images from OE (last stable version). We can see that upload calls storeObjectAttribute() not fetchObjectAttributeHTTPInput() Does anyone have the same problem? we want to rule out a bug so that we keep looking into the error in any of our modifications or settings We have been looking for this problem for days, any help will be really appreciated. Thanks in advance. Francisca Iguana IT, SL - http://www.iguanait.com
Mads Ovesen	Thursday 29 April 2010 6:52:42 am Hi, Im experiencing this problem in 4.3, and I can see the storeObjectAttribute function for the image datatype is empty. Why is it empty? Is it a bug, and are there any fixes for it? I have tried to copy the contents of this function from v 4.1, and then it vorks correctly, so it seems to me, that it is a bug. mvh Mads /m

Author

Message

Tuesday 17 November 2009 8:54:42 am

Hi,

in most recent testing and debug we found that the latest stable base version for 4.1 with changes into ezimage datatype codes is causing images not to be uploaded/viewed correctly in public or adm site. The removed code in storeObjectAttribute() method in ezimagetype script created a bug here and no images can be uploaded correctly and under the correct path in storage unless we put back this piece of code (without reverting the other changes in script). The latest code caused OE, ezmultiupload and common publish of images not to function properly( returning "Original alias not found, other aliases cannot be created without it" error ), and the images uploaded were placed not under storage/images, but under storage/images-versioned and because of it - not considered published.

Is this a real bug, or has something to do with settings, or anything else ..? Another fix besides putting back the old code into storeObjectAttribute() method?

Thanks

Deni

Iguana IT - http://www.iguanait.com

Francisca Hernández

Thursday 19 November 2009 2:46:26 am

Hi,

The problem came with this change http://lists.ez.no/pipermail/sdk-svn/2009-October/018413.html in 4.1 and 4.2. this only happens when you upload images from OE (last stable version). We can see that upload calls storeObjectAttribute() not fetchObjectAttributeHTTPInput()

Does anyone have the same problem? we want to rule out a bug so that we keep looking into the error in any of our modifications or settings

We have been looking for this problem for days, any help will be really appreciated.

Thanks in advance.

Francisca

Iguana IT, SL - http://www.iguanait.com

Mads Ovesen

Thursday 29 April 2010 6:52:42 am

Hi,

Im experiencing this problem in 4.3, and I can see the storeObjectAttribute function for the image datatype is empty. Why is it empty? Is it a bug, and are there any fixes for it? I have tried to copy the contents of this function from v 4.1, and then it vorks correctly, so it seems to me, that it is a bug.

mvh Mads