Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: wordpress

  • The Anarchy of .htaccess and Multiple Domains

    The Anarchy of .htaccess and Multiple Domains

    Traffic sign of 301 htaccess redirectWhen you use domain mapping on a Multisite install (or anything similar, I know Drupal has this too), you run into the issue of sometimes wanting to redirect a URL just for one domain.

    Over the 15 years I’ve had this site, I’ve moved my blog posts around from https://ipstenu.org/ to http://blog.ipstenu.org back to https://ipstenu.org/ and then https://ipstenu.org/blog/yyyy/mm/dd/postname to https://ipstenu.org/blog/yyyy/postname and finally to https://ipstenu.org/yyyy/postname And in those years, I’ve managed to never slaughter my SEO. Why? Becuase I know the secret magic of .htaccess. I don’t (yet) use nginx, I’m sure that will change one day, so right now my genius is limited to knowing how to do a nice regex redirect in .htaccess.

    The majority of this magic comes in two lines:

    RewriteRule ^blog/([0-9]{4})/([0-9]{2})/(.*)$ https://ipstenu.org/$1/$3 [L,R=301]
    RewriteRule ^blog/(.*)$ https://ipstenu.org/$1 [L,R=301]
    

    I also have this to handle the blog.ipstenu.org:

    RewriteCond %{HTTP_HOST} ^blog\.ipstenu\.org  [NC]
    RewriteRule ^(.*) https://ipstenu.org/$1 [L,R=301]
    

    The RewriteCond is the neat bit that says ‘If you come here from blog.ipstenu.org, use the following rule.’ The [NC] is because domains aren’t case sensitive, and we want to CYA.

    For my old setup of a single install, this was great. Today I’m using Multisite, and if I used that redirect, then any site on my network would be redirected! If you’re using subfolder Multisite, you don’t need to worry about this at all, since a redirect for ^blog/ will only impact a URL that has the first folder of /blog/. And that’s precisely why it’s a problem for Subdomains and mapped domains (of which I use both). That redirect up there would affect both https://ipstenu.org/blog/monkeys and http://photos.ipstenu.org/blog/monkeys and https://halfelf.org/blog/monkeys — and I don’t want any of that. I only want to redirect for those URLs if you’re going to ipstenu.org.

    Thankfully, if you look at what I did for redirecting blog.ipstenu.org, you can easily see how to leverage that for this into two checks:

    RewriteCond %{HTTP_HOST} ^ipstenu\.org  [NC]
    RewriteRule ^blog/([0-9]{4})/([0-9]{2})/(.*)$ https://ipstenu.org/$1/$3 [L,R=301]
    RewriteCond %{HTTP_HOST} ^ipstenu\.org  [NC]
    RewriteRule ^blog/(.*)$ https://ipstenu.org/$1 [L,R=301]
    

    Why did I duplicate the RewriteCond? Typically, you cannot use multiple RewriteRule statements following a single RewriteCond. That means for ever call I make to a domain, I can use but one rewrite rule. There are ways around that, but none of them worked well for me.

    If you look at halfelf.org, however, the world gets even messier. Half-Elf is the combination of three domains. Ouch. Two can point to the same place, one needs to redirect totally differently, and then I have a category merge. Oddly that came out as only three sets.

    First we can look for http://code.ipstenu.org and http://tech.ipstenu.org and redirect everything to https://halfelf.org. The trick to this is using (code|tech) in my RewriteCond, which really is one of my favorite things. That’s a built in ‘or’ right there, and if I had a hundred subdomains, I could still do that.

    RewriteCond %{HTTP_HOST} ^(code|tech)\.ipstenu\.org [NC]
    RewriteRule ^(.*) https://halfelf.org/$1 [L,R=301]
    

    Next we want to redirect http://ebooks.ipstenu.org to https://halfelf.org/my-ebooks/ – notice how I don’t want to redirect it like I did for code and tech. Here, everything gets dumped back to the ebook page:

    RewriteCond %{HTTP_HOST} ^ebooks\.ipstenu\.org [NC]
    RewriteRule ^(.*) https://halfelf.org/my-ebooks/ [L,R=301]
    

    Finally I want to tackle the merge of my old categories, and again this is straightforward:

    RewriteCond %{HTTP_HOST} ^halfelf\.org [NC]
    RewriteRule ^category/code/(wordpress|bbpress|buddypress)(.*)?$ https://halfelf.org/tag/wp/ [L,R=301]
    

    My actual .htaccess is even crazier, since I have four domains pointing to multisite plus an add-on for my short URLs.

    This should get you started on customizing redirects in .htaccess for multiple domains. What are you favorite tricks?

  • Amazoned

    Amazoned

    Amazon.com IconI don’t actually like Amazon. However the Kindle people spoke and I listened. After checking that, yes, I can release my ebook for sale on the Kindle legally (that was a weird conversation), I sat about doing it. I really wanted to self-publish on lulu, but … well, Amazon was easier. There. I said it. They actually know what they’re doing, and made it surprisingly painless! Of course, that they want you to write it in .docx, export to html, then upload a zip, was a little nuts. They also let you upload ePubs, which I have, so that was a lot easier.

    I am now a Amazon Author or publisher. Whatever. And I have two books up on Amazon:

    There’s no DRM on these puppies, and while, yes, it costs $7.99 to download, that’s because Amazon takes a really hefty chunk of change. See for every $5 you donated to me, I got $4.50 from Paypal and WePay. Amazon takes 30% or 65% of your money for every sale. Now I know, you’re thinking ‘Why would anyone pick the 35% option!?’ In the ‘real world,’ publishers give writers around 15% in royalties. Seems like a rip off at first, but look at what goes into all this. Writing, editing, typesetting, printing, binding, shipping, advertising, etc. And I’m skipping all that to go at it alone.

    So why would I pick 35% for epublishing, when all they’re doing is webhost plus bandwidth? If you pick 70% royalties, then you get 70% of the cost, minus ‘shipping.’ Shipping, by the way, is electronic delivery. You’re paying for the bandwidth. Fair enough, works out to about $0.05 for every country. But also with 70%, I can only charge between $2.99 and $9.99 US for my book. So the max I can charge is $9.99, which will ‘net’ me $6.96. With 35% I can charge up to a couple hundred ($299.99). Now here’s the dillema. How much to charge. If I max out and go to $9.99 (damn it, I wish they’d just say $10!), I may look greedy. Then again, I did all the work here, do I not deserve my $7 per book? To get the $4.50 I was getting via donations, I’d have to charge about $6.75 for the book, at which point I may as well charge $7. Then again, the average donation I got was actually closer to $8.

    Which is how I ended up at charging $7.99 you see. I don’t expect to break the bank. Hell, I don’t expect lightning to hit like that again. But it was kinda cool. By the way, you don’t get 70% for all countries, just the ones that allow it. The rest get you 35% instead.

    The biggest hassle, other than price, was sorting out the various fields, which in and of themselves, weren’t that hard. Took me an afternoon, and I had the books approved by later that day. I found an error (I’d uploaded the wrong cover, go me) and made a fix, for that I waited a day for the republish and the image to show up. Weird, but not complicated.

    I have to say, Amazon is a hassle, but far less than other places that say ‘You need to make an ISBN’ and ‘You must follow these formatting guidelines.’ which are cryptic and … You know, if they really wanted to make things easy, someone would make a nice form where you could upload your book, sans cover and author pages and copyright. Just the book content, right? Then once it’s uploaded, from epub or docx, you create your author ‘page’ and place it where you want (front of TOC or behind) and then copyright page ditto. Finally you upload your cover. If an ISBN is required, you make it for them. Remember, self publishing is something that you should be helping people do! Otherwise what’s the point?

    Amazon (mostly) hits that one on all the marks. Why not iBooks, you may ask? The tool sucked. No, really. I wrote a doc in pages (Apple’s version of Word) and you’d think I could upload to iBooks and it would auto-format. Nope. Also there was the restrictive bit. Apple’s terms say that any content produced with iBooks Author that is for sale is to only be available on the iBookstore. Free ones can be distributed anywhere you like, but iBooks Author only exports to the .ibook format (and PDFs) so if you want to free-distribute (which technically is what I do here), you have to use a flat PDF. Okay, that isn’t really terrible, the epub to pdf ratio is 1:70. But then I can’t ‘sell’ on Amazon! Amazon, by the way, only locks me down if I’m using the KDP Select program. At least I think so. I read the legalese a few times.

    Fairness to be had, I don’t feel that it’s ‘wrong’ for Amazon or Apple to restrict what you can do when selling your books. It’s free, you get what you pay for, as it were. Both Amazon and Apple take a 30% cut, and all things being equal, Amazon is a better choice. Of course you can still download them ‘for free’ if you want to from my ebooks page. Donations, as always, are welcome.

  • WordPress Multisite 110 – Electric Boogaloo

    Multisite 110

    Introducing WordPress Multisite 110

    I promised a sequel and I delivered. I hope you guys find it helpful. The sequel is out, and it’s longer than the original. Weighing in at over 80 pages, WordPress Multisite 110 has even more information about WordPress Multisite!

    Why a sequel and not a second edition? There were more things to add than a few extra plugins. Branching into a little more philosophy and explanations to the whys, Multisite 110 hopes to be the second handbook you’ll need. The funny thing is most people who read my site regularly don’t need this at all. But your clients might. Imagine being able to hand that off to them saying ‘I’ve got you started, here’s how you can make it epic.’

    Oh yes, with a Creative Commons release, you can pass this on to your clients as you like. I won’t stop you, just don’t sell it to them. If you want to get into the shenanigans, you can bill them for it, but not sell it. Yeah, licenses will kill us all one day. Speaking of licenses, there’s code in this one, and it’s all under GPL2 (most of it’s also on this site already).

    What’s not in it? Deep diving into the database. Fixing everything… There’s no way to cover everything. This one gets into the machinations of how you make a multisite where everything looks the same, or where your admins aren’t admins at all. Favicons? Got that covered too! The White Page of Death? How to figure out what plugin you want? Man, you know I got your back! Backups, control, security, uploads… the list isn’t endless, but there’s a lot going on.

    Check out WordPress Multisite 110

    The post title of ‘Electric Boogaloo’ comes from a movie that came out in 1984: Breakin’ Two: Electric Boogaloo. All sequels should have that sub-title

  • You Can’t Be Everything

    You Can’t Be Everything

    There’s no app out there that does everything.

    A lot of you just said ‘I know.’ but did you ever stop to think about why that’s the case? After all, some applications do everything you need them to do, and some you don’t, so who gets to decide what is and isn’t needed? When I talked about how WordPress was just fine on it’s own, without any plugins, people stepped up and said “But Ipstenu, I really need XYZ.” Heck, Lorelle said she needed Akismet.

    Learning how to separate your personal needs from the needs of the masses, when writing software, is a full-time job, and many of us come at it from a slant-wise point of view. In fact, writing core code for WordPress is in diametric opposition to why we write plugins! While I’m going to talk about it from a WordPress point of view, the concept holds true to any application that has ‘add ons.’

    Plugins are written, by in large, to solve a specific problem. They’re not ‘fixing’ WordPress, they’re expanding. Remember, your iPhone wasn’t broken until it had Angry Birds, nor was your iPad incomplete without Twitter. Those are things you wanted, and solved a problem for you. The base tools, in and of themselves, address a broader group of people, with a diverse set of needs, and have the option of being everything or nothing.

    The best tool, WordPress, your computer, etc, are built to be extendable. They’re built with the innate knowledge that the users may want things they can’t forsee. Five years ago, how many of you thought Google+ or Twitter would be a ‘thing’?  Let’s take that further. You know how when a new video game comes out, sometimes you can’t play it on your older computer? That’s because it wasn’t built with the new game in mind, so it’s just not capable. And that’s why computers generally let you upgrade memory, CPU, and hard drives. They are built to be extendable becuase they know they can’t know the future.

    Bringing it back to WordPress, it was built to meet a need. People wanted to blog, they wanted it to be easy and they wanted it to just bloody work! So the Matts said ‘This is what we want’ and built it. Thankfully, they understood that people wanted to extend WordPress. But not at first. Oh you didn’t know? Back in December 2003, a ‘new feature’ was introduced called my-hacks.php, which let you put a file by that name in the root of WP, and it would treat it like a functions file. In fact, that’s why I call my non-plugin code ‘hacks.’ Heck, we didn’t get pretty permalinks until January 2004 (then called ‘cruft free’ URLs).

    The point of this is not to expose the funny looking beginnings, but to demonstrate the nature of the software. As it grew, people had needs, and instead of writing everything into core, they cleverly changed WordPress so it was extendable and let people grow as they needed. So when we talk about things like needs and wants, we do it in the understanding that we write our software to fill a need, and we make add-ons to fill wants. Sounds like double speak, I know, but that’s why I said plugins and core development are in direct opposition.

    When I want to add things to core, I want them to be useful to everyone, so I’m forced to remove my ego from the equation. Looking at the (few) core submissions I’ve made, I carefully thought them out beforehand. I looked at places were the user experience was inconsistent or diminished. When I make suggestions or offer commentary to what I think could be better, I try to show my passion without acting like a teenager’s first big crush, or a screaming fangirl meeting her heroes.

    This isn’t to say I don’t think passion is a part of the driving force of any product, but that it must be tempered and controlled in things like WordPress core. We know that we can’t make WordPress core do everything, and we know we shouldn’t. When things are extendable, we utilize that and demonstrate our fire. When they’re difficult to extend, or kludgy to implement, we come back and say ‘You know, it would be nice if we could…’ But at the end of the day, when WordPress tags your trac ticket ‘wontfix,’ it’s because they know, being unable to be all things, that they must limit the things they are.

    If you haven’t yet, take the time to read WordPress’s Philosophy.

    Aaron Jorbin - Haters Gonna HateWhen I usually talk about divorcing my ego from a project, what I mean is that I don’t let my passion cloud my better judgement. One of the lessons I’ve learned in nearly 20 years of active fandom is that when you love something, you get fired up about it, and you tend to view peoples opinions and actions as a personal attack when, in fact, they often aren’t. Yes, there are idiots and trolls and people who hate-monger, but in general, people actually aren’t dicks. They’re selfish and self-centered, but that’s just human nature. Part of designing a project means you have to let go of your personal attachment to your baby, and understand that haters are just gonna hate, and there’s nothing you can do about it.

    This also applies to using a tool, though. People mock the evangelists, and we all hate the extremists, and certainly no one actually supports those who are outright malicious. But all those archtypes come part and parcel with a system, and are all aspects of the simple problem that no one product can do all the things. We want things to be a silver bullet, to fix everything we, personally, have a problem with, and we’re totally unrealistic in wanting that.

    Mark and I were talking recently, and he pointed out that WordPress was once 230kb. It’s now 3.8megs, even zipped up. Part of this is because it all grew and became more, but if you ask the old-timers, some will complain that around the 1.5 days, WordPress just became too big. It does too much! And those people say we should pull things like the importer out of WordPress. After all, you’re going to use it once, if at all. Core plugins would get pretty big too. Jetpack is 2.4megs on its own, zipped up. By trying to be everything, maybe we’re making things a little worse.

    So the next time someone gets their panties in a bunch at you for not doing everything, tell that it’s by design. Do what you want with your code, make it easily extendable for the next guy (or forkable), and carry on. They’re not getting that unicorn.

  • WordPress 3.4 – No Problem

    WordPress 3.4 – No Problem

    It’s in beta, don’t nobody panic.

    The last 3 releases of WP, I’ve made troubleshooting posts about what to do, what plugins are going to barf, and so on. This time, there really doesn’t seem as much to worry about. Of course, having said that, everything will die in a fire. Actually, though, I haven’t made a list of things yet, because there’s nothing to list. I’ve not run into any stand out ‘Oh shits!’ and the forums are remarkably quiet. So. If you’ve got stupid problems, or found you have to edit themes/plugins, please reply and let me know! I’ll get on it.

    So here’s some of the cool new stuff:

    Akismet 2.5.6

    Custom Headers and Backgrounds — See also Flexible Headers in 3.4 Themes and Backwards Compatibility for WP 3.4 Headers and Backgrounds

    Twitter was added to oEmbeds — This should just work out of the box, but if you have a plugin (like Blackbird Pie), you may want to disable it before upgrading.

    RPC-XML support for Custom Post-Types.

    Admin Toolbar To The Top! Click on any blank space in the admin bar and you go to the top of the page. (It’s the toolbar, damn it, I know this!)

    Sexier Theme Options. Have you ever wanted to see what the changes did to your theme on the fly? Go to WP Admin > Themes and click on Customize Theme to get a quick way to see what you’re tweaking. Not every option is there, nor will every option be added, but this is pretty nice!
    Theme Options

    You also get that view when you preview a theme.

    Of note, Twenty Twelve and Favicons got punted to 3.5.

    Edited to add…

    Jane Wells has a nice write up of some of the new stuff. It’s on .com, but a lot of this (all) is on 3.4 too. What? You didn’t know .com used the same (mostly) WordPress we do?

  • jQuery – Why U No Enqueued?

    jQuery – Why U No Enqueued?

    DevoThis is a followup to my how to get your plugin in the WordPress repository post.

    While code isn’t outright rejected for being ‘bad’ code (only security holes and guideline violations), a lot of plugins are doing the easy things wrong. These plugins will get approved, but they won’t work with all setups, they’re more likely to have issues with Multisite, and they’re just not thinking forward. They aim to solve a, singular, problem, without looking beyond. Primarily I see this when people are trying to bring in some js code into their plugin. Heavens knows I do it, and I’ve done it wrong too. But as I see more and more plugins, I’m starting to get better and better at knowing what’s wrong when I see it.(“I know it when I see it” thanks to United States Supreme Court Justice Potter Stewart)

    The easiest way to show you is to give you some really bad examples and go through some of the steps to fix it. The best part is that I’m actually going to use real plugins I’ve seen. Only the name has been changed to protect the innocent.

    Ready? Here’s what we’re doing wrong.

    Not using functions to define locations

    The very bad code:

    echo '<script src="/wp-content/plugins/myplugin/myscript.js"></script>';

    I wish this was something I made up. Worse, I’ve see it more than once. Recently.

    This install is assuming WordPress is installed in the root of your HTML folder (i.e. domain.com). This is not always the case, as many people install WordPress in subfolders. We’ll need to fix that first with home_url().

    echo '<script src="'.home_url('wp-content/plugins/myplugin/myscript.js').'"></script>';

    Now it’s a little better, as by using home_url() we’re letting WordPress define where ‘home’ is. Great! This has two pretty obvious problems, however. First, if I have WordPress installed in a folder, like /public_html/wordpress/, but I’m running it out of the main domain by giving it its own directory, this won’t work. Your code would point to http://example.com/wp-content… when mine is in http://example.com/wordpress/wp-content.. instead! The ‘easy’ fix is to change home_url() for site_url(), but what if I’m not using wp-content? You didn’t know we could Move wp-content? We can. So let’s address that.

    echo '<script src="'.content_url('plugins/myplugin/myscript.js').'"></script>';

    By using functions to determine plugin and content directories, we can make this much more flexible. That works, but it could be better. What if we didn’t have to define the plugins or myplugin folders? We could just do something simple like this.

    echo '<script src="'.plugins_url('myscript.js',__FILE__).'"></script>';

    Now we have a simple, flexible, functional script embed of js. Except there’s one, minor problem. We’re not including the script correctly.

    Not enqueuing files

    This isn’t ‘wrong’ really. I mean, if I put this in my plugin, it would echo out the script, and that’s what I want, right?

    echo '<script src="'.plugins_url('myscript.js',__FILE__).'"></script>';

    But let’s say I want to put it in my header:

    function my_scripts_method() {
        echo '<script src="'.plugins_url('myscript.js',__FILE__).'"></script>';
    }
    add_action('wp_head', 'my_scripts_method');

    And now I want to include my CSS so it looks pretty:

    function my_scripts_method() {
        echo '<script src="'.plugins_url('myscript.js',__FILE__).'"></script>';
        echo '<link rel="stylesheet" type="text/css" href="'.plugins_url('myscript.js',__FILE__).'" media="all" />';
    }
    add_action('wp_head', 'my_scripts_method');

    Oh, wait, no, I wanted my JS in the footer:

    function my_scripts_method_foot() {
        echo '<script src="'.plugins_url('myscript.js',__FILE__).'"></script>';
    }
    function my_scripts_method_head() {
        echo '<link rel="stylesheet" type="text/css" href="'.plugins_url('myscript.js',__FILE__).'" media="all" />';
    }
    add_action('wp_head', 'my_scripts_method_head');
    add_action('wp_footer', 'my_scripts_method_foot');

    And really, this will work. But it’s not efficient, I’ve got extra actions, and I’m not considering any jquery dependencies anymore. By using wp_enqueue_script is better. Weblog Tools Collection did a series on how to properly add scripts (note that it’s a bit out of date with the use of WP-CONTENT constants). From that we can extrapolate to use just this to include our js and css:

    function my_scripts_method() {
        wp_enqueue_script('my_script', plugins_url('myscript.js',__FILE__) );
        wp_enqueue_style('my_script', plugins_url('myscript.css',__FILE__) );
    }
    add_action('wp_enqueue_scripts', 'my_scripts_method');
    

    What enqueue does is put your code in the best possible location and can be extended to load dependencies. wp_enque_scripts has a lot of power, and because it’s a WordPress function, it’s got options that make it more flexible. Like when I look at my above code, I remember, oops! I wanted to run my js out of the footer! Not a problem. Look at my options.

    wp_enqueue_script('handle', 'source', 'dependencies', 'version', 'in_footer');

    jQuery Logo looks like a Devo HatThe ‘handle’ is what I want to name my script, it should be unique. If I register my script, I can call the handle over and over again. We’re using my_script right now. The ‘source’ is where my file is located. We’re lifting that from our other code, the bad code, because it works. Your ‘dependencies’ are the other js files yours needs to function. If I put in array('jquery', 'scriptaculous') then both jQuery and Scriptaculous would get loaded before my script. Curiously, you don’t actually need the ‘version’ option, as you can leave it blank and WordPress will automatically add a version number equal to the current version of WordPress you are running. So every time you upgrade WP, it will get updated and force a re-download. This is good, since if you have dependencies to scripts included in WordPress, and they change with a new version (which is the only way they can change), then you get updated too. Finally we have the value I was looking for, ‘in_footer.’ Leave it blank and it’s in the header, put in true and it’s not.

    This makes my code:

    function my_scripts_method() {
        wp_enqueue_script('my_script', plugins_url('myscript.js',__FILE__), '','', true ););
        wp_enqueue_style('my_script', plugins_url('myscript.css',__FILE__) );
    }
    add_action('wp_enqueue_scripts', 'my_scripts_method');
    

    Yeah, isn’t that a lot easier?

    Using a different jQuery

    This last one I’m going to touch on today is the exact code I saw, in the wild, and it’s got two of my three buggaboos in it.

    wp_enqueue_script('jquery-1.4.3.min.js', '/wp-content/plugins/myplugin/js/jquery-1.4.3.min.js');

    Okay. You already know the right way to call the script, so we’ll edit that into something more flexible.

    wp_enqueue_script('jquery-1.4.3.min.js', plugins_url('js/jquery-1.4.3.min.js',__FILE__) );

    That should be okay, but it’s totally not.

    Most importantly here, we’re calling jquery, which is actually built in to WordPress. Now, we’re calling it by a different handle, but that’s no guarantee that it won’t cause conflicts. In fact, I’m pretty sure this will cause no end of problems with some plugins. The right thing to do would be this:

    function my_scripts_method() {
        wp_deregister_script( 'jquery' );
        wp_register_script( 'jquery', plugins_url('js/jquery-1.4.3.min.js',__FILE__) );
        wp_enqueue_script( 'jquery' );
    }
    add_action('wp_enqueue_scripts', 'my_scripts_method');

    Now we’re making sure we won’t have conflicts by re-registering jquery, replacing it, and moving on.

    A lot of people would actually recommend using Google instead, as it takes the responsibility off you for including a file you don’t ‘control.’ Also it makes your plugin smaller and load faster.

    function my_scripts_method() {
        wp_deregister_script( 'jquery' );
        wp_register_script( 'jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.4.3/jquery.min.js' );
        wp_enqueue_script( 'jquery' );
    }
    add_action('wp_enqueue_scripts', 'my_scripts_method');
    

    Devo Hat looks like Devo HatGreat! Now we’re done, right? Wrong. As of this writing, WordPress is using jQuery 1.7.2. Now I couldn’t come up with a reason to include an old version of jQuery in WordPress (newer, yes, older, no), so I asked around and none of my friends could either. Using an older version is more likely to cause issues with newer code included in WordPress, as well as plugins which are upgraded to take advantage of the new features. You’re shooting yourself in the foot. The only thing you might be using this for is to include deprecated fictions, and really you need to update your code to fix that instead.

    If the whole point is to load the scripts from Google, though, there’s an awesome plugin for that.