Oh, thanks for the correction, Mika. I was not being very precise, because, in truth, I’m rather unfamiliar with Amazon’s terms. It seems that what Amazon calls a CDN is CloudFront. What I had in mind was merely the S3 service, so, cloud-based storage, similar to what DreamHost is offering (in beta!) and exposing a compatible API.
Here is what I did. After setting up a bucket on DreamHost and marking it as “public”, I went to /wp-content/plugins/w3-total-cache/lib and edited S3.php on lines 819 and 1347, changing the hard-coded domain name s3.amazonaws.com to objects.dreamhost.com.
Then go to /wp-content/plugins/w3-total-cache/lib/W3/Cdn/S3.php and do the same on line 339, and, for good measure, change it on /wp-content/plugins/w3-total-cache/lib/W3/Cdn/S3/Cf.php on line 95 as well. This should be enough.
Then I went to the General tab for the W3TC plugin. I selected CDN and as a CDN Type Amazon Simple Storage Service. W3TC, at this point, complains that you need to fill in all the remaining data and push content to the cloud service.
Then I went to the CDN tab and put my API key, secret, and bucket name. Did a test (clicking the button below) and it was green — the test had passed!
Now came the next step: starting moving the initial content to the bucket. This is simply achieved by clicking a button on the messages that W3TC displays to remind you that everything needs to be pushed on the cloud. A popup appeared, saying that there were 382 objects to be pushed, and after pressing Start, it happily started to push objects over smoothly, with a green “all clear” status for each of them. So things seemed to be working!
This actually worked quite well for a few minutes, with well over 200 objects placed in the bucket, until after a while I started getting red status saying: [503] Unexpected HTTP status. Aw! And it was running so smoothly. Intrigued, I went to the DreamHost control panel, to see what was inside the bucket so far… and got “Network Error. Try Again Later”. So I did, waiting for a bit. After a few minutes, the Network Error disappeared and I could see all the objects which had been pushed so far. Yay!
Back to WordPress and clicking “export media library” once more. W3TC correctly identified that a lot of objects were already on the cloud (yay!) and up-to-date, so it just pushed the missing ones over. Cool! Everything seems to work as expected!
Then I proceeded to push the remaining bits over — wp-includes, theme files, custom files, and so forth. Often I get the dreaded network error again, and for a few minutes, nothing gets uploaded. So it takes some patience… upload as much as you can, watch for errors, wait a few minutes until the network error disappears (checking on the DreamHost control panel), and trying again. Eventually everything will be uploaded, sooner or later. After all, DreamObjects is still “beta” ??
The end result: WordPress is now using DreamObjects using the S3 API to store all static files as seen by W3TC ?? Cool stuff! Now I will very likely not be using this configuration for long. As DreamObjects are still in beta, this means that the nasty “Network errors” will simply fail to get anything retrieved from them while the situation goes on unattended. As said, sooner or later the Network Error will go away, and things will work as expected for a while.
So, this sort of proves my point. It would be awesome if W3 Edge’s developers would allow changing the endpoint without requiring it to be hacked. As more and more cloud storage providers use S3 (or RackSpace’s) API as a standard, it makes little sense to “limit” S3 just to Amazon. It also doesn’t make sense to keep adding more and more options each time a new provider becomes popular. All that is needed is a box to add a new option on the CDN tab to allow a different hostname as the API endpoint.
In fact, I understand that this S3.php is some sort of a standard library. The constructor of the class S3 defaults to s3.amazonaws.com, but the constructor can be called with a different hostname, and the library doesn’t need to be changed at all. I saw that the option page is generated from /wp-content/plugins/w3-total-cache/inc/options/cdn, but I couldn’t (yet) find the place where the WP options for W3TC are stored (to add a new one, say, cdn.s3.endpoint or something like that, and make sure it gets correctly called from the place where the class S3 is invoked by W3TC. It seems to be only called at two places, /wp-content/plugins/w3-total-cache/lib/W3/Cdn/S3.php and /wp-content/plugins/w3-total-cache/lib/W3/Cdn/S3/Cf.php but of course I’m not sure. If I have nothing to do during the weekend, I might also change that, and see what happens, even though I have no clue how to get in touch with W3 Edge to review the changes and eventually incorporate them in their next release. For now, for people not worried about hacking things, the simple hack I’ve suggested works fine.
I might move these instructions to the DreamHost wiki, too, since they might be useful for others… and post them in my blog as well, where I’m sure nobody will delete them ??
