This started in this post with the wrong bucket endpoint: http://stackideas.com/forums/es-using-incorrect-s3-bucket-endpoint. That issue was solved but then led to a discussion of a recurring problem with file transfers to Amazon.
I applied the two patches in that post.
A few new users have registered on the site, and none of them have had their avatars or cover photos transferred to S3.
Here are some snippets from that post:
I will send site credentials through a secure private ticket.
I applied the two patches in that post.
A few new users have registered on the site, and none of them have had their avatars or cover photos transferred to S3.
Here are some snippets from that post:
I am on ES 1.4.6. The site has been running ES for more than a year. The remote storage was set up about three months ago
The vast majority of my avatars are still being served from the server. Looking in the social_avatars table there are only 14 entries with storage value of "amazon". A whopping 87 entries in that table are still showing "joomla" as storage. So roughly 80% of my avatars somehow missed the transfer. Some of the avatars still on the server date way back to 2014.
Similarly, the social_photos DB table shows 36 entries with storage "joomla", and 208 with storage "amazon".
For some reason a few pics and nearly all avatars were missed at some point by the cron. And, it seems to me, that if an image is not picked up by the ES cron on the first run, then it is forever left on the server. i.e. the cron will never try to transfer the image again from server to S3. Is that correct?
The cron has been botching transfers ever since I switched to S3 storage, so it's not specifically related to the API issue which you fixed which seems to have started on Jan 1st of 2016.
I will send site credentials through a secure private ticket.