Archive for August 2010

I’m about half done with this, and just wanted to give an update to those people I know who are awaiting it.

I’m ditching the multiple-plugin thing. Too many complaints and too much confusion. Also, the plugin directory and updaters don’t support it well. So 1.0 will have a checkbox area where you can select the pieces you want instead.

It’s using the new Javascript SDK. All this stuff is currently working great.

Login works. Register needs some more work.

Automatic publishing now works for both Fan Pages and Applications! I just worked out how to make Application posts through the Graph API properly. Manual publishing isn’t quite there yet.

Widgets are largely unchanged, but will all be rolled into one sub-module.

Fan box got replaced by the Like box, which is the same thing with a different name. So I’m going to keep calling it the Fan Box in the interface.

The bookmark widget is going away, because it doesn’t work properly anymore anyway.

New widgets for the Facebook Social Plugins are working.

Like and Share will remain unchanged, although the Like now uses the XFBML to do its thing. Doesn’t really make a whole heck of a lot of difference, though.

Comments pull-back from Facebook is possible. I know how to do it. I’m debating whether or not to turn them into “full-fledged” comments or just display them separately.

Comments push *to* Facebook is also possible. Meaning that if somebody leaves a comment using FB and clicks the share checkbox, it will send it to Facebook (no popup) and also include the text of their comment (or an excerpt, at least). This is not done yet, but it’s actually quite easy to add now.

All dependence on the FB-Connect library will be gone. Ditto for their PHP library. I’m writing this with pure calls to the Graph API and XFBML. PHP 5 is still required, and there’s still an activation check for that.

One last thing: Upgrading from old versions to the new one will be a hassle. Things will just stop working properly when you upgrade. Can’t be helped. So I recommend deactivating SFC and all sub-plugins entirely before upgrading, then reactivating it afterwards. There will be a note to this effect on the WP plugins screen.

Shortlink:

Google Apps has always been a bit of a black sheep in the Google account system. If you had an email on a Google Apps system, then it was kinda like a Google account, except not really. Some of the features were the same, some were not. What made it more confusing is Google’s tendency to create a separate Google account using your email address, which meant data sharing across the two was broken and tricky to work with. So most users ended up maintaining two separate Google accounts, which annoyingly had the same email address/username (unless you added GMail to one, in order to get access to Buzz, which then made it forced to have a gmail account as the primary email).

But recently, Google has been making efforts to pull these systems together into a more unified whole. They started off with the multiple account sign in features, which works, but is pretty lame. Having to choose which account you’re on throws all the complication back on the user.

A better way is to simply make all Apps accounts into full-fledged Google accounts. They’ve taken this step and now (some) Google Apps administrators can choose to integrate their Apps account into the larger Google account-o-sphere. I did this the other day, and while it’s taken a bit of effort, I’m now starting to pull all my information over into this new, fully-capable, Google account.

So this post is just a few notes on the process of migrating from two accounts to one, as I do it. Note: This is disorganized and random. I’m just making notes here. Read them if you like.

- Have two browsers open when you’re migrating things. I’ve been using Chrome and Firefox. Sign each one into a different Google account here: https://www.google.com/accounts/ManageAccount

- Don’t use the multi-sign-in thing. It makes things really confusing.

- Change your passwords on one of the accounts. I noticed that when I had the same password on both of them, sometimes I’d log into a Google property and it would log me in using the wrong account. With different passwords, that stopped happening and I started getting in on the correct account, based on the email I gave, every time. Basically, it appears that the migration process changes your old GMail-account which was tied to your old non-gmail based address to use an account on gtempaccount.com. Using this, it can still recognize your old email address as being on that account, if the password fits. By having different passwords, it can’t do that and thus you get the correct account for the email you’re signing in as.

- YouTube accounts can be delinked from one Google account and relinked to the other Google account. Check the account settings page on YouTube. Yes, I know they say YouTube won’t work on the Apps accounts. It does. I did it.

- Google Voice accounts *CAN* be transferred to non-gmail based Google accounts. This link works: http://spreadsheets.google.com/viewform?formkey=cjlWRDFTWERkZEIxUzVjSmNsN0ExU1E6MA . Even though it says there that it will not work with a Google Apps account, it *will* work if you’ve migrated your Apps accounts into the general system. I did it, and if you do it, make a note saying that the account migration had been done. They transferred it over just fine. Took about an hour for me. Probably will take longer for them to get to you.

- Chrome Sync works on the new accounts, just go into Chrome, disconnect the sync, then reconnect it to the new account.

- If you use Reader, you can export your subscriptions from one as an OPML file, then reimport them to the new Reader account. Although your followers *seem* to transfer, there may be an issue there as I always get errors when commenting on shared posts.

- Google Talk works fine, but you need to sign it out then back in to the new account.

- AdSense can’t migrate. You’ll have to close your old AdSense account and create a new one on the new account.

- Strangely enough, somehow in this process, Wave got added to my Google Apps account. Which is weird, as I thought they killed that. Not that it matters or anything, just thought it was unusual.

- One HUGE benefit: The new Google Chat. A few days ago, they rolled out “call by phone” to Google Chat. You can call anywhere in North America for free through Google Chat on your GMail. While they didn’t roll this out to normal Google Apps accounts (yet), they did roll it out to migrated Google Apps accounts. I got it in my GMail today and used it to talk to my mom. She said the voice quality was fine. Afterwards, I signed into Google Voice and lo and behold, my GChat was available as a Google Voice forwarding account! So now if I’m on GMail (which I always am) and you call my Google Voice number, I can answer through the computer. How awesome is that?

This is not final. I will be updating this post as needed. I’m just posting it now so that people can benefit from it now.

Shortlink:

If you don’t get immediate responses from me for the next few days, that’s probably because I’m not here. As you can tell from my new sidebar badge, I’ll be in Savannah, GA for WordCamp Savannah 2010. I’ll be around the SCAD River Club all of Saturday and Sunday, and also Friday (if they’ll let me hang out, I didn’t sign up for that). Looks like it’s going to be awesome, Jane has really pulled it together nicely.

I will be trying though, and the hotel claims to have internet, but this is going to be my first real road-trip for a WordCamp, so I’ll be mostly unavailable for quick answers like I know a lot of people are used to getting from me. Don’t worry, I will get to you. Eventually.

If you’re coming to Savannah, please make it a point to come and ask me anything you like. I’m looking forward to meeting people and getting to know the community better. My only meat-space connection with the WordPress community has actually been meeting (and working for) Matt, and he’s clearly a biased source. ;)

So enjoy your week, everybody! I know I will!

And I WILL be having dinner at the Crab Shack. This is a requirement.

Shortlink:

A while back, I wrote a post detailing why it was a bad idea to generate Javascripts using PHP in WordPress plugins. In that post, I mentioned a couple of better ways to do it.

At the time, I didn’t know about the third, and best way, to accomplish this. Mike’s comment over there reminded me of it. WordPress has it built in.

If you already know about wp_localize_script, you can stop reading now.

The wp_localize_script function was made in order to allow for WordPress translations to be able to also translate some of the JS files inside WordPress. Thus the name “localize”. The way it works is to load up the translated versions of text from the translation files and then include them into the resulting HTML output as a Javascript object. The scripts then use that object to produce any text output they need to produce.

Turns out that’s really similar to our goal of sending arbitrary parameters from WordPress to be used by Javascript code.

How to do it:

1. Make your script static (instead of generated) and enqueue your script as per normal. Example:

wp_enqueue_script('my-script','/path/to/whatever.js',…);

No real changes there. You’ll have to come back and modify your script to use these parameters it’s getting passed, but we’ll get to that in a minute.

2. Build an array of your parameters that you want to send to the script.

$params = array(
  'foo' => 'bar',
  'setting' => 123,
);

Note that my parameters are simple examples, but this is PHP code. You can get your parameters however you like. Such as get_option to pull them from the database, perhaps.

3. Call wp_localize_script and give your parameters a unique name.

wp_localize_script( 'my-script', 'MyScriptParams', $params );

What this will do is make WordPress output an inline script with your parameters (properly encoded) just before the enqueue outputs the script tag that loads your script in the first place. So then those parameters will be available to your script as an instance of an object with “MyScriptParams” (from my example).

This means that Javascript code can now reference them as attributes of the name you gave.

So, step 4. Modify your script to use those parameters. In my example, I used “MyScriptParams” and the parameter names are “foo” and “setting”. In my Javascript code I can use them as “MyScriptParams.foo” and “MyScriptParams.setting”.

Much cleaner. One static and unchanging JS file to cache. Parameters get put into your HTML itself as a one-liner. You can deal with the parameters using a normal PHP array before passing them over. No need to screw around with generating Javascript from PHP or looking for wp-load or even messing with tricky actions.

Perfect.

Shortlink:

So I added the new Tweet button to Simple Twitter Connect yesterday, and was going through the documentation they provided for it. One thing I noticed was a mention of the “count API”.

Now, Twitter says that the count API is private, but come on.. Seriously? You’re sending count information to every Tweet button being displayed anywhere, how private can that really be?

Turns out it’s not private at all. It’s just hidden.

To get the tweet count for any URL, simply do a GET for this:

http://urls.api.twitter.com/1/urls/count.json?url=URL-TO-GET-COUNT-FOR

What you’ll get back will look like this:

twttr.receiveCount({"count":123,"url":"URL-TO-GET-COUNT-FOR"})

Some of you may recognize that as a JSON callback. Basically, they’re using part of their @anywhere system to receive the count and update the button accordingly. Not surprising, the whole tweet button is built on top of the anywhere code. But it’s kinda useless to us in this format, since we need to be able to define our callback appropriately instead of using theirs. No worries, just add a callback parameter yourself:

http://urls.api.twitter.com/1/urls/count.json?url=URL-TO-GET-COUNT-FOR&callback=bob

bob({"count":123,"url":"URL-TO-GET-COUNT-FOR"})

Obviously, they didn’t release this information because they’re concerned about scaling, and probably rightfully so. Still, if you want that count, you can get it. Just don’t abuse it.

Shortlink:

While this isn’t affecting a lot of people now, it will be in the future. Especially if you use well-supported themes.

Somewhere in version 2.8 or 2.9, WordPress started supporting Theme Updates. In the same way that it supports automatic plugin updates from the plugin repository, a theme developer can now make updates to their theme in the themes repository, and you can upgrade it directly from the WordPress interface.

This is a great thing. Theme developers can fix problems, add features, and have it easy for the users to get those changes right away.

Unfortunately, the theme has historically been the user’s playground. Themes are frequently modified by the user directly. Whether it be for looks or for adding code to be used by plugins or whatever, the theme you’re using is very probably not the theme you downloaded. So upgrading will blow away your changes. Thus, most people are disinclined to upgrade their themes.

The way to avoid this is with a child theme. Child themes derive from another theme, called the parent theme. A child theme, by default, looks exactly like the parent. Then you make your changes to the child, and those changes are used on the site. The parent remains untouched. So, when you upgrade the parent theme, the changes you made don’t go anywhere. They stay right where they are.

So let’s dive right in:

How to Make a Child Theme

First, obviously, install the parent theme. Take note of what directory name it goes into. You can find this on the Theme’s screen, it will tell you what directory each theme is in. The new default theme in 3.0 is “twentyten”. So let’s use that one as our parent.

Now, create a new directory in your /wp-content/themes directory. This is where we’ll put our child theme. Let’s call it “mytheme”.

In the mytheme directory, create a new style.css file. Put this in it:

/*
Theme Name: My Theme
Template: twentyten
*/
@import url('../twentyten/style.css');

Finally, load up WordPress and go activate your new “My Theme” theme. You’ll notice that WordPress tells you both what directory your child theme is in and what directory its parent is located in.

Now you’re running on a child theme. It doesn’t have any changes in it, so it looks exactly like the twentyten theme does, but still, we’re running it.

How to Change Things

Let’s say I wanted to change the color of the post titles to, say, green. A silly change, but it illustrates the point.

Normally, I’d go edit the theme, find wherever the color of the text is defined, and change it or add to it to make the titles change in the way I want. In this case, I do the same thing, but I modify the child theme, and I do it in a way that overrides the specificity of the parent’s CSS code.

To do this, I add this code to mytheme’s style.css file:

#content h2.entry-title a {
   color: green;
}

Why that change? Well, I looked at the parent theme and found that “#content .entry-title a” was what it used to define the color of the post title links. To override that, I need to be more specific.

Specificity is a difficult concept for some people, but basically it breaks down to this: When the browser is parsing the CSS, more specific rules take precedence over less specific rules.

In my case I needed to be more specific than “#content .entry-title a“. By adding the h2 to the .entry-title rule, I achieve that because h2.entry-title only will affect h2′s with the entry-title class, while just .entry-title can affect any tag on the page with that class.

The fact that only the h2′s on my page have .entry-title is irrelevant. The HTML doesn’t actually matter in regards to specificity. A rule is more specific based on what it can affect, not on what it actually affects.

So by making my rule more specific, I can override the color of those title’s in my own CSS file separately, and without changing anything about the parent theme.

Overriding Templates

Child themes are not limited to overriding only styling, although in many cases that may be the only customization you need. Best to stick with the rule of the minimum; try to make the most minimal change you can make to accomplish what you want to accomplish. But if you do want to change the way some of the templates work, you can do that too.

All you have to do is to copy the specific template file you want to alter from the parent theme into the child theme’s directory, then make your changes. The way WordPress works is when it looks for some template file, it looks in the child theme first, then it goes to the parent theme if the file it wants isn’t there.

Note that you’re not limited to overriding existing files in the parent. The entire Template Hierarchy applies to child themes too, so if you want to define a category.php file for Category Templates, and the parent theme doesn’t have that file, then you can create a new one in your child and it will be used. You will probably still want to start out with some existing template from the parent though, so look at the Template Hierarchy to see which template the parent is using for your case. The index.php is the usual suspect in these cases, so you can probably just copy that to the child theme and rename it to the template file you want it to be.

Overriding Functions

One exception to the overriding mechanism of child themes has to do with the functions.php file. In a child theme situation, both functions.php files from both themes are loaded. This is necessary because elements of your parent theme might require pieces of the functions.php file to be loaded. This can make overriding functions in the parent theme tricky unless it’s written to allow you to do just that.

The key to this is that the functions.php file of the child theme is loaded first. So if the parent theme is written in a manner WordPress calls “pluggable“, then you can override those functions.

In the twentyten theme’s functions.php file, several of the functions are defined like this:

if ( ! function_exists( 'twentyten_admin_header_style' ) ) :
function twentyten_admin_header_style() {
...
}
endif;

That is a pluggable function. Basically, before it defines the function, it checks to see if the function is already defined. If the parent theme uses this mechanism, then a child theme can override this function by simply defining a function of the same name first. So all you have to do to change it is to copy the function into your child’s functions.php file and make your changes. When the parent theme loads, it will see that you already defined the function and continue on.

Another way to override things is through the normal WordPress action and filter hook mechanisms. If a theme’s functions.php file uses those, then you can simply add your own hooked functions with different names. However, because the child’s functions.php file loads first, it can’t actually unhook things defined by the parent theme.

The way to get around this is to use the after_setup_theme action hook. This action is called immediately after both functions.php files are loaded.

For example, if I look at the twentyten theme, I’ll find this:

function twentyten_excerpt_length( $length ) {
	return 40;
}
add_filter( 'excerpt_length', 'twentyten_excerpt_length' );

I don’t want that, I want my excerpts to be 55 words instead. So I add this to my functions.php file:

function my_excerpt_length( $length ) {
	return 55;
}
add_filter( 'excerpt_length', 'my_excerpt_length' );

Whoops! It doesn’t work. Why not? Because I didn’t remove twentyten’s hook, and its filter is overriding mine. So I have to add this too:

function my_undo_hooks( $length ) {
	remove_filter( 'excerpt_length', 'twentyten_excerpt_length' );
}
add_action( 'after_setup_theme', 'my_undo_hooks' );

And then it works. I’ve added my filter, and removed the one in twentyten. Voila.

Programmer Note

In a WordPress theme you’ll often find references to “stylesheet_uri” and “stylesheet_dir”. You’ll also find references to “template_uri” and “template_dir”. Normally, these are the same thing. In a child theme case, they’re not. Stylesheet refers to the child theme. Template refers to the parent theme. This is an important distinction that you’ll want to make when creating your theme. You should probably use stylesheet in most cases, except for when you need to specifically refer to the parent (for image URL creation and such).

Conclusion

Child themes are a very good way to survive theme upgrades, and if you’re using a well supported theme, these are likely to become more common. It’s still perfectly safe to modify your theme directly (except for twentyten! Normal WP upgrades overwrite twentyten), but it’s always a good idea to keep your customizations separate. They’re a lot easier to manage that way.

Shortlink: