The chain of events leading to my decision to become even geekier started with one of my favorite pasttimes: aimlessly surfing the web. I came upon this blog post that talked about the Dvorak keyboard layout being a much faster & more efficient way to type. Well, I like efficiency, so the next logical step was (of course) to drop all plans for the night and learn it. I followed his link to DVzine.org and printed out their comic about the history of keyboard layouts, and if there was any convincing left to be done, that did it.

Next I decided to pop the keys off my keyboard and rearrange them, which turned out to be a bad idea, because I bricked my keyboard in the process. (I’m typing this on a spare.)

Anyway, a couple of typing tutorials later, I got bored, so here I am. I’ve been typing this entire post in Dvorak, and I’m cruising along at a whopping 10 words per minute. But just like being forced into driving a manual transmission by losing my automatic, I know that this is the quickest way to learn it. Wish me luck!

Oh, and if you do decide to follow in my footsteps, don’t brick your keyboard!

Update: The hardest part of this is definitely keyboard shortcuts. I never realized how much I looked at the keyboard for those.

Another update: Keyboard shortcuts can be saved! There’s a second Dvorak option in Mac OS 10.5 (it’s one of four options in 10.6) called Dvorak – Qwerty that converts the keyboard to Qwerty when the command key is held down. I will probably try to get used to the keyboard shortcuts in Dvorak eventually, but in the meantime, I won’t accidentally quit an application when trying to cut and paste. Hooray!

I recently had the privilege of rebuilding the website for Minnesota Voters for Animal Protection, and developing the site in WordPress opened my eyes to a lot of tricks, shortcuts, and standards that I hadn’t used before.

In the spirit of learning new WordPress development techniques, I thought I’d share the ten resources I use the most. These cover a lot of best practices that are a great baseline for solid plugin & theme development. Here they are, in no particular order:

1. WordPress Template Tags

This might be the most-clicked bookmark on my computer. It’s such a fantastic, quick reference to look up the arguments/syntax/existence of almost any WordPress function.

2. WordPress Coding Standards

I feel lucky that my coding style matches that of the WordPress team almost completely; I had very few adjustments to make. Developing for WordPress in their coding style makes your code easier for others to read and modify later (if you’re making open-source stuff). Also, if your style is all over the place, this will help you achieve consistency.

3. Plugin Resources (from the WordPress Codex)

I keep this bookmarked because it links to the pages in the codex I refer to the most. The list of filters & hooks, and examples of their syntax, is especially helpful for me.

4. Best practice for adding JavaScript code to WordPress plugins

This is the most concise and easy-to-follow guide on this topic that I’ve seen.

5. Advanced Power Tips for WordPress Template Developers

Smashing Magazine is a fantastic place for finding useful, plug-and-play code snippets that might change the way you develop forever.

6. Advanced Power Tips for WordPress Template Developers: Reloaded

More great stuff from Smashing Magazine, this time focusing mostly on the admin area.

7. Posts tagged “WordPress” on Smashing Magazine

I wanted to list a lot of these posts, but then my entire list would have been Smashing Magazine articles! Here’s their list of WordPress posts.

8. WpRecipes.com

Like Smashing Magazine, there are a lot of code snippets here that work very well for specific things.

9. Digging into WordPress

This website is a great resource for unlocking more advanced, CMS-like functionality in WordPress. Their book is one of those I mentioned at the beginning of my post.

10. Google

This might be how I learned 99% of what I know about WordPress development, whether directly or indirectly. You’d be surprised at how quickly you can find what you need by searching for a function name or throwing “wordpress” in front of your keywords.

Refer back to these sites often! The blogs update frequently, and the codex entries are great standards to keep bookmarked in your browser.

Set up a print stylesheet

For those who don’t know how to make a print-specific stylesheet, it just takes the addition of one attribute to your CSS links in the <head> section of your site:

<link rel="stylesheet" href="style.css" type="text/css" media="screen, projection" />
<link rel="stylesheet" href="print.css" type="text/css" media="print" />

The “media” attribute tells the browser to pay attention to stylesheets only in those situations. Add ‘media=”print”‘ to your stylesheet link for a print stylesheet. If the “media” attribute is left out, that stylesheet is called in all display situations, including print.

Hide unnecessary information with display: none

In the case of my website, I decided to hide things like the sidebar, the email subscription form, and the social media/bookmarking links at the end of each post. Do this with a simple display: none; at the top of your stylesheet. The user isn’t trying to print out your sidebar; they’re trying to print the article they just read.

Add back any global styles to make your printed page match your website

This step is only necessary if you left your main stylesheet out of the mix for printed pages. You will probably want your fonts to be the same on paper as they are on a screen, so make sure to re-insert those styles in your print stylesheet. The same goes for classes that apply global formatting to elements, such as floating images left or right.

Add extra information to your website to display only in printed pages

On my website, you’ll notice that the only thing in the footer is the copyright statement. When it’s printed, the URL “alisothegeek.com” appears in the right side of the footer. This is something I added in my footer (you can see it in the source code) and I set it to hide in my main stylesheet, but not my print stylesheet. Things like this can give a little extra clarity to users who print an article and later forget where it came from.

Also, the header on my site is one giant background image, with no text. Many modern browsers automatically turn off background images when they print pages, in order to save ink or toner. For the benefit of a user printing my site (and for the benefit of screen readers & search engines) I do have text in the header of my site, and CSS is hiding it on the screen. This way, it shows up on printed pages but not in the browser. I also added my logo next to that text using an <img> tag so it would still print.

Make hyperlinks useful on a printed page

Printing out a hyperlink is just like printing out text that’s underlined. It means no more to the reader than regular formatted text. To keep hyperlinks useful on a printed page, I added this code to my CSS (taken and modified from this article at A List Apart):

.entry a:after {
     content: " [" attr(href) "]";
     font-size: 80%;
     font-weight: normal;
}

This adds the URL after each hyperlink in my post’s content (which is div class="entry") in slightly smaller font surrounded by square brackets. This way, a printed article still retains the benefits of its hyperlinks.

Make final touches to keep it looking classy

Take some time and print out some test pages. Make formatting tweaks as necessary to make sure you didn’t miss anything from your main stylesheet that you want to keep in printed form. Add padding or margin where it will help things look nicer. For many websites, a printed page is a lot wider than the main content area is on the screen, so take that into consideration as well.

I hope this post helps some website builders out there with print stylesheet creation. It’s something that is often overlooked in website design, but something users really appreciate when it’s done right. Happy coding!

1. Use the $wpdb object for all database queries

If you only read and follow one of these tips, make it this one. Setting up database connections with mysql_connect over and over again is a waste of code. If you’re in anything other than a standalone processing script, $wpdb is ready to go with just one line of code:

global $wpdb;

(If you are using a standalone script for something, just include two files to make $wpdb work: wp-load.php and wp-includes/wp-db.php.)

There are different functions for the $wpdb class to make different kinds of database queries (see the WordPress codex page for details on them all).

On average, I find that using $wpdb saves two to three lines of code for each time I make any sort of database query. For example, this:

$name = mysql_real_escape_string($name);
$result = mysql_query("INSERT INTO $myplugin->categories_table (name) VALUES ('$name')");
if (!$result)
    die("Could not insert into database. ".mysql_error());

turns into this:

$wpdb->insert($myplugin->categories_table, array('name' => $name), array('%s'));

One of the most important reasons to use $wpdb instead of mysql_query is that it automatically protects the database from MySQL injection attacks. More details about that are on the codex page as well.

2. Call jQuery using wp_enqueue_script

One of the most frustrating things I’ve seen responsible for my WordPress plugins not working is that other plugins are calling jQuery the wrong way:

<script src="../../../wp-includes/js/jquery/jquery.js" type="text/javascript"></script>

WordPress has its own way of handling calls to jQuery (and other common Javascript libraries). It’s called wp_enqueue_script. This is how WordPress would have you call jQuery in a plugin:

wp_enqueue_script('jquery');

So if WordPress itself needs to load jQuery, or an additional plugin calls it in this way, then it’s only loaded once, and it’s loaded in no-conflict mode. This means that there won’t be two jQuery scripts of different versions competing for attention. And if you prefer an external reference to jQuery (such as the one from Google Code), there is a method for doing that in a WordPress-friendly way, too (see step 2 on this linked page).

3. Use unique class & function names

If you have a function in your plugin called “load()”, then what happens if another plugin is activated on a user’s blog that uses a function called “load()”? Well, crap explosions happen. Plugins break. Solving this problem is easy: name all your functions something unique to your plugin. My personal method is to come up with a two- or three-letter representation of my plugin (like “sm” for SimpleMap) and use that as a prefix to all my function names. For example:

sm_display_map()

Easy as pie.

4. Prep all text for localization from the get-go

Even if you don’t include any translation files with your plugin, someone out there might want to write one for you (or for themselves). It’s pretty tedious to go back through your existing code and prep the text for translation, so make it a habit right away. First, you have to pick a key for your plugin’s translation files (this is usually just the plugin name or slug). Then you have to surround any text that gets displayed to the user with the following code:

__('This is the text to be translated.', 'PluginKeyHere');

Note: ‘PluginKeyHere’ would be the key you picked. For example, in SimpleMap this is ‘SimpleMap’.

The double underscore at the beginning will return the translated string to PHP. If you want to echo the string, instead of adding echo before the double underscore, you can use this shorthand:

_e('This is the text to be translated.', 'PluginKeyHere');

More details on localizing your plugin can be found in the WordPress codex.

5. Write a good README file

This is something I highly recommend. When I’m searching for a plugin to install, an inadequate or poorly written README file will often make me go back to my search results and keep looking. Writing a good README file shows that you care about the people using your plugin. If you treat it like it’s just a step WordPress forces you to take to submit a plugin to the repository, it’s going to make you look like an ass, and users won’t want to try your plugin at all.

To top it off, Mark Jaquith has recently released a plugin that makes good use of your README files on your own blog. It’s called I Make Plugins, and it automatically populates pages on your blog to promote the plugins you’ve created. You can see it in action here on Aliso the Geek.

Well, that’s all for now. More tips are sure to come in the future! If you have any suggestions, please leave a comment and share them!

—

I was going to change the way Categories work a little. Right now the category name is actually what’s inserted into the database record for a location. In the categories table, each category has an ID number, and I was going to link to that from the locations database instead. That way, when you change the name of a category, it will be changed across all the locations in that category. I could also let the user reassign those locations to a different category automatically.

This would make matching the category in a search a little more painful to code. It also still limits each location to one category.

My mission with SimpleMap is to keep it really simple… like I’ve said in a blog post or two, I won’t be adding any major features for a while after I release 1.2, because I want to make this plugin as streamlined as possible before it gets any bigger.

Would adding a Tags field, like you mentioned in your email, be a little too busy? I like that it would allow another search dimension, and that it would be unrestrained as to what you type in it (multiple tags, huge phrases, numbers, wouldn’t matter). My only concern is making things too complicated.

Then again, WordPress uses both categories and tags for posts, and people using this plugin already use WordPress. So I think I’ve answered my own question.

It started out pretty simply: we only needed a few different security levels, because a lot of the teams could share the same level of access to the site’s content. I made a simple(-ish) plugin that added an extra table to the WordPress install and defined a number of groups (an unlimited number, technically, but we only needed five to start). In the interface, you could choose which WordPress roles each group was equivalent to, and which other groups each one could share access with. For example, the Admin group would include the access levels of the Basic AND Executive groups, while the Executive group would share Basic’s access but NOT Admin, and Basic didn’t share anyone’s access. I even figured out how to add a drop-down menu to the user add & edit forms to choose a group for each user. Everything was as it should be in a plugin: dependent only on the files in the plugin folder.

Since then, UserGroups has ballooned into a monster of epic proportions that now prevents any automatic upgrading of WordPress. Why? Because I had to edit the core WordPress files to make things work in a hurry. The true scope of the project wasn’t clearly defined at the start, so addition after addition came to the list of requirements, and complications popped up in every function I had written in my tiny little plugin. Now the WordPress install has four extra tables, and only the original extra one is even created or destroyed by the plugin install. The core files in the wp-admin folder are altered to insert even more options into the user add & edit forms. There are not only groups now, but also teams, which do not affect security level but still need to be distinguished. There are sub-groups within the groups. It’s all functional, but it’s a complete mess that is in no way compartmentalized. On top of all this, it’s still not complete yet.

The moral of the story? Have a very clear picture of what the end result needs to be before you even start a plugin (or any other project of any kind, really). This could have been a really cool plugin to release as a freebie, and now it’s going to be too much work to dig it out of the piles of trashy code it’s buried in.

This is a pretty short post, but the single piece of information in it is something I consider very valuable knowledge. Everyone has been through it, but I wanted to remind everyone of how frustrating it is and how easily it can be avoided.

Hopefully, the next time a project like this comes along, this little programmer will remember to talk directly to the client about what actually needs to be built before she starts building it…