Question Using Amazon S3 for styles doesn't work

[fly]

So I decided to try and use S3 on my site today. I enabled the bucket, added all the pertinent info, and had vbO copy all the proper files into the new bucket. Everything is fully synced. Now, when I turn on the CDN, the styles get all screwed up with white background. It doesn't seem like any of the pics load at all.

What am I doing wrong?

 

[fly]

Never mind. I think I forgot to make the folders public in S3. Whoops

 

[fly]

Hmmm. That doesn't seem to be the problem after all. Any ideas?

 

[Fillip H.]

I will need to see this in action in order to tell you why - can you please PM me with an AdminCP account that has Can Administer vB Optimise so I can turn this setting on while I test?

 

[fly]

It looks like this is setup to use S3, and I would prefer to use their "real" CDN service, CloudFront. So I'm going to go in a different direction with this. I think we can close this. Thanks!

 

[Fillip H.]

As I was not the one who developed the CDN feature I don't know why the author decided to use S3 instead of CF.

Isn't CF a simple origin pull/mirror service? If it is, you should be able to get it working in vBO by just deleting the existing settings and setting it up again by using the relevant entry in the "choose your CDN" drop-down.

I'll hang on to the access details PM for a little while until we exhaust our options

 

[fly]

As I was not the one who developed the CDN feature I don't know why the author decided to use S3 instead of CF.

Isn't CF a simple origin pull/mirror service? If it is, you should be able to get it working in vBO by just deleting the existing settings and setting it up again by using the relevant entry in the "choose your CDN" drop-down.

I'll hang on to the access details PM for a little while until we exhaust our options

Yes, I was going to try simple style replacement variables, but I noticed the origin pull/mirror setting in vBO. Will try that next.

 

[fly]

I couldn't get it to work properly. And it seems like the plugin only changed links that used the BBURL, and not links that were relative. In the end, I created my own plugin to do a simple str_replace to my CDN url.

 

[Fillip H.]

That's correct, it's unfortunately not feasible to change relative URLs as we have no frame of reference. Not only that, but since relative URLs can use directory navigation syntax like "../../images/something.jpg" that can cause problems when combined with absolute URLs.

Sorry

 

[fly]

I know this goes beyond support of this product, so if you don't feel comfortable answering - that's cool. In your professional opinion, am I really liable to break something by doing this in a plugin?

$oz_process = str_replace('"http://www.forums.com/clientscript/vbulletin_css/', '"http://css.forums.com/clientscript/vbulletin_css/', $output);  
$oz_process = str_replace('"http://forums.com/clientscript/vbulletin_css/', '"http://css.forums.com/clientscript/vbulletin_css/', $oz_process);  
$oz_process = str_replace('"clientscript/vbulletin_css/', '"http://css.forums.com/clientscript/vbulletin_css/', $oz_process);   

$oz_process = str_replace('"http://www.forums.com/clientscript/', '"http://js.forums.com/clientscript/', $oz_process);   
$oz_process = str_replace('"http://forums.com/clientscript/', '"http://js.forums.com/clientscript/', $oz_process);   
$oz_process = str_replace('"clientscript/', '"http://js.forums.com/clientscript/', $oz_process);   

$oz_process = str_replace('"http://www.forums.com/images/', '"http://images.forums.com/images/', $oz_process);   
$oz_process = str_replace('"http://forums.com/images/', '"http://images.forums.com/images/', $oz_process);   
$oz_process = str_replace('"/images/', '"http://images.forums.com/images/', $oz_process);   

$output = $oz_process;

 

[Fillip H.]

It looks good in theory, obviously I can't vouch for it as I haven't tested it personally but nothing springs to mind.

I'm not sure if CSS files will be covered by this replacement, though. As in, the contents of the CSS files. That's one of the things vBO handles before it sends the CSS to the CDN.

 

[fly]

It should. If CloudFront doesn't have the file cached yet, it just grabs it from my webserver and moves it into the global cache. Thanks for looking it over.

 

[Fillip H.]

But the replacement variables are executed on templates, and .css files are flat files and served as such.

Though to be honest I would be 100% unsurprised if you know more about this than me since I've not looked at the actual code, this is just my initial reaction (to give you a reason why it's not working if it turns out not to)

 

[fly]

It seems to be working, but I'll check and make sure CF is actually serving the CSS. Thanks again for your help.

 

[Fillip H.]

You should check that CF is serving the images referenced inside the CSS files - if that's not happening, you're missing out on a not insignificant portion of images (in fact, nearly all of them).

 

[fly]

You are correct. It isn't. I will have to go back to the mirror/pull origin deal. What I didn't understand with that was exactly what it was doing when I enabled it. With S3, I had to give it my credentials and it pushed the files to my S3 bucket. With the mirror/pull origin option, it appears to be doing the same thing (it loops through about 2000 files), but has no credentials to actually do anything. Any chance you could explain what its really doing?

 

[Fillip H.]

From my understanding of how an Origin Pull / Mirror works it's kind of like so:

1. You configure the source domain on the CDN to be domain.com/forums/
2. A browser requests an URL from the CDN, like cdn.something.com/images/image.png
3. If the file is not found on the CDN server the user is relegated to, the CDN looks up the source domain and pulls domain.com/forums/images/image.png and stores it on their server / displays it to the user

The reason why vBO is still looping through your stuff is because it's preparing the image paths inside the .css files for the pull request from the CDN whenever the CSS is loaded next. The fact that it prints image paths may be a result of abstraction in the "prepare CDN" code - in other words, it will always print the image paths even if it's not actually pushing the image anywhere, just to let you know it's not hanging.

 

[fly]

In case anyone else had this issue, I thought I'd come back to mention that I fixed it. I'm not *sure* exactly how, but I've done a couple things. I was running an old version of Nginx, so I updated that. I also updated to the latest version of PHP 5.3.