Kunena 7.0.4 Released

The Kunena team has announce the arrival of Kunena 7.0.4 [K 7.0.4] in stable which is now available for download as a native Joomla extension for J! 5.4.x/6.0.x. This version addresses most of the issues that were discovered in K 6.2 / K 6.3 / K 6.4 and issues discovered during the last development stages of K 7.0

Topics that are moved into this category are generally considered to be closed. Users may want to add additional information but these topics should not be resurrected in order to discuss new problems or unrelated matters.

Question Deleted attached images are still present on disk

More
15 years 4 months ago #74973 by nitisara
(Kunena 1.6.1 on Joomla 1.5.22, all in Russian translation)

In Image Browser I can delete any image which was used as an attachment. It works fine.
But deleted image still exists on disk and physically is not deleted. It will lead to server overfill with images which already do not exist in Image Browser but still exist on server.

All attached images go to /media/kunena/attachments/### folders, where ### is user ID number. So, these folders constantly fill with images although user thinks that these images were deleted, and there is no back-end access to these files anymore.

Is there any way to clean up attached and then deleted images from media folder?

Please Log in or Create an account to join the conversation.

More
15 years 4 months ago #75242 by xillibit
Hello,

Check that the right on image allow the system to delete it (it's need 777 by example)

I don't provide support by PM, because this can be useful for someone else.

Please Log in or Create an account to join the conversation.

More
15 years 4 months ago #75409 by nitisara
All images are loaded as Kunena Forum attachments, and are usual jpg photos. These images have no other source.

How this happens:
I just attach a photo as an attachment to Forum post as front-end user, and then I delete this post from Forum. After this I go to back-end Image Management and there I see my photo, and it is said that this image is not used by any post. I press command to delete this image permanently, and it disappears from Image Management as it is removed.
But then I go to the server by FTP to the folder /media/kunena/attachments... and I see that physically image was not deleted and it is still present there. I can easily delete this file by FTP access to website. Annd this happens with all images which were deleted by back-end Image Management section.

Please Log in or Create an account to join the conversation.

More
15 years 4 months ago #76512 by xillibit
I mean check permissions on images to check if it can be deleted

I don't provide support by PM, because this can be useful for someone else.

Please Log in or Create an account to join the conversation.

More
15 years 4 months ago #77864 by nitisara
In your kunena.attachments.class.php file you have this:

$this->_db->setQuery ( "SELECT a.* FROM #__kunena_attachments AS a LEFT JOIN #__kunena_attachments AS b ON a.folder=b.folder AND a.filename=b.filename WHERE a.id IN ({$attachids}) AND (a.folder LIKE '%media/kunena/attachments%' OR a.folder LIKE '%images/fbfiles%') AND b.filename IS NULL" );

$fileList = $this->_db->loadObjectlist ();

So it is supposed to get $fileList array with filenames to be deleted. But this array is always 0 in size - it is always empty. After that you delete database reference of this attachment (this works fine), but image file still remains on disk. This is the problem I think - in incorrect database query which always return empty result.

I am not an expert neither in PHP nor in mySQL, so can you please tell me what I have correct in this code above that it work? I really need to clean up my images from forum attachments.
Thanks!

Please Log in or Create an account to join the conversation.

More
15 years 4 months ago #77902 by xillibit
For the moment, i will report this like bug, anyway thanks for report

I don't provide support by PM, because this can be useful for someone else.

Please Log in or Create an account to join the conversation.

Time to create page: 0.254 seconds