Otto on WordPress

Google came out with an experimental specification for websites to provide “hints” on forms, to allow things like autocomplete to work better and be more standardized. Seems useful.

Here’s a quick plugin snippet you can use to make your comments form use this specification. Only Chrome 15 and up is using this at the moment, but in the long run I think most browsers will be implementing something similar to this, since filling out forms is just one of those endless pieces of drudgery that we could all stand to do away with.

Note that your theme will need to be using the comment_form() function call for this to work, otherwise you’ll just have to edit your comment form in the theme manually.

<?php
/*
Plugin Name: Add X-Autocomplete Fields to Comment Form
*/
add_filter('comment_form_default_fields','add_x_autocompletetype');
function add_x_autocompletetype($fields) {
	$fields['author'] = str_replace('<input', '<input x-autocompletetype="name-full"', $fields['author']);
	$fields['email'] = str_replace('<input', '<input x-autocompletetype="email"', $fields['email']);
	return $fields;
}

Simple little bit of code, really. Should work with any theme using the normal comment_form() function call.

If you read “how-to” stuff for WordPress sites around the web, then you frequently run across what many people like to call “snippets”. Short bits of code or functions to do various things. I myself post snippets frequently, usually made up on the fly to solve somebody’s specific problem.

One question I get a fair amount is “where do I add this code?”

The usual answer to this for a lot of people is “in the theme’s functions.php file”. This is a quick solution, but it is often a problematic one.

The reason this has become the more or less go-to place to add these snippets is because it’s complicated to explain to a newbie how to make a plugin and activate it, or to point out the problems with modifying core code, or plugin code. Saying to look for a specific file in their theme, on the other hand, is quick and easy, and until recently theme upgrades have been fairly rare.

However, as themes get upgrades, it becomes more and more incorrect to tell people to modify them directly. And telling people how to create child themes is complex, even if it’s easy to do.

So I’d like to start a new trend, and recommend that people start making Site-Specific Plugins. Most people who run WP sites on a serious level do this in some way already, but if you make it sorta-standard practice, then it’ll make things simpler all around.

How to create a Site-Specific Plugin

1. Create a new directory in the plugins directory. Name it after the site in some fashion. For example, /wp-content/plugins/example.com or something like that.

2. Create a new php file in that directory. Name is dealer’s choice.

3. Put this in the file:

<?php
/*
Plugin Name: Site Plugin for example.com
Description: Site specific code changes for example.com
*/

4. Finally, go activate your new blank plugin on the site.

Now you have a simple and specific place to add snippets. It will survive upgrades of any sort, and you can edit it to add new code on an as needed basis. What’s more, it’s kinda sorta break-proof. If the user uses the built-in plugin editor to edit it, and they add code that breaks the site, then the editor detects that on saving the code and deactivates the plugin, preventing the “white screen of death” for their site.

This is a much better way to use “snippets” than the theme’s functions.php file, and we should really use it more often in our replies to users.

My post about how to customize WordPress images with tricks like greyscale and such got me lots of feedback, so I figured I might as well turn it into a plugin.

The ImageFX plugin allows you to customize the image sizes from WordPress or custom ones for your theme, by applying filters to them.

The way it works is basically identical to my original post on the topic, only it allows the filters to be defined on a per-image-size level. It also allows the addition of a “slug” to be appended to the image filename, which is useful for cases where you want to have two images at the same size, but with different filters.

Since it was easy to do, I went ahead and created several other simple image filters that you can use for your images:

• Greyscale (black and white)
• Sepia tone (old-timey!)
• Colorize with red, yellow, green, blue, or purple
• Photonegative
• Emboss
• Brighten
• Greyscale except red, green, or blue (classy!)

Here’s some examples. This a pic of me, Nacin, Rose, and Matt at WordCamp San Francisco. I ran it through the sepia, blue colorize, and grey-except-red filters.

These are some of the default filters included, but since I could, I went ahead and made it easily expandable too. All you have to do to define a filter is to create a function to do the image filtering you want, then call the imagefx_register_filter() function to add it.

To implement your own custom filter, you can do it like this:

imagefx_register_filter('custom-name','my_custom_filter');
function my_custom_filter(&$image) {
 // modify the $image here as you see fit
}

Note that the $image is passed by reference, so you don’t have to return it. This is because the $image resource takes up a lot of memory, so to save on memory usage, you are manipulating it in place, sort of thing.

You can use any of the image functions in PHP to change the image however you like. The filters I’ve implemented are mostly pretty simple. You can see them all in the filters.php file, in the plugin.

Caveats: The plugin will only filter JPG images, to avoid the overhead of recompressing PNGs and to avoid breaking animated GIF files. Also note that I haven’t tested these filters extensively. They’re only a starting point, sort of thing. I spent all of about 20 minutes writing them, so don’t expect miracles.

You can download version 0.1 of the plugin from the WordPress plugin directory: http://wordpress.org/extend/plugins/imagefx/

Enjoy!

Facebook recently made a breaking change to the developer process, which makes it impossible for new applications to get the correct API keys. Since this essentially broke all previous versions of SFC, I went ahead and pushed the beta version public. It’s still unfinished, but Facebook didn’t really give me a lot of choice.

So, this is a quick walkthrough of some of the new features of SFC 1.0.

Upgrade Process

The upgrade process is slightly more involved for this one. It is recommended that you deactivate the old SFC plugins before upgrading. Why? Well, if you don’t, you’ll get a bunch of errors when visiting the Plugins screen later, saying that all the old SFC plugins either don’t exist or have an invalid header. These errors are normal, because of the next feature:

One plugin only

No more sub-plugins

Simple Facebook Connect is now a single plugin, with modular features. If you examine the plugins screen, you’ll find only one entry: Simple Facebook Connect.

The many-plugins-in-one was a useful experiment, IMO, and I still think it’s a better way to do things. But many people find it confusing, and some have disagreed with the notion. A lack of useful core support for plugin dependencies and user feedback convinced me to switch it up. So now, SFC is one plugin. But it’s still modular!

Sub-module selections

As you can see in the image, you can still turn on and off pieces of the plugin. Why have a piece running and consuming valuable resources if you’re not using it? Turning a module off completely disables it in the code. And the core of SFC itself is still written modularly, for maximum performance (since integrating Facebook itself is such a drag on performance for a site to begin with).

Support for new Facebook code

Over a year ago, Facebook stopped supporting the original Facebook Connect libraries. This was a major problem for sites, however the old code still worked. So as time went on, and the old Connect libraries started to degrade and become less and less useful, SFC was rewritten from the ground up to use all the newer supported libraries. Facebook’s JS SDK is used. FB’s Graph API is used. The old Facebook REST Platform code is completely gone, as are the older incompatible Facebook Connect libraries. OpenGraph meta tags (including embed info for images and video) are inserted into the entire site, completely automatically, allowing Facebook to see the content of your site and act accordingly.

Many of the plugins themselves have been rewritten fairly extensively as well, but with this comes some removal of older code.

Faux Share button settings

The Share button is gone. It was previously implemented using the older Connect libraries, but with the newer libraries from Facebook, it’s been completely removed. There was just no good way to retain it, Facebook has simply dropped any and all support for it. So, in it’s place (because it was so handy) is a modified Like button, which can still look sorta like the old Share button. The SFC module is still named Share, for ease of transition. The Like button itself is still around too, so you can use both Like and Share to get two Like buttons on the same post, perhaps for different placement.

The Bookmark widget is gone. It simply isn’t supported anymore, and didn’t work anyway.

The Find on Facebook widget is gone. This didn’t do really anything special to begin with, other than place the Find Us image into a widget, with a link to the Facebook Page. The image it once used is still included in the plugin, for people that want to do this themselves via a text widget.

The Connect widget is gone, but may make a return in the next version, as soon as some bugs are sorted out.

The Upcoming Events widget is gone. It rarely worked properly to begin with, and the newer XFBML libraries doesn’t have support for it anymore. A alternate approach to this may make it back into the next version.

All the remaining widgets have been combined into a single module for use on the widgets screen. In addition, most of them still have a way to access them directly, such as from a function call in a theme.

Publisher settings

The Publisher has been simplified greatly. For one, auto-publishing now works even for Applications! The confusing permissions dialogs have been reduced to one. Colored indicators have been added, showing when the plugin has the necessary “tokens” from Facebook in order to be able to publish properly. The manual publishing functionality is still on the edit post screens too. And for those people using the auto-publish, a new system for pulling Facebook comments on their published posts back into the blog has been implemented.

For those who wanted it, Custom Post Type support has been added to the publisher as well. Any CPT marked as “public” gets shared like everything else.

Register screen

The Register system has been completely rewritten to take advantage of Facebook’s new register plugin functionality. It can handle standalone registrations, or registrations using Facebook information. It even adds a Facebook created captcha to prevent spam registrations.

Login has been improved. One of the most common complaints was “What does ‘User not recognized’ mean?” This should be severely reduced now, since the Login module will auto-detect existing users and automatically connect their local WP accounts with their FB accounts, when they try to login. This follows Facebook’s own Registration Flow Models for connecting users to sites.

The Comment system has been improved. The share-after-comment system now happens in the background, no extra popups for users to have to click on. The whole system is now using the Graph API, so no more strange javascript errors causing weirdness. Although there is still some javascript to display the user their picture and info after logging in, so it still has that same look and feel.

There’s a lot more too. I’ll be updating this post with new stuff soon!

Another new thing in SFC 1.0 is the new Login and Registration mechanism. The login mechanism in the older SFC worked, but it was slightly buggy and didn’t work very well. The new mechanism works quite well indeed.

Login screen with Facebook popup

For starters, it will auto-connect existing accounts to Facebook, based on matching email addresses. Just Login with your FB credentials, and if you’re using the same email in both sites, then it auto logs you in based on that. Your account gets automatically connected to your Facebook Profile, and this appears in the “Howdy” dropdown as well as on your Profile.

Howdy dropdown

This may seem insecure to some, however the mechanism behind the scenes is that Facebook sets a cookie in your browser, and cryptographically signs it. Your Application Secret is the key used to decode this signature, thus proving it came from your Facebook application, and eliminating the risk of having users log in without your valid credentials.

However, this does point out something everybody should know: Secrets are supposed to be secret. So keep your Facebook Application Secret a real secret. This applies anytime you’re setting up interconnected web applications. Secrets are called that for a reason.

Registration Flow

In order to integrate Login and Registration using Facebook, Facebook came up with what is essentially a flow diagram explaining the steps an app should use to login and register somebody to a third party site.

Facebook's rather complex registration flow diagram

This rather complex looking flowchart shows how a site which has its own login and registration mechanism can implenent Facebook. I’ve followed this chart as best as possible, and thanks to FB’s Registration plugin, it works quite well now. Here’s how it breaks down.

For existing users:

1. You click the Login button.
2. You login to Facebook if needed.
3. If your email on Facebook matches your email in WordPress, you’re logged in and your account is automatically connected.
4. If your email doesn’t match, then you can log in normally with WordPress instead, and connect your account manually, on the Users->Your Profile screen.

For new users:

1. You click the Login button.
2. You login to Facebook if needed.
3. If no account can be found for you from the login process, you get redirected to the Register page.
4. There the Facebook register plugin shows up and lets you register for the WordPress site, using your Facebook credentials. All it asks for is a username and to solve a CAPTCHA (to prevent spam registrations).
5. You get a new WordPress account, already connected to Facebook for you. It even emails you a password.

Registration screen

Some have expressed concern that Facebook seems required for registration. This is not actually the case, because after all, not everybody uses Facebook. One of the nice things about the FB Register plugin is that it has different methods for Facebook connected users vs. non-Facebook connected users. Both types of users can register for the site. Facebook users get some advantages like having their account automatically connected and not having to type in an email address, but the basic process is the same.

For new users not using Facebook:

1. You click the Register link.
2. The Facebook register plugin shows up and lets you register for the WordPress site. It will ask for a username and your email address, as per the normal registration process. It does have the CAPTCHA too, and tells you that you can login using Facebook as well, if you want.
3. You get a new WordPress account, and it emails you a password.

Registration screen

And after logging in and having it recognize you, the user will be automatically connected to their account on their Profile page.

Facebook Connection shown on the Profile Page

If you want to try the new version now, I’ve finally moved it into the normal “trunk” directory on the repository at WordPress.org, so you can download the ZIP file of the plugin here:
http://downloads.wordpress.org/plugin/simple-facebook-connect.zip

Release date: soon. Real soon now.

First, WordPress plugin authors: Please don’t do this.

if ( isset($_GET['resource']) && !empty($_GET['resource']) ) {
	$resources = array(
		'icon1.png' => '... base 64 encoded code ...',
		'icon2.png' => '... base 64 encoded code ...',
		);

	if ( array_key_exists($_GET['resource'], $resources) ) {
		$content = base64_decode($resources[ $_GET['resource'] ]);
                header('Content-Length: '.strlen($content));
                header('Content-Type: image/png');
            	echo $content;
		exit;
	}
}

I’ve seen a few different versions of this, and while the idea is nice, this is really the wrong way to go about it.

The idea is to include small icons or images in the plugin file itself, instead of as separate files. This sort of code then lets you reference them by calling a URL of ?resource=icon1.png or whatever. When that resource variable is detected, the plugin kicks in and serves up the image instead of the site.

Advantages to this sort of thing:

• No need for extra icon files

Disadvantages to this sort of thing:

• Now every http request to get an icon file on your admin page results in loading up the WordPress code, causing extra CPU usage.

Here’s a better way. It’s called the Data URI.

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />

Here’s that code in action, right here:

Why this is better:

• Same benefits as before, no need for extra icon files
• No extra CPU load from loading WordPress to get that icon file
• No extra HTTP requests at all, in fact, since the data for the tiny icon is contained right there in the code

Disadvantage:

• Doesn’t work in IE7. You can work around this by detecting IE7 and serving up the image separately, if you really want. Or you can just ignore it like most people do. Seriously. IE7 is insecure (link, link) and nobody should be using it, anywhere. WordPress itself will probably drop IE7 support in the admin in the next couple of versions.

So use Data URIs for small images (under 32KB in size). They’re fast and easy. They’re an idea whose time has come.

Google rolled out their +1 button today. So I added it here. You’ll find it below all the posts. Try it out.

Here’s the simple-stupid plugin I wrote to do it. While you can just edit your theme, I like making these sort of things into plugins. That way, I can turn them off at will, and I know exactly where to go to change them without having to dive into my theme code. Also, if I change themes, the code still works on the new theme.

<?php
/*
Plugin Name: Otto's Google +1 Button
Description: Add a +1 button after the content.
Author: Otto
Version: 999
*/

add_filter('the_content', 'google_plusone');

function google_plusone($content) {
	$content = $content.'<div class="plusone"><g:plusone size="tall" href="'.get_permalink().'"></g:plusone></div>';
	return $content;
}

add_action ('wp_enqueue_scripts','google_plusone_script');

function google_plusone_script() {
	wp_enqueue_script('google-plusone', 'https://apis.google.com/js/plusone.js', array(), null);
}

I wrapped the button in a div so that I could style it. In my particular case, I’m floating it right and giving it a margin, same as the Twitter and Facebook plugins. One day, I’ll make all these little Google plugins more generic and configurable, and roll them into a Simple Google Connect plugin.

One thing I don’t like is that the +1 button only works for people who are logged into a GMail account. Sorry Google Apps users, you’re out of luck. Complain to Google until they fix it.

If you want to add more parameters to the plugin and reconfigure it, you can find out about the available parameters here: http://code.google.com/apis/+1button/#configuration

I got tired of waiting for a “proper” YOURLS WordPress plugin to come out, so I did it myself. Hey, I’ve got other stuff to do, and I needed a working shortlink solution.

Basically, this is the “YOURLS: WordPress to Twitter” plugin, with all the Twitter bits removed.

While I was in there, I also fixed the password saving bug that I kept having in Chrome (just cut out the submit button JS), switched it to eliminate the Pear_JSON package entirely (WordPress has JSON support built in already), and did some other minor things. I’m sure I missed some bits, but for the most part it was really just a hack and slash job. Eliminated about 30% of the plugin’s main code and all the ancillary Twitter libraries.

On a side note, this sort of thing only reinforces something I’ve said before: Plugins should only try to do one thing, and to do it well. Trying to have a twitter solution in this plugin when I didn’t want to use that bit at all basically just made it stop doing the shortlinks correctly. That’s a real problem when it’s really a shortlink plugin to begin with. I already had a really good twitter solution, trying to have all this extra crap in there just made it not work properly.

If I had more time, I’d also remove all the JS stuff on the settings page too. That’s not really necessary when you only have a few fields to enter. But I guess it works, sort of. Whatever. Not important.

Anyway, here you go. I won’t be putting this in the plugins repository, since it’s not really my code. But I am posting it here in case it helps anybody. And if Ozh changes his plugin to eliminate the Twitter stuff (or to at least make it optional without impacting functionality), then it would be worth switching to that in the future. I won’t be supporting this plugin anytime soon.

YOURLS – WordPress (no Twitter)

Edit: Note that I did this mainly because I wanted to use my own Simple Twitter Connect instead for posting items to Twitter. That works fine and uses the shortlink from this plugin fine. But the extra Twitter stuff in the original plugin interfered with it, and there was no good way to disable that stuff short of editing the plugin. I’m a fan of not editing other people’s plugins, but in this case there really wasn’t a lot of choice. YOURLS is a good system and I like using it, I just wish the WP plugin for it wasn’t trying to do so much. Just so you know.

Sorry for the several updates over the last day. Somebody pointed out that I hadn’t pushed a new version of SFC in several months, and that the fixes in trunk had gotten a ways ahead of those in the released version. Unfortunately, I didn’t actually go and test properly, so versions 0.22 and 0.23 had minor but critical bugs in them. Version 0.24 should push shortly with the fixes for those bugs as well as the enhancements over the last several months.

A short list of the changes/fixes:

• Thanks to Burak Tuyan, the whole plugin is now more i18n capable, for people who want to translate it.
• Added an sfc_img_exclude filter, to let others add their own image classes to exclude from the automatic image finder for share and publish and such.
• The sfc_like_button() functions now supports a url parameter to add a like button to a specific URL.
• A couple of patches by Jamie Zawinski: Publish now sends up to 1000 chars from the post to Facebook.
• Also thanks to jwz, publish now gets images correctly in more cases.
• If you enable login avatars (by uncommenting that code), it will show them for comments now too.
• Eliminated deprecated calls to Facebook functions (xid and register users calls)
• Custom Post Type support for automatic publishing (any CPT with public=>true will get auto-published).
• Custom Post Type support for manual publishing (any CPT with public=>true will show the meta box in its edit screen).
• Contextual help added to SFC Settings page.
• Improved error messages
• Numerous other minor optimizations and bugfixes

Version 1.0, which will ditch the old Connect code entirely, isn’t quite ready yet. The new registration stuff will be in there though, eventually. It will probably be after I get back from the core developers meeting though. Sorry for the excessive delay on that. I know lots of people want it, I never seem to have the time. I’ll try to find the time and finish it up soon. Really.

Note to users: If you got the “Breaking change: API deprecations” email from Facebook today, then you are probably using the SFC-Login plugin, or have at some point. Version 0.24 removes the code they are deprecating from the SFC-Login plugin. So upgrade and you’ll be fine. However, note that SFC is no longer compatible with WordPress versions prior to 3.0. Upgrade WordPress to 3.0 or later before upgrading SFC.

Note to international users: And with all that, there’s still a bug. If you’re seeing weird characters in your FB Published posts, edit the sfc-publish.php file. On line 179 you’ll find return utf8_encode($text);. Change it to return $text; to fix the problem with the double encoded characters. The next version will have this fix as well, but I didn’t think it was major enough to push a whole new version right away.

Update: Forget this plugin. Go install Jetpack instead.

WordPress.com rolled out a nifty new feature called “Gravatar Hovercards” today. Basically it changes gravatar images into popups showing more info when the user hovers over them. In the comments, Andy Peatling mentioned bringing them to self-hosted WordPress blogs soon.

I didn’t feel like waiting.

<?php
/*
Plugin Name: Gravatar Hovercards
*/
function gravatar_hovercards() {
	wp_enqueue_script( 'gprofiles', 'http://s.gravatar.com/js/gprofiles.js', array( 'jquery' ), 'e', true );
}
add_action('wp_enqueue_scripts','gravatar_hovercards');

This is not official.
It’s not supported.
It may not even work for you.
It certainly won’t work if they change things.

Still, this blog is about fun things I do with WordPress, so I saw no reason not to post it. I expect they’ll come out with their own plugin soon, but I’d be rather surprised if it’s much more than this. Maybe some extra options or something. I dunno. Switch to that script when it comes out.

But for those people who like experimenting and playing with WordPress on the edge, here you go.

And for you Javascript inclined people, take a look at their code. It’s got some tricks in it that are pretty neat.

Enjoy.

(Updated as per several comments)