Please, help me with images in 3.3!

Next topic

Author	Message
Nicklas Lundgren	Thursday 29 January 2004 1:31:07 pm Yes, I am desperate, Im afraid. This is the second time I try to upgrade to 3.3 froom 3.24. Like before I hit the wall when it comes down to the new image system. I am beginning to give up. This is the story: I develop three different sites on one ez-installation. They all share the same db. The purpose of this is that the three sites later on are going to share some information. Well, I did it all right, I believe. Brought down the 3.32 software, migrated it with my settings and designs. Updated the db. I did it all. So now, all my sites are up and running under 3.32. With one SERIOUS exception. The images. The strange thing is that some of the images in each site are being created under the var/site/images directory. While other images totally refuses to participate, leaving disturbing white spaces in the webpages. And I keep getting error messages like: --------------------- Error: eZImageManager::createImageAlias Jan 29 2004 22:10:52 The reference alias original file var/site/storage/images/[...]/6141-1-swe-SE/evenemang1.jpg does not exist Error: Jan 29 2004 22:10:52 Original alias does not exists, cannot create other aliases without it -------------------- I come to the following conclusions: 1. There is no problem with ImageMagick, since some images are created OK. 2. My settings in image.ini are OK, since some images are rendered OK. 3. All paths to the images seem to exist in the db-table ezimagefile. Event paths to images that do not exist in var/site/images/... 4. I probably should just give up and throw the computer out of the window. Do anyone of you have a clue about this? If you have a lot of knowledge regarding the new image-system, please share it. For instance - when is it decided that an image should be created in var/site/images/... ? And are there any script to run like the "updateniceurls.php" script? I mean, that might be good if it all is a problem with the db? I am out of ideas here. I have even tried to run the latest stable version 3.3.3 (4927). But the result is the same. All ideas on how to get out of this trouble is greatly appreciated. Kind regards, Nicklas Lundgren
Nicklas Lundgren	Friday 30 January 2004 1:24:49 am Hi again, I sorted it out myself. It came down to the length of the data in ezcontentobject_attribute:s column data_text. Apparently some of my paths to images were too long in ez 3.3.2 for this column. With the result that only a few images showed up. I just now found the db update script from 3.3.2 to 3.3.3, where it is a fix for this. After installing it, it all seem to work out fine. So, if you come into the same trouble: 1) Upgrade to 3.3 2) Dont forget to run the db update script from 3.3.2 to 3.3.3. I guess, if I would have stayed in version 3.3.2 I would never have gotten out of this trouble... Regards, Nicklas
Kåre Køhler Høvik	Friday 30 January 2004 1:32:23 am Hi I find this quite strange. The ezcontentobject_attribuet.data_text in 3.3-2 is able to store upto 64kB of data ( in mysql, unlimited in postgresql ). Are your paths actualy longer than this ? btw, some code has been added to the soon to be released 3.3-3, to make the new image system more compatible with the old one. -- Kåre Høvik Kåre Høvik
Nicklas Lundgren	Friday 30 January 2004 2:31:41 am Hi again, Thanks for the reply, Kåre. If the problem is not caused by the length of the column data_text, then I cant understand what finally solved my problems. In the end, I started to debug the kernel/classes/datatypes/ezimage/ezimagealiashandler.php. There I found out that the method aliasList checked if (domTree==false) . If so, the call to generateXMLData took care of creating the images in the right places. In my case, event though the images had not been created before, the domTree was true! With the result that the images never were created. I suppose domTree became true due to the existense of the image in the ezcontentobject_attribute table. But something must have been wrong there, since the images didnt exist under the corresponding places in var/site/images... Wheter it was due to the length of the data_text, or anything else, im not sure. But I am sure that my troubles were caused by the domtree returning true, when it shouldnt have. It would be interesting to here your ideas about this. Kind regards, Nicklas Lundgren
Kåre Køhler Høvik	Friday 30 January 2004 6:13:27 am I'm not sure about the domTree == false satement, but I did some changs to the ezimagealiashandler in rev. 4834 to to fix one bug regarding the dom tree. -- Kåre Høvik Kåre Høvik