Archive for the 'Incoherent Code' Category

Year-End Browser Stats

Ed Bott published fresh browser stats this morning, and I thought I would comment on some aspects…

The point that Ed makes about the lack of increase in Firefox’s market share is disappointing, but are we really surprised? I’ve said for quite some time that Firefox is geared towards the tech enthusiasts among us and that it really offers no hard benefits for your average every-day user.

Back when Mozilla was competing only with IE6 (we’ll continue ignoring Opera and Safari), it offered great benefits like tabbed browsing and native popup blocking, etc. Unfortunately, by the time it caught any ground, Microsoft had already usurped a great deal of its momentum by releasing the most-needed features in IE7. Sure, Firefox’s amazing extension support offers a lot of flexibility to those of us who consider ourselves power users on the web, but does the average person who only has one computer need 10 different bookmark syncing extensions or the inspection capabilities of Firebug? No…

The most interesting thing I see in these stats is the market penetration of IE7.

I run some basic stats on all our sites at work (mainly to let me know what cool stuff I can and cannot use), and IE6 still has an 80% lead over IE7 in our user base. Since we’re getting traffic from totally technically inept users, that’s a somewhat unfortunate statistic. Even more distressing is that IE has a 95% lead over all other browsers combined.

Clearly both Mozilla and Microsoft have done a fair job marketing their newer products to technical users who keep up with such things, but they’ve failed miserably at extolling the virtues to the average user — and that’s something that needs to change.

How do we do that? I haven’t a clue… I develop the stuff, I don’t market it.

The really interesting question, given the recent announcement that IE8 has passed the ACID2 test, is whether this will matter in a year. If all browsers follow standards properly, do we care which browser anyone uses? Of course if IE8 doesn’t drastically improve upon the market adoption of IE7 thus far, it may take another 10 years before everyone is seeing the web as it was intended to be seen…

Modifying Allowed Upload Types in Wordpress

Several times recently in #wordpress, I’ve seen people asking how they could modify the list of allowed file types used in the file uploader on the Write Post page.

Since this information isn’t readily available (apparently) and to a lesser degree because I’m tired of not being able to find my previous code (causing me to re-type it all each time), I thought I’d throw together another quick WordPress hack guide.

Introduction

When you attempt to upload a file in WordPress (2.0+ I believe) that is not in the default list of acceptable file types1, you will receive the following error:

WordPress File Upload Error

As of WordPress 2.2, there are 35 allowed file types configured in the default install. While there’s no admin-based tool for editing this list (nor any plugins that I’m aware of), it’s not at all difficult to add your own…

The Code

Upload filetypes are checked by the function wp_check_filetype in wp-includes/functions.php (around line 1,000 in my current copy of trunk). Looking at the code, we see that the default array is passed into the upload_mimes filter, allowing you to easily add and remove types at will using a quick plugin hook.

So how do we do it? Well, first you need to add a new plugin hook. In your theme’s functions.php file, add this line:


add_filter('upload_mimes', 'custom_upload_mimes');

You can, of course, replace custom_upload_mimes with your own preferred function name. Just make sure it’s something unique that ideally won’t cause any naming conflicts later on2.

Now we’ve got a hook that tells WordPress to take the array of file types passed into the upload_mimes hook and hand it to the function custom_upload_mimes. Great, but where’s our function?

No problem, I’ve got it all ready for you. Open back up your theme’s functions.php file and toss in this code:


function custom_upload_mimes ( $existing_mimes=array() ) {

// add your ext => mime to the array
$existing_mimes['extension'] = 'mime/type';

// add as many as you like

// and return the new full result
return $existing_mimes;

}

Note that the function accepts the $existing_mimes array, adds a new file type (with the extension “extension” and of the mime type “mime/type”), and then returns the whole array.

Replace extension with your extension (no period before it, just the textual extension) and then Google to find out its mime type3.

Add as many new types as you like, simply by copying the example line and filling in your values. Also, make sure you name the function the same thing you used in the hook, assuming you don’t like my convention. Save your new functions.php file and you’re good to go!

Removing Existing Types

What if you want to remove an existing allowed type, instead of adding your own new type? Well, that’s even easier!

Replace the line $existing_mimes['extension'] = ‘mime/type’; with unset( $existing_mimes['extension'] ) and you’re done. For example, to prevent users from uploading .exe files, you would use:


unset( $existing_mimes['exe'] );

Good luck, hope this helps!

  1. For example, Microsoft Installer files are not allowed by default, so track down an .msi file and try to upload it for a quick test. [back]
  2. I like to use the prefix ‘custom_’ simply because it’s easy to tell later on that this is a custom modification. [back]
  3. Googling for “.zip mime type”, for example, should give you any number of sites listing a whole slew of mime types. Yours should be in the same <category>/<type> format as the others. Zip is “application/zip”. [back]

Why the NewsGator API Still Sucks

The Idea
I had a brilliant idea yesterday, and couldn’t wait to get home so I could start coding it. Things were moving along great. I had my database created, I’d gotten Code Igniter configured and running with my standard set of libraries, helpers, etc. and I was hammering away at some code.

Damnation
And then it happened. I got to the heart and soul of the application: the part that interacted with the NewsGator API. Almost instantly, my entire world crashed in around me.

What’s that? You’ve never dealt with the NewsGator API? Consider yourself lucky. Only murderers and rapists should be doomed to such a fate. The NewsGator API is by far, and without a doubt, the worst API I have ever dealt with - and I’ve dealt with quite a few in the past.

Continue reading ‘Why the NewsGator API Still Sucks’

Using jQuery in Wordpress

It’s been a while since I actually encountered this particular nugget of advice1, but I thought I’d go ahead and make a quick post out of it anyway.

This is the kind of totally random and arbitrary development structure Wordpress has adopted that doesn’t really seem to ever be documented anywhere. If you don’t already know this kind of thing, you could very well be in store for major development and debugging headaches.

Anyway, here we go… If you’re using the built-in jQuery Javascript library that’s included in Wordpress since version 2.2, don’t use the handy-dandy $() function. In Wordpress, $() is reserved for the Prototype library, which is also bundled2.

Instead, for interoperability, be sure to use jQuery() instead, which should accomplish the same thing.

A bad example:


var username = $('#username').val();

If Prototype were to be loaded on the page this snippet of JS is running on, it would throw an error, since it uses a different pattern for selecting DOM elements.

A good example:


var username = jQuery('#username').val();

This line should work on any page, regardless of library conflicts. It’s a couple extra characters to type, but in the end it’s really for the best - you get portability, and it’s more self-explanatory which library is being used when you go back to look at this code in 6 months.

I’m planning another, similar, Javascript-related post as soon as I get a few more minutes to make it coherent. Stay tuned, and happy coding!

  1. Pointed out by rob1n in #wordpress, BTW. [back]
  2. In all fairness, I suppose this makes sense. Prototype was added first. [back]

How Strong is YOUR Password?

You’ve probably read it over on the Wordpress.com blog by now - they’ve taken a step up in password security by adding a meter that gauges the strength of a user’s password as they change it.

Well now you don’t have to use Wordpress.com to make sure your users are aware when their passwords stink - the Password Strength plugin provides the same functionality for stand-alone Wordpress 2.2+ blogs.

Password Strength is a stand-alone port of the Wordpress.com feature written by Donncha1 and uses the same Password Strength Meter jQuery goodness, written by Phiras!

Download
Ready? Set. Goooooo! password_strength-1.0

Note that this plugin requires Wordpress 2.2, as it relies upon the bundled jQuery Javascript library.

  1. Or is it that cat that does all the work? I never can tell… [back]