Really... This is odd... We have experienced the same issue on two separate VPS servers running Centos LINUX (Plesk) and one CPanel configuration. All with the same results.
-k
Any word on this issue yet..?
I still can't believe you are unable to reproduce this issue. In the past week, we have tested on a separate shared hosting account, and moved to a new VPS hosted on 1&1 (
www.1and1.com
). Same results on all! Previous configuration was hosted from a Go Daddy VPS.
-k
Hi Kevin,
I can access administrator page anymore. seem you are using custom security URL. please edit your first post at this topic any update credentials information.
I want make sure you set photos and avatar to remote storage already.
Regards
Credentials are re-activated. We do not leave this account open... When we know you are looking, we will open it up... We will leave it open through the end of next week.
Hi Kevin,
probably next week 4.0.8 will be released. and we make some improvement regarding this issue.
here the fixes:
Can you confirm that this is still the correct use of cron.php in a scheduler?
wget -O /dev/null '
www.mountainbridgeblog.com/index.php?opt..._community&task=cron
' > /dev/null
Now that the files are replaced, none of the uploaded images are moved to S3 when cron is run...
-k
Hi Kevin,
that correct, but I nee you to increase php memory limit from 128 to 512?
there is an error at cronjob process, seem missing files at site server. but I can debug it, at debug mode always got this error
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 307668 bytes)
Did not get a whole lot of time to work on this over the weekend but did make some changes.
PHP Memory = 1024
I found some malformed records in the database that was causing cron to return errors; "*_community_photos". Records were removed and cron appears to be working again.
I see that profile covers are still not being displayed in the Photo Albums when moved to S3. Will do some more testing tonight...
-k
Hi Kevin,
seem the user with missing profile cover must re-upload it. I made the test like this:
- upload profile cover
- refresh the page, the cover not revert back to default
- execute cronjob, the cover transferred to S3
- refresh profile page, the cover still same like uploaded. and the source already pointing to S3
Regards
Yes... My testing has shown the same thing... But:
- From your profile, the remote load of the cover from S3 is successful
- Goto 'Photos'; Cover thumbnail loads from local image; link to full image is broken
- This issue also applies to the Group Cover as well.
There is no cleanup of user, group or event avatars and covers from S3... They are all orphaned. You will also see that after avatars and covers are deleted from the front-end, the records for these images are not purged from the DB table '*_community_storage_s3'.
We're getting closer but this is still not resolved!
-k
Also... I think you were a little early to call this bug fixed!
I see that there is still no fix for this issue in 4.0.8. Can I get a status please?
-k