Archive for 2011

« Previous Entries
Next Entries »

October 8, 2011, 12:43 pm

I’ve been hosting my sites on GoDaddy for years, despite everybody saying that they suck and so forth. I’ve even defended them. Their interface is crap, but it’s not terrible once you get used to it. It works well enough. Their shared servers are indeed overloaded, but with a little super-caching they tended to work alright. Their new cloud hosting service is definitely faster.

But if there’s one thing I can not stand, it’s censorship.

I recently discovered that a couple of old posts of mine about decoding code used by hackers were no longer loading up. Everything else worked, but not those posts. I couldn’t even pull them up in the WordPress post editor.

After some trial and error and back and forth, I discovered that any HTTP or FTP request that contains the string “eval(base 64_decode(” or similar variants, is blocked. FTP just stops dead, as does HTTP requests, with a continual spinning loading icon. Apparently they have some form of filtering in the TCP stack somewhere that just stops those connections dead in their tracks.

(BTW, the irony here is thick. GoDaddy’s malicious code scanner was blocking my “Scanning for Malicious Code is Pointless” post.)

GoDaddy… guys, I loved your service in the past, but I have to tell you that this is a *shit* approach to security.

After some tweeting back and forth, I found out from the horse’s mouth that this is intentional and cannot be disabled.

And as much as they’d like to claim this isn’t censorship:

Guys, you’re wrong. It is censorship. I wrote that post content, and they’re refusing to serve it over HTTP. You can spin that any way you like, but GoDaddy hosting is now censoring me.

What’s more, this is a *new* problem. Those posts worked fine when I wrote them. What changed? I dunno. I did move to their 4GH hosting, but nowhere did I see in the documentation that they would be intentionally blocking my content.

Anyway, I’ve worked around the problem for now with a plugin to add spaces to the proper places in my HTML content, thus bypassing their filter. However, in the long run, this will not stand. GoDaddy thinks it’s okay to block my personal content. I disagree with them, and no amount of argument is going to make me change my mind on this topic. Blocking my own content from being served is NOT a security measure.

As you might be able to tell, I’m a bit angry.

Therefore, I am now looking for a new hosting service. Some requirements of mine:

  • Traffic-wise I serve about 6000 page views a day, all told. In terms of total HTTP requests, I’d say somewhere around 30,000 or so.
  • Bandwidth tends to be in the 1.5 GB per day range. So, 50 GB per month, say.
  • Obviously, any form of censorship or technical limitations is unacceptable.
  • SSH access is a must-have.
  • I don’t necessarily need dedicated hosting or virtual dedicated hosting, shared is fine if it can handle it.
  • Speed would be nice. GoDaddy has always sucked in terms of time-to-first-byte. Their cloud hosting made it better, but not great.
  • MySQL Databases. I need at least 10 of them.

So, not too heavy requirements, I’d say.

I’ve heard suggestions for DreamHost in the past, and A Small Orange has always gotten favorable reviews from people I’ve talked to, but what the heck, might as well solicit the opinions of the internets in general, yeah?

Suggestions are happily accepted. If you can provide estimated pricing or links, I’d love to take a look at them. 🙂

Shortlink:
Tags: , ,
Category: Other, Rants  |  62 Comments

October 6, 2011, 4:18 pm

Note: Post has been updated for 3.3 beta 2

WordPress plugin and theme authors could get something interesting in WordPress 3.3: a somewhat more comprehensive help screen system.

This is actually just a small part of a more long term makeover involving unifying the admin screen code base, but it’s pretty cool nevertheless. Backward compatibility is sorta fuzzy on parts of it at the moment, but not a lot of authors used these functions previously anyway, from what I can tell.

Anyway, I spent an entertaining half hour reworking the help dropdown for my SFC plugin. Here’s what it looks like in 3.3-aortic-dissection right now (note that the look and feel of this will probably change before final):

SFC Help screen in WordPress 3.3

SFC Help screen in WordPress 3.3

As you can see, the dropdown Help menu moved into the Admin bar (along with lots of other stuff), and has some tabs on the left hand side where you can make different topics and such for different parts of the plugin.

The code for this is actually fairly straightforward, albeit in a sideways sort of way…

First we have to look at the code that adds my options page in the first place. This would work with any of the add_*_page functions, so add_theme_page and such works fine too.

add_action('admin_menu', 'sfc_admin_add_page');
function sfc_admin_add_page() {
	global $sfc_options_page;
	$sfc_options_page = add_options_page(__('Simple Facebook Connect', 'sfc'), __('Simple Facebook Connect', 'sfc'), 'manage_options', 'sfc', 'sfc_options_page');
	add_action("load-$sfc_options_page", 'sfc_plugin_help');
}

This makes an options page, and then uses the assigned identifier for that page to hook the load-* action. This means that when our page is loaded, the sfc_plugin_help function will get called.

function sfc_plugin_help() {
	global $sfc_options_page;
	$screen = get_current_screen();
	if ($screen->id != $sfc_options_page)
		return;

Here, we call get_current_screen() to get the current WP_Screen object. The WP_Screen object is new to 3.3, but essentially it encapsulates an admin screen. It’s still under active development, but in the long run, it may make the task of creating admin screens much, much easier.

Anyway, right away, I do one thing and that is to check if the ID of the current screen matches the ID I was given for my options page. If it doesn’t match, then the user isn’t on my screen, and so I return having done nothing at all. This is a sort of belt and suspenders approach, since we shouldn’t be here if load-$sfc_options_page didn’t get called, but it never hurts to be sure.

The next bit is where I add my help screens. Here’s an incomplete sample of that code:

$screen->add_help_tab( array(
	'id'      => 'sfc-base',
	'title'   => __('Connecting to Facebook', 'sfc'),
	'content' => "HTML for help content",
));

$screen->add_help_tab( array(
	'id'      => 'sfc-modules',
	'title'   => __('SFC Modules', 'sfc'),
	'content' => "HTML for help content",
));

$screen->add_help_tab( array(
	'id'      => 'sfc-login',
	'title'   => __('Login and Register', 'sfc'),
	'content' => "HTML for help content",
));

I removed the content for each one to make it clearer. Essentially, I’m just calling the object’s add_help_tab function to add my new tabs to the help screen, one by one. Simple, right?

There’s other useful bits in WP_Screen too, such as adding screen options, adding a right hand side sidebar to the help dropdown, and so forth. I haven’t figured out a use for them yet, but they’re still nice to see.

If you have a complex plugin or theme, might be worth looking into this now. Might reduce your need for end-user support. Maybe. Hard to say. People rarely look at the documentation, but inline help might be worth a shot.

Shortlink:
Tags: , , , , ,
Category: WordPress  |  25 Comments

October 4, 2011, 8:12 pm

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!

Shortlink:
Tags: , , , , , , , , , ,
Category: Code, Other  |  31 Comments

September 27, 2011, 6:13 pm

Seen this a couple of times on various sites and had a couple people ask me on Twitter about it.

Starting October 1st, Facebook will start requiring two new things:

1. OAuth 2.0 support. SFC has this in version 1.1, which will be released shortly (tomorrow, probably).

2. Canvas and Page Tab Applications will require HTTPS/SSL support.

Both of these are true.

However, some people are interpreting that second one to mean that you need to buy an SSL certificate for your own domain to use Facebook Connect type of functionality, like my plugin Simple Facebook Connect provides. This is false.

A “Canvas” application is one that runs on your site, but shows up on http://apps.facebook.com. A “Page Tab” application is similar, but can show up anywhere on the facebook.com website, depending on how it’s written (it makes a “tab” for somebody’s “Page”). Both of those have something in common: Your website’s contents are actually showing up on *.facebook.com.

Simple Facebook Connect does neither of these things. SFC is a way for you to integrate Facebook connection functionality back into your own site. It can publish stories to Facebook, it can let users comment using Facebook, etc., but the whole point of it is to take things from FB and put them on your site. SFC does not enable your site to appear under the *.facebook.com domain name.

You do NOT need an SSL certificate to use SFC, and you will continue to not need one after October 1st.

You will, however, need to upgrade to SFC 1.1. Old versions, including 1.0, will cease to function.

SFC 1.1 will most likely be released tomorrow, and should be a painless upgrade from 1.0. Sorry for the delay.

Shortlink:
Tags: , ,
Category: Other, Rants  |  15 Comments

September 9, 2011, 3:31 pm

Have you ever looked at the add_action function in WordPress? Here it is:

function add_action($tag, $function_to_add, $priority = 10, $accepted_args = 1) {
	return add_filter($tag, $function_to_add, $priority, $accepted_args);
}

I know, right? Some people’s minds just got blown.

What are Filters?

A filter is defined as a function that takes in some kind of input, modifies it, and then returns it. This is an extremely handy little concept that PHP itself uses in a ton of different ways. About half the string functions qualify as a ‘filter’ function.

Look at strrev(). It’s a simple-stupid example. It takes a string as an argument, and then returns the reverse of that string. You could use it as a filter function in WordPress, easily. Like, to reverse all your titles.

add_filter('the_title', 'strrev');

Some filters take more than one argument, but the first argument is always the thing to be modified and returned. PHP adheres to this concept too. Take the substr() function. The first argument is the string, the second and third are the start and optional length values. The returned value is the part of the string you want.

What are Actions?

An action is just a place where you call a function, and you don’t really care what it returns. The function is performing some kind of action just by being called. If you hook a function to the init action, then it runs whenever do_action(‘init’) is called.

Now, some actions have arguments too, but again, there’s still no return value.

So in a sense, a WordPress action is just a filter without the first argument and without a return value.

So why have them both?

Because there is still a conceptual difference between an action and a filter.

Filters filter things. Actions do not. And this is critically important when you’re writing a filter.

A filter function should never, ever, have unexpected side effects.

Take a quick example. Here’s a thread on the WordPress support forums where a person found that using my own SFC plugin in combination with a contact form emailer plugin caused the email from the form to be sent 3-5 times.

Why did it do this? Basically, because the contact form plugin is sending an email inside a filter function.

One of the things SFC does is to build a description meta from the content on the page. It also looks through that content for images and video, in order to build meta information to send to Facebook. In order for this to happen at the right time, the plugin must call the_content filter.

See, what if somebody puts a link to a Flickr picture on their page? In that case, oEmbed will kick in and convert that link into a nice and pretty embedded image. Same for YouTube videos. Or maybe somebody is using a gallery and there’s lots of pictures on the resulting page, but the only thing in the post_content is the gallery shortcode.

In order to get those images from the content, SFC has to do apply_filters(‘the_content’,$post_content). This makes all the other plugins and all the other bits of the system process that $post_content and return the straight HTML. Then it can go and look for images, look for video, even make a pretty 1000 character excerpt to send to Facebook.

But SFC can’t possibly know that doing apply_filters(‘the_content’,…) will cause some other plugin to go and send a freakin’ email. That’s totally unexpected. It’s just trying to filter some content. That would be like calling the strrev() function and having it make a phone call. Totally crazy.

Shortcodes

Shortcodes are a type of filter. They take in content from the shortcode, they return replacement content of some sort. They are filters, by definition. Always, always keep that in mind.

Also keep in mind that shortcodes are supposed to return the replacement content, not just echo it out.

Conclusion

So plugin authors, please, please, I’m begging you, learn this lesson well.

Filters are supposed to filter. Actions are supposed to take action.

When you mix the two up, then you cause pain for the rest of the world trying to interact with your code. My desk is starting to get covered in dents from me repeatedly banging my head into it because of this.

Shortlink:
Tags: , , , ,
Category: Rants, WordPress  |  28 Comments

August 24, 2011, 10:53 am

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!

 

Shortlink:
Tags: , , , , ,
Category: Other  |  79 Comments

August 19, 2011, 12:04 pm

Manipulating images in PHP isn’t all that difficult. WordPress offers some functions to make it easier, and integrating with the WordPress uploader isn’t at all difficult, really.

For example, let’s say your theme needed a black and white version of the images, sized at 100×100, and cropped to that size. This might be suitable for Next/Previous images to use for a gallery, perhaps…

When black and white bears attack...

First, we need to create the image size itself:

add_action('after_setup_theme','themename_bw_size');
function themename_bw_size() {
	add_image_size('themename-bw-image', 100, 100, true);
}

This simple function hooks into the after_setup_theme hook, which is loaded after the theme’s functions.php file is loaded. The function calls add_image_size to add a new image size for the uploader to create for each image that is uploaded into the WordPress media library. The size is specified as 100×100 with hard cropping.

Now that is easy enough, but we need to make the image black and white. To do this, we’ll hook into the wp_generate_attachment_metadata filter. This filter is called after the images have been resized and saved, but before the metadata about those resized images has been added to the attachment post. We’re not actually using this filter as a “filter”, but we need some of the meta data so this is as good a place to hook as any, as long as we remember to return the metadata again.

add_filter('wp_generate_attachment_metadata','themename_bw_filter');
function themename_bw_filter($meta) {
	$file = wp_upload_dir();
	$file = trailingslashit($file['path']).$meta['sizes']['themename-bw-image']['file'];
	list($orig_w, $orig_h, $orig_type) = @getimagesize($file);
	$image = wp_load_image($file);
	imagefilter($image, IMG_FILTER_GRAYSCALE);
	switch ($orig_type) {
		case IMAGETYPE_GIF:
			imagegif( $image, $file );
			break;
		case IMAGETYPE_PNG:
			imagepng( $image, $file );
			break;
		case IMAGETYPE_JPEG:
			imagejpeg( $image, $file );
			break;
	}
	return $meta;
}

Let’s break this down piece by piece:

$file = wp_upload_dir();
$file = trailingslashit($file['path']).$meta['sizes']['themename-bw-image']['file'];

This bit of code gets our upload directory path, makes sure it’s trailing slashed, then appends the filename of our themename-bw-image file to it. Thus, after this is run, $file contains the full local path to the image we want to make black and white.

list($orig_w, $orig_h, $orig_type) = @getimagesize($file);

This line of code simply gets the image size and type into some variables. We really only need the type for later, but this is an easy way to do it.

$image = wp_load_image($file);

The wp_load_image function is a handy one. It reads in the image and returns a PHP image resource for us to work with.

imagefilter($image, IMG_FILTER_GRAYSCALE);

This simply applies the grayscale filter to the image resource, making it black and white.

switch ($orig_type) {
	case IMAGETYPE_GIF:
		imagegif( $image, $file );
		break;
	case IMAGETYPE_PNG:
		imagepng( $image, $file );
		break;
	case IMAGETYPE_JPEG:
		imagejpeg( $image, $file );
		break;
}

Finally, we save the image back to the same file, overwriting the color one with the black and white one.

return $meta;

Since we used a filter, it’s important that we don’t leave out the final return to return the original information we were passed in, so that the metadata gets properly stored in the attachment post. We didn’t actually modify the metadata here, though we could.

Pretty simple to manipulate images in this way. You could apply one of the many other types of filters available, or change all the images into pictures of bears, or whatever you like, really.

Shortlink:
Tags: , , , , , ,
Category: Code, WordPress  |  45 Comments

July 24, 2011, 2:10 pm

Added a new feature that people have been asking me for since I created SFC to begin with: Comments Integration.

Facebook Comments

Facebook comments

When you make a post with SFC, the publisher plugin has the ability to push that post to either your Facebook Page or Profile. Up until now, the auto-publish feature has been doing this and storing meta-data with the post about the resulting “story” id that Facebook sends back. This data was stored, but not really used.

No longer. Now, if you auto-publish to Facebook, you have the option to pull comments back from that automatically published Facebook post and show them in the blog as if they were normal WordPress comments.

You can see this in action here on my own site. On the SFC 1.0 Photo Support post, you’ll find a comment at the bottom made by a user named “Kartsios Vasilis”. That comment wasn’t left here on this site, it was left on the Facebook story corresponding to that post. As you can see, the avatar for the user shows up on the comment, it’s styled differently (I felt the blue background sort of distinguished it), and it doesn’t have a reply link.

Since these aren’t “real” WP comments, and don’t live in the WP database, you can’t reply to them properly. So the reply link is automatically removed for them. I used a styling rule in the CSS to add the “This comment was originally made on Facebook, so replying to it here is not allowed.” message where the Reply link would normally be. Because this is just using a simple CSS style rule, you can make that message anything you like, or not have it at all. That’s up to you and your theme.

The new feature is relatively painless too. No configuration is needed. Every 6 hours (minimum), the plugin will retrieve the relevant comments from the Facebook posts, then store them as a transient. This reduces the amount of work since it doesn’t have to talk to Facebook every time. The comments are then integrated in with the normal comments for the post, and the comment count is updated to reflect the right number.

There’s still some minor detail work to be done. Right now, for example, the comments are just added onto the end of the list of comments, and so they’re out of order. The final version will have the comments integrated in correctly by the date and time they were made. Edit: This is now working, comments are added in the proper order.

If you want to use the beta version of SFC (currently marked as version 0.999) you can find it in the WordPress Plugins SVN repository.

Edit: The CSS to add this text, since people asked, is this:

li.comment.facebook .reply:before {
content:"This comment was originally made on Facebook."
}

Simple, really.

Shortlink:
Tags: , , ,
Category: Code, Other  |  21 Comments

July 20, 2011, 11:51 am

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: Red dot

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.

Shortlink:
Tags: , , , , , ,
Category: Code, WordPress  |  8 Comments
« Previous Entries
Next Entries »