ISSUE SUMMARY:
This is an issue that has gone unresolved for a few years now... Covers are not linked properly after uploading covers when an installation is configured to store images on Amazon S3.

I found the fix to resolve the User Cover, but the Group and Event covers are still impacted. Is there a code fix that can be applied for these covers as well... and is the dev team ever going to fix this issue?

-k

Hi Kevin,

please provide me FTP access detail by editing your first post at this topic. put it at site info form.
I need it for debugging purpose.

or if you want wait our next release 4.0.7, probably this week. at that version I cant replicate this issue anymore. it fixed.

Regards

Lets wait until the next release. I don't want to fix the issue twice.

Thx,

-k

Hi,

today version 4.0.6 has been released. please try it with that version. and let me know the result

Regards

Nope... Neither the group or event cover issues are fixed in the latest patch. The change log clearly says that the profile cover issue is fixed though. How long before 4.0.7 is released?

There is a difference with the Group and Event Covers (Different than Profile Cover)
1. Image is uploaded as group OR event cover
2. Image is uploaded locally to a cover album but is not set as cover
3. Cron task does not move group or event cover into S3

Is there already a code fix for the issue...

-k

Hi Kevin,

please edit your first post at this topic. and update credentials information at site info form. I need working access detail for FTP and administrator page.

Regards

Access credentials updated...!

I've done some additional testing and it appears that the patch did NOT fix the profile cover issue... It is actually worse now

User Profile Cover:
1. Upload new cover to webserver. Cover is set to local copy
2. Cron Task runs; cover is copied to S3 bucket; cover image is NOT removed from webserver; link to profile cover image is broken
3. The photo display from the album displays copy from S3
4. Modify Cover and select the cover image uploaded in step 1; cover is set from local copy NOT S3 copy
5. Remove the Profile Cover image; image is removed from photo album and S3 bucket but copy is orphaned on webserver at '/images/cover/profile'

Group Cover
1. Upload new cover image; cover image is NOT set; default cover is displayed
2. Cron Task runs; cover image is copied to S3 bucket; cover image is removed from webserver; Cover image is set from copy in S3 bucket

Event Cover
1. Upload new event cover image; after refresh, event cover image is NOT set; default cover is displayed
2. Cron Task runs; cover image is copied to S3 bucket; cover image is NOT removed from webserver; Cover image is set from copy in S3 bucket
3. Upload multiple event cover images; delete all event cover images; allevent cover images removed from S3 with copies orphaned on webserver

Hi Kevin,

please give me time for this issue.

Regards

Hi Kevin,

1. please set at jomsocial backend > photos > photo setting, delete original photos = Yes
2. edit /components/com_community/tables/event.php around line 1180, find this code

if ($this->storage != 'file') {
    $storage = CStorage::getStorage($this->storage);
    return $storage->getURI($this->cover);
}

//if ($this->storage != 'file') {
    $storage = CStorage::getStorage($this->storage);
    return $storage->getURI($this->cover);
//}

Made the changes, tested and backed out... These changes made everything worse. All uploaded covers are essentially lost after the cron task runs... This is now creating orphaned cover images on both the webserver and in the S3 buckets.

I would honestly recommend that you guys strip out this feature from JS... it hasn't been fixed in the 2+ years since I first reported it and I have little hope that it will and frankly irritated that I'm paying for something that doesn't work.

I'm removing the S3 configuration and going to try using the JoomlArt S3 component instead.

-k

Because of the way images are being displayed, we can't use JoomlArts S3 component to leverage cloud storage.

With that said, we are stuck with this flawed S3 feature of JS. I'm astonished to be the only apparent customer upset about this. When will it be fixed?

I have spent several hours beating up the many use cases revolving around the image features and this is not the only problem that JS is facing. I've found several other issues where uploaded images are being orphaned on the webserver storage with no way of logically purging them without writing a custom script. Due diligence appears to be slacking in the Q/A department.

-k

Hi, Kevin.

Please, open new, separated threads for those several issues where uploaded images are being orphaned. Let developers to take care of them too. I'll talk about this issue with our developers if we could focus on this one and find the root cause...

I wasn't suggesting that the developers shift their focus to other issues... I was suggesting that Q/A efforts on this component could use some help!

Lets stick with fixing the remote storage issues and then I'll share some of the other mis-behaving features I've found!

Hi Kevin,

I still investigate this issue, please give me time. I cant replicate this issue at my test site.

Regards