Support » Plugin: DreamSpeed CDN (RETIRED) » Not all images uploaded??
Not all images uploaded??
-
I setup the plugin and got everything working…
decided to migrate existing files.During the migration the mem-cached issue happened on my dreampress site.
So….it seems that most content uploaded…but some didn’t.
http://www.jaxrestaurantreviews.com/southside/dicks-wings-great-place-watch-game/The thumbnail images aren’t on the CDN but the full size image is (if you click the linky on where the thumbnail should be)…
Can I force a re-upload or something?
-
You could do it manually, but there isn’t currently a way to retriggwr the upload.
It would just be copying up the uploads folder to the cloud using CyberDuck or such.
How does the plugin “know” what’s been uploaded?
I’ll try syncing the bucket with my upload folder and see if that fixes it.
It’s stored in the db as meta data in the _postmeta table.
When you run the upload existing, it hits each post, looks for attached media, and uploads known sizes that are created with the add media functions. I’m not sure why the memcached bug would have done that. That should have uploaded nothing, or not updated the db. Updating the db and not uploading the images is … Weird.
perhaps I’m jumping to conclusions…
But…it’s weird…
http://cdn.jaxrestaurant.reviews/wp-content/uploads/2013/11/Marinated-cheeses-225×300.jpgI manually uploaded that from the WP install to the CDN and it’s not showing when I hit that URL…is there some kind of delay?
No, no delay.
http://cdn.jaxrestaurant.reviews/wp-content/uploads/2013/11/Marinated-cheeses.jpg doesn’t show either.
Is the bucket Private? The tool default uploads as public (for … obvious reasons)
I’m really confused. Yes, bucket is public and all images were originally moved using the plugin. However, last night I copied uploads over and replaced what was already in the bucket.
I checked this morning and the list of files are exactly the same.
for Simplicity I focussed on one article http://www.jaxrestaurantreviews.com/tapas/13-gypsies-riverside-tapas/What I found was the permissions on the bucket (according to transmit) were Read:Owner instead of Read:World
When I changed 1 images permissions it seemed to work…however when I try to do it in bulk it seems to not apply the changes.
What I found was the permissions on the bucket (according to transmit) were Read:Owner instead of Read:World
On the BUCKET or the images? Or both?
Because… yeah, well that’d do it 😀
on the images…bucket is definitely World readable.
but not all of them…I moved about 18 months worth of images and it seemed like it everything older than about a year experienced the same issue. Newer stuff moved fine.
I guess @ this point it’s “solved” though…I just can’t figure out why the permissions would change 1/2 way through the upload. Does it do newest to oldest or oldest to newest when making a move?
It does oldest to newest. I’ll check with the dho team and see if we had a glitch when you were uploading.
hmmm…is there any correlation between permissions on the server to object permissions in the bucket?
In any case, this particular case is closed…though changing permissions sorta sucks as you have to drill down to each file as changing it at the folder level fails silently within transmit.
What do you mean? Do you mean if the file permissions on the web server are read only, will that transfer up to the server?
I … don’t know! That’s something to test.
nah…maybe a potential problem…but not in this case…
both old images I had trouble with and new stuff are 644.
So, something else weird happened.I get a similar problem to this, i.e tried using the “Upload Existing Media” button and despite what it said I needed to click it over and over again for all of the media to be considered fully uploaded.
But after all this I noticed that random images did not show up on the site and when I looked through the wp-content/upload folders sure enough some images were there and others were not.
Finally I eventually noticed that there were additional year and month sub-folders and these actually contained the missing images but were essentially useless as they were not linked correctly by the website, plus also the fact that the new renamed year and month bore no reference to the source images time and date stamp??
So I’ve finally now deleted and re-uploaded everything via cyberduck (which has messed up the all permissions also!) and now set all permissions to Everyone-Read and now it FINALLY WORKS AGAIN! (sorry it’s been frustrating as everything uploads/downloads sooooo slowly via cyberduck…)
So unfortunately this has not been a very smooth experience. Might be worth debugging why the images are moved/renamed to previously non-existent year/month folders?
I guess I’ll know if the other part of this plugin works next time we upload something new?
It gets the folders based on the time/dates of the POSTS not when you upload the images
I wonder if this is happening because you uploaded the images while on another post and they’re they’re somehow attached to an older dated post but being used on this one? It should match whatever they’re attached to though…
I’ve not been able to reproduce this myself, which has made it a nightmare to debug 🙁
Hi Mika,
The original configuration of the updloaded images was in the order that they were posted. And like I said once I re-uploaded a previous backup of the content in the original formation onto the CDN it all worked again.
Not entirely sure why all the images were shuffled into different year date folders but can only say that I was experimenting with the WP Super Cache plugin at the same time.
I tried static caching but I’m pretty sure I disabled it before enacting the Dreamhost CDN “Upload Existing Media”? But none-the-less perhaps the interaction between these two plug-ins is what cause the trouble?
I still would like to enable static caching in WP Super Cache and even the CDN support that it has built in but I’m a bit once-bitten now.
Do you have experience with using these plugins together to speed up a web site?
- The topic ‘Not all images uploaded??’ is closed to new replies.