Problem with images-versioned

Author Message

Nathan Kelly

Tuesday 05 December 2006 1:33:29 am

Hi all,

I'm setting up a forum using ez's built in forums where users "must" be allowed to attach images to forum topics and replies (the site revolves around solving problems by looking at them "visually" so it is an absolute necessity).

I'm using Daniel Beyer's method as described at:
http://ez.no/community/forum/developer/multiplefileupload_extension_discussion/re_multiplefileupload_extension_discussion__5#msg73556
To allow multiple image attachments and for the best part this works perfectly until a user decides to delete an image.

My problem is that using this method whereby I'm not placing images in the content tree any image a user attaches is stored in var/storage/images-versioned.

When I delete images from a topic or post they are removed from said topic or post, however the images still remain in the images-versioned directory. This is a major problem when it comes to disc usage as the client would like users to be able to post very large images (in excess of 3meg). So any redundant images are simply going to chew up valuable disc space very quickly and managing removed images manually is highly impractical due to the fact any user can create or remove images (How will I know which images aren't in use?).

According to this bug report: http://issues.ez.no/2874 a similar issue was fixed but in what version I don't know?

I'm currently running ez 3.7.6

Is there anything I can do to remove images from the images-versioned directory when they are removed from an object, or for that matter should they be stored elsewhere? From my understanding the images-versioned directory is used for temp images, should my images infact be stored in another directory once their parent object is published and if so how can I set this up?

This is an extremely high priority for me as I need to have my otherwise ready forums live within the next few days (or before the end of the month at the absolute latest).

Any help greatly appreciated.

Cheers!

Pardon me while I burst into flames...

Nathan Kelly

Wednesday 06 December 2006 2:15:21 pm

I still cant solve this issue, has anyone got any suggestions at all, maybe there is something I can do to patch the system?

Can I specify where these images are stored? And would it make a difference if I do?

Has anyone else ever had this problem, did you ever solve it?

Any suggestions at all would be appreciated as they might prompt me to think of something I am overlooking.

Cheers!

Pardon me while I burst into flames...

Matthew Carroll

Wednesday 06 December 2006 10:21:13 pm

Actually the bug report only says 'resolved' on the new bug system. The old one just looks like it was closed:

http://72.14.205.104/search?q=cache:www.ez.no/community/bugs/images_remain_in_images_versioned

Afraid I can't help you beyond that - I suggest you upgrade to 3.7.9 and see if the bug remains there - if so, file a report.

Actually, you may want to seriously consider upgrading to 3.8, since the 3.7 branch will no longer be supported once 3.9 is released, and that isn't far off it seems.

Matthew

http://carroll.org.uk

Nathan Kelly

Wednesday 06 December 2006 10:56:16 pm

Thanks for the reply Mat,

I'm a little sketched out about upgrading at the moment as I'm still deep in development and don't want to end up with any new bugs at this stage.

The site is live while in development and we just don't have time to deal with any new issues, but once we get the site near complete (or at least the development side near complete) we plan to backup and upgrade on a separate ip on the same server to make sure things will go as smoothly as possible. This way we can counteract any bugs etc before we do a real upgrade.

Maybe someone from eZ could tell me if there is a fix in a newer version and if it would be possible to patch 3.7.6 as a temporary solution? ;)

Cheers!

Pardon me while I burst into flames...

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.