The last 3 releases of WP, I’ve made troubleshooting posts about what to do, what plugins are going to barf, and so on. This time, there really doesn’t seem as much to worry about. Of course, having said that, everything will die in a fire. Actually, though, I haven’t made a list of things yet, because there’s nothing to list. I’ve not run into any stand out ‘Oh shits!’ and the forums are remarkably quiet. So. If you’ve got stupid problems, or found you have to edit themes/plugins, please reply and let me know! I’ll get on it.

So here’s some of the cool new stuff:

Akismet 2.5.6

Custom Headers and Backgrounds — See also Flexible Headers in 3.4 Themes and Backwards Compatibility for WP 3.4 Headers and Backgrounds

Twitter was added to oEmbeds — This should just work out of the box, but if you have a plugin (like Blackbird Pie), you may want to disable it before upgrading.

RPC-XML support for Custom Post-Types.

Admin Toolbar To The Top! Click on any blank space in the admin bar and you go to the top of the page. (It’s the toolbar, damn it, I know this!)

Sexier Theme Options. Have you ever wanted to see what the changes did to your theme on the fly? Go to WP Admin > Themes and click on Customize Theme to get a quick way to see what you’re tweaking. Not every option is there, nor will every option be added, but this is pretty nice!

You also get that view when you preview a theme.

Of note, Twenty Twelve and Favicons got punted to 3.5.

While code isn’t outright rejected for being ‘bad’ code (only security holes and guideline violations), a lot of plugins are doing the easy things wrong. These plugins will get approved, but they won’t work with all setups, they’re more likely to have issues with Multisite, and they’re just not thinking forward. They aim to solve a, singular, problem, without looking beyond. Primarily I see this when people are trying to bring in some js code into their plugin. Heavens knows I do it, and I’ve done it wrong too. But as I see more and more plugins, I’m starting to get better and better at knowing what’s wrong when I see it. ¹

The easiest way to show you is to give you some really bad examples and go through some of the steps to fix it. The best part is that I’m actually going to use real plugins I’ve seen. Only the name has been changed to protect the innocent.

Ready? Here’s what we’re doing wrong.

Not using functions to define locations

The very bad code:

echo '<script src="/wp-content/plugins/myplugin/myscript.js"></script>';

I wish this was something I made up. Worse, I’ve see it more than once. Recently.

This install is assuming WordPress is installed in the root of your HTML folder (i.e. domain.com). This is not always the case, as many people install WordPress in subfolders. We’ll need to fix that first with home_url().

echo '<script src="'.home_url('wp-content/plugins/myplugin/myscript.js').'"></script>';

Now it’s a little better, as by using home_url() we’re letting WordPress define where ‘home’ is. Great! This has two pretty obvious problems, however. First, if I have WordPress installed in a folder, like /public_html/wordpress/, but I’m running it out of the main domain by giving it its own directory, this won’t work. Your code would point to http://example.com/wp-content… when mine is in http://example.com/wordpress/wp-content.. instead! The ‘easy’ fix is to change home_url() for site_url(), but what if I’m not using wp-content? You didn’t know we could Move wp-content? We can. So let’s address that.

echo '<script src="'.content_url('plugins/myplugin/myscript.js').'"></script>';

By using functions to determine plugin and content directories, we can make this much more flexible. That works, but it could be better. What if we didn’t have to define the plugins or myplugin folders? We could just do something simple like this.

echo '<script src="'.plugins_url('myscript.js',__FILE__).'"></script>';

Now we have a simple, flexible, functional script embed of js. Except there’s one, minor problem. We’re not including the script correctly.

Not enqueuing files

This isn’t ‘wrong’ really. I mean, if I put this in my plugin, it would echo out the script, and that’s what I want, right?

echo '<script src="'.plugins_url('myscript.js',__FILE__).'"></script>';

But let’s say I want to put it in my header:

function my_scripts_method() {
    echo '<script src="'.plugins_url('myscript.js',__FILE__).'"></script>';
}
add_action('wp_head', 'my_scripts_method');

And now I want to include my CSS so it looks pretty:

function my_scripts_method() {
    echo '<script src="'.plugins_url('myscript.js',__FILE__).'"></script>';
    echo '<link rel="stylesheet" type="text/css" href="'.plugins_url('myscript.js',__FILE__).'" media="all" />';
}
add_action('wp_head', 'my_scripts_method');

Oh, wait, no, I wanted my JS in the footer:

function my_scripts_method_foot() {
    echo '<script src="'.plugins_url('myscript.js',__FILE__).'"></script>';
}
function my_scripts_method_head() {
    echo '<link rel="stylesheet" type="text/css" href="'.plugins_url('myscript.js',__FILE__).'" media="all" />';
}
add_action('wp_head', 'my_scripts_method_head');
add_action('wp_footer', 'my_scripts_method_foot');

And really, this will work. But it’s not efficient, I’ve got extra actions, and I’m not considering any jquery dependencies anymore. By using wp_enqueue_script is better. Weblog Tools Collection did a series on how to properly add scripts (note that it’s a bit out of date with the use of WP-CONTENT constants). From that we can extrapolate to use just this to include our js and css:

function my_scripts_method() {
    wp_enqueue_script('my_script', plugins_url('myscript.js',__FILE__) );
    wp_enqueue_style('my_script', plugins_url('myscript.css',__FILE__) );
}
add_action('wp_enqueue_scripts', 'my_scripts_method');

What enqueue does is put your code in the best possible location and can be extended to load dependencies. wp_enque_scripts has a lot of power, and because it’s a WordPress function, it’s got options that make it more flexible. Like when I look at my above code, I remember, oops! I wanted to run my js out of the footer! Not a problem. Look at my options.

wp_enqueue_script('handle', 'source', 'dependencies', 'version', 'in_footer');

The ‘handle’ is what I want to name my script, it should be unique. If I register my script, I can call the handle over and over again. We’re using my_script right now. The ‘source’ is where my file is located. We’re lifting that from our other code, the bad code, because it works. Your ‘dependencies’ are the other js files yours needs to function. If I put in array('jquery', 'scriptaculous') then both jQuery and Scriptaculous would get loaded before my script. Curiously, you don’t actually need the ‘version’ option, as you can leave it blank and WordPress will automatically add a version number equal to the current version of WordPress you are running. So every time you upgrade WP, it will get updated and force a re-download. This is good, since if you have dependencies to scripts included in WordPress, and they change with a new version (which is the only way they can change), then you get updated too. Finally we have the value I was looking for, ‘in_footer.’ Leave it blank and it’s in the header, put in true and it’s not.

This makes my code:

function my_scripts_method() {
    wp_enqueue_script('my_script', plugins_url('myscript.js',__FILE__), '','', true ););
    wp_enqueue_style('my_script', plugins_url('myscript.css',__FILE__) );
}
add_action('wp_enqueue_scripts', 'my_scripts_method');

Yeah, isn’t that a lot easier?

Using a different jQuery

This last one I’m going to touch on today is the exact code I saw, in the wild, and it’s got two of my three buggaboos in it.

wp_enqueue_script('jquery-1.4.3.min.js', '/wp-content/plugins/myplugin/js/jquery-1.4.3.min.js');

Okay. You already know the right way to call the script, so we’ll edit that into something more flexible.

wp_enqueue_script('jquery-1.4.3.min.js', plugins_url('js/jquery-1.4.3.min.js',__FILE__) );

That should be okay, but it’s totally not.

Most importantly here, we’re calling jquery, which is actually built in to WordPress. Now, we’re calling it by a different handle, but that’s no guarantee that it won’t cause conflicts. In fact, I’m pretty sure this will cause no end of problems with some plugins. The right thing to do would be this:

function my_scripts_method() {
    wp_deregister_script( 'jquery' );
    wp_register_script( 'jquery', plugins_url('js/jquery-1.4.3.min.js',__FILE__) );
    wp_enqueue_script( 'jquery' );
}
add_action('wp_enqueue_scripts', 'my_scripts_method');

Now we’re making sure we won’t have conflicts by re-registering jquery, replacing it, and moving on.

A lot of people would actually recommend using Google instead, as it takes the responsibility off you for including a file you don’t ‘control.’ Also it makes your plugin smaller and load faster.

function my_scripts_method() {
    wp_deregister_script( 'jquery' );
    wp_register_script( 'jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.4.3/jquery.min.js' );
    wp_enqueue_script( 'jquery' );
}
add_action('wp_enqueue_scripts', 'my_scripts_method');

Great! Now we’re done, right? Wrong. As of this writing, WordPress is using jQuery 1.7.2. Now I couldn’t come up with a reason to include an old version of jQuery in WordPress (newer, yes, older, no), so I asked around and none of my friends could either. Using an older version is more likely to cause issues with newer code included in WordPress, as well as plugins which are upgraded to take advantage of the new features. You’re shooting yourself in the foot. The only thing you might be using this for is to include deprecated fictions, and really you need to update your code to fix that instead.

If the whole point is to load the scripts from Google, though, there’s an awesome plugin for that.

However, not all of you have access to the server to make all those cool tweaks and changes to speed up your website. If you’re on shared hosting (and there’s nothing wrong with that), you can’t edit httpd.conf, you can’t always edit php.ini, and you sure can’t upgrade PHP on your own. Don’t worry, there are still things that you can do!

The first thing you should do is understand that the more complicated your site is, the slower it’s going to be. So if you want a site with all those bells and whistles, you have a lot more work to do than a simple, plain, site. These are the tradeoffs we must accept in all things. ² Reduce the complications and things run faster. You have to have a balance between ‘everything’ and usability. If your site is sexy as all get out, but slower than a truculent five year-old on a family walk, then you’re doing it wrong. That doesn’t mean you need to have the world’s most boring site, it just means you have to start learning what it is that makes your site slow. When you look at themes and plugins for a site, remember the more you have, the slower things may become, so use them wisely.

My favorite tools to show why a site is slow are YSlow and PageSpeed. YSlow is a browser add-on you can use with Chrome, Firefox, and every other commonly used browser. Except for IE. Once installed, you simply go to the webpage and run the tool to get a scan of your site. You get ‘graded’ on an A through F scale, with F being the worst, and the grades are computed based on a fairly understandable methodology. ³ Page Speed is Google’s version, and I prefer it, but only because I don’t have to install anything to do it, and it gives really good explanations of what’s wrong. There’s also Web Page Test, which is great to find out if your site flails on different browsers, as well as giving you accurate speed breakdowns.

Here are three of my sites, all installed on this server, scanned by YSlow:

And here are the same three as SiteSpeed:

I’m not going to go through every option, most of them are self explanatory (put the CSS at the top and JS at the bottom). Instead, I’ll explain the weirder ones that you can tweak yourself, and some that you can ignore. If you’re using a tool like W3 Total Cache, you actually can configure most of this directly in the tool instead. For what it’s worth, I did ‘fix’ my scores with both sites and I’m now in the 90s from Page Speed and .. Well not so much with YSlow. The two disagree on how much ‘weight’ to give various errors. Page Speed thinks minification is low priority, and doesn’t judge you about a CDN. It also understands that you can’t gzip what you don’t own. If you use YSlow, make note of what you score poorly in, and fix those as best you can.

Things I Ignore

When I get complaints of too many HTTP requests, that just means I’m calling ‘too many’ JS scripts and stylesheets. YSlow doesn’t say which ones those are, which isn’t actually helpful to the novice. If you click on ‘Read More’ it just explains why this is bad. The idea here is that you should have one CSS file, but realistically, any dynamically generated site is going to have more that one. Especially when you consider I’m calling some from Google, Facebook and Twitter for my sharing buttons. While this does slow your site down, unless you have 20 stylesheets on your own site (again, I’m not counting the ones on other domains), it’s not that big of an issue. If you minimize what you have, and combine as much as you can, you’re going to be okay.

I also totally ignore any scores related to my CDN, or rather the fact that I’m not using one. Yes, a CDN will make your site much faster, but I don’t think this is applicable for everyone, and I generally ignore that value.

Finally I ignore suggestions to use cookie-free domains, but that’s because I’m running WordPress, and it needs cookies.

Things I Fix in .htaccess

You can fix most expires headers errors, but only the ones that relate to your site. When I look at a scan for one of my domains, I see that the items my site loads that don’t have Expires headers are a flash module from PayPal, Google’s +1 javascript, a banner, and two gravatars. Those are all items that, yes, can slow my site down, but they’re outside my ability to fix! And in the case of gravatars, I don’t want them to Expire too soon, since they may change. I’m going to, again, ignore this.

Why wasn’t my server listed? It’s because I added Expires headers to my site. Obviously. The easiest way to do this for your site is to put the following in your .htaccess file ⁴:

<ifmodule mod_expires.c>
  <filesmatch "\.(jpe?g|gif|png|css|js)$">
       ExpiresActive on
       ExpiresDefault "access plus 1 year"
   </filesmatch>
</ifmodule>

What this will do is turn on Expires and set to to today plus one year. Now this isn’t actually the best way to do it, as it leaves out a lot of variables, but for most people, it’s good. Keep in mind, the further you set out this expires, the harder it is to change any files! For example, if I upload a PNG with a 1 year expiration, and then upload a new version, no one will see it (unless they flush their browser cache). Don’t set this further than a year, and only set it for things you know aren’t changing often. ⁵

Cache-Control is the half-sibling of Expires, and lets you specify what files should be cached and for how long. The Ask Apache site has some great examples, as this is what I generally use:

# 480 weeks
<filesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Cache-Control "max-age=290304000, public"
</filesMatch>
 
# 2 DAYS
<filesMatch "\.(xml|txt)$">
Header set Cache-Control "max-age=172800, public, must-revalidate"
</filesMatch>
 
# 2 HOURS
<filesMatch "\.(html|htm)$">
Header set Cache-Control "max-age=7200, must-revalidate"
</filesMatch>

The ‘must-revalidate’ tag is what makes sure your webpages changes actually get picked up quickly. Nothing’s worse than editing a typo, and not having it fixed for your readers!

Related to that is ETags, which is a bit weird, but this too is something you can tweak. If you disable ETags, everyone has to trust your cache and that gives you a lot of control. It sounds easy, but there’s a reason we should be using ETags for some situations. My sites are using a pretty complex rule that was set by W3TC for me. It sets my Cache Control and ETag, generating the rules I need. If you just want the basics, though, AskApache’s Speed Tips: Turn Off ETags will get you there. For what it’s worth, a small site doesn’t need to worry about this too much.

If you want to grab my default .htaccess starter, here you go!

Things I Fix via CPanel

You can also speed up your site by enabling gzip. I’d say I left it off on purpose to show you the error, but the fact is I forgot to turn it on when I moved to a new server. If you have cPanel, this is stupid easy. Log in, go to ‘Optomize Website’ and turn it on.

Doing improved a lot of results on my site, though it didn’t want to consider three of my .js files gzipped for some reason, though it did on other domains on the same server when I changed it. I’m not terribly concerned at this point, since I used the HTTP Compression Test (from What’s My IP?) and it says I’m compressed.

Things I Fix with Elbow Grease (or Plugins)

Minification. If you view the source of this site, it’s ugly. Everything’s all crammed up without line breaks, and finding anything is a hassle. That’s because I minified my content. If you don’t have a plugin or add-on for your site that can do that for you, you’ll need to do this manually, via Minify CSS and Minify JS. It’s more of a hassle to do that manually, since it’s hard for you to edit later. After-the-fact compression can slow your site a little, but it’s easier to maintain and still faster than non-minified code. Now I use W3TC, which has a minification tool built in, but there are other WordPress plugins that do the same thing.

The Rest

There are a lot more tips and tricks to getting your site running faster. I mention W3 Total Cache (W3TC) multiple times because it works great. There’s also WP Super Cache, which I prefer for smaller hosts and shared servers. W3TC is very, very, very complicated, so be warned. WP Super Cache isn’t a ‘lesser’ tool, it’s just different, and I advocate using either one if your site is moderate to large.

If your site is small, you really can get by with just minifying. There are a lot of minification plugins out there. Images can be reduced in size by compressing them more via Smush.it (there’s a plugin called WP Smushit for WordPress). Many people have also suggested using a Lazy Load plugin, like jQuery Image Lazy Loading, which loads images on demand. I like it, but it slows my site down, and doesn’t work well at all on ones with a lot of dynamic images. I may be using it wrong.

Anyone can take advantage of a free CDN, Cloudflare has a free plan. ⁶ They claim to protect you as well as speed things up, and I’ve heard interesting (good) reports on it.

Many people advocate using plugins to tune your database, but I really don’t like using a plugin for that. You can optimize your database with a cron job instead, or even just do it manually now and again, if you think your site is sluggish. For WordPress I limit my revisions and empty my trash more often with two lines in my wp-config.php:

define('WP_POST_REVISIONS', 5);
define('EMPTY_TRASH_DAYS', 5 );

When all else fails and nothing you can do speeds up your site, take a look at your server. If the server itself is really slow, all the time, and I mean you can hardly get your email, ask your host if you can be put on another cluster. A lot of shared hosts are oversold, since not everyone needs all the space and power. It makes sense, but some hosts monitor the status of these servers and move people around if they become bad neighbors, while others wait for you to notice. Opening up a line of communication with your host is always a good thing. Remember, you’re paying these guys! They should be willing to help you out, or you should leave and get a new host.

At a certain point, you’ll notice that the only ‘fixes’ are to throw more money at it, buying a better host, better themes, better tools, and so on. And that’s simply a fact of life. You can’t live forever on ramen and hot dogs.

This list is not all encompassing, but touches on the issues I see the most often.

What You Must Do

Failing to do the following will likely end up in your plugin being yanked (or not approved at all).

Read The Guidelines

We are not pirates. These are not wishy-washy rules, though they are intentionally kept as light as possible. You see, the more you make a rule “You can’t do this!” then the more you get “Well, you said I couldn’t dig to China, not Australia!” ¹ The basic guidelines are on the front page of the Developer Center, but it’s the expanded guidelines you really need to read. I helped write those guidelines (over beery emails with Otto) and he and I both hate that we have to spell certain things out, but apparently they’re unclear. Just read them. If you think you’re doing something that might be on the far side of okay, ask around. Tweet, post in the forums, or find a plugin dev you respect and ask them directly.

Check Licences

All plugins must be GPL2 (or later) compatible. This is pretty basic, but a lot of people don’t realize what that means. First, there’s the issue of GPL2 versus GPL3. While the WordPress repository accepts GPL3 plugins, it’s still not compatible with everything, so make sure the code you fold into the plugin will work with which ever license you chose. If you don’t want to use GPL, you don’t have to! Remember, there are a lot of GPL Compatible Licences. At the same time, there are a lot of incompatible licences as well. And there are the Non-free Software licenses. When you’re only releasing your own code, this is pretty easy. You pick a compatible license and move on. When you’re incorporating other people’s code, however you have to study their license carefully.

Generally I’ve seen people get dinged for using the Creative Commons license, and in most cases this is because they’re not using the CC0 license. That is the only CC license that really works with GPL (except for CC BY ND). Your code really shouldn’t be CC licensed, anyway, though. Just don’t use it.

Provide the code

When you submit your plugin, put in a link to the code so it can be downloaded and checked. ² If, for some reason, you can’t because the code is behind a paywall, or you don’t want it in the wild, don’t worry! The only people who see that link are the plugin review team, and they’re trustworthy. They don’t need an API key, either, they just want to make sure you’re not breaking the repo guidelines. If you don’t provide a link to the code, you don’t get in. It’s really that simple.

Don’t break the other WP rules

Did you know you can’t use ‘wordpress’ in your domain name without permission? If your author or plugin URL is http://mycoolwordpressplugins.com then your plugin will be rejected.  ³ In addition, you’re still going to be held subject to the forum rules with your account. I mention this because if you get blocked on the forums for rampant asshattery, you won’t be able to check new code in. Basically remember that it’s the internet, and we can see your behavior on Twitter, Forums, Faceybooky, etc. Don’t be an idiot.

What You Should Do

Not doing the following won’t get you punted from the repo, but they’re still good to do, in order to provide the best support possible.

Write a good readme

A good readme file is going to tell the person everything they need to know before they download the plugin. This means:

1. Describe what the plugin does
2. Explicitly state any and all requirements
3. Be upfront about any external accounts required (for APIs or what have you)
4. Inform users if their information is being sent to another site, where, and why (not necessarily technical explanations, just ‘Your IP, browser specs, etc will be sent to Google for Analytics purposes. This is required if you want to use Google Analytics.’)
5. Include screenshots of the options
6. Include a screenshot of what the plugin looks like on the unmodified default theme
7. Document if no support is provided (or if support is handled somewhere other than the WordPress forums)

Credit Appropriately

A subset of that is that if your plugin is a fork of someone else’s, be the good person and credit them! It’s not required all the time, but take a look at the copyright information on a plugin. Sometimes they say they require credit in the code. If so, you’ve got to do it. Even just a line that says “Copyright 2009-2011 Some Other Dude” and then “Copyright 2011 Me” below it. That’s a nice CYA. If you want to be really nice, put their userID under ‘contributors’ in the readme file, and they’ll have their pretty face on your plugin.

Write Good Code

Using good code is complicated. I don’t pretend to be the best at it myself (seriously, the level of shenanigans I went through over nonces cannot be measured on a human scale). But I know that good code is secure code. I know I should use nonces in certain situations, I know to protect against SQL injections, and I know to not let total strangers upload executable files (so they can’t upload a PHP file that wipes my DB, for example). And I know when to go find Otto, WePay him a beer, and say “So what the hell did I do wrong, here?”

Writing good code is exceptionally complicated, which is why, if you’re going to write a large plugin, you need to know what you’re getting into. The problem a lot of people get into is the classic ‘Your eyes are bigger than your stomach.’ When you write a plugin, keep it simple. Start with the code you know, slowly fold in the new stuff. Try to test as many different ways as you can think of, but know that you’re going to miss something.

What To Do If Your Plugin Is Yanked?

Every plugin developer’s worst nightmare is waking up to find that their plugin was yanked from the WordPress repository.

Don’t panic!

This happens when your plugin has been reported as possibly being in conflict with the developer guidelines, or it has a security hole. Many times you will not be notified when this happens. Sometimes you’re not notified because the report is found to be incorrect, and sometimes it’s because you’ve been warned before. And, once in a while, it’s because the person who closed your plugin doesn’t have the ability to email you. Surprise! There are some people on the plugin repository team who don’t have the access to the plugins email system, so when they close your plugin, they’ll ask someone else to email you. If that person is busy, it might take a while.

When a plugin is closed, the rest of your plugins are usually checked over to make sure they’re not also having an issue. For example, if you have one plugin with a front facing link that’s turned on by default, all your plugins will be checked for that and, if they all have the same problem, they will all be yanked. This is why you need to keep up to date on the plugin guidelines, and follow the WordPress Development Blog.

As soon as you find out your plugin is closed, email plugins@wordpress.org and ask what you can do to restore it. Posting in the forums won’t help much.

There’s more than one path to knowledge; it’s not always the same knowledge once you get there, either. But if you think it was easy to get there, you’re not at the destination you think you’re at.

Credit: Surviving the World

The obvious problem with this is that if someone gets access to your files (via a security hole in your webapp or your webhost), they now know your server password and ID, and can get in and cause serious damage.

But what if instead of using that normal ID and password, you made a special one that only was used for SQL. You couldn’t log in with it, you couldn’t FTP or anything except play with SQL. Then, even if they got in, they couldn’t delete your files! That’s really simple.

cPanel

If you’re using cPanel, just go in to the MySQL Databases screen and add a new user. I like to use something totally obvious, so I can remember it, like ipstenu_sql.

For those passwords, I tend to use the generator to make something like m}+akwQN=&)!, not because I feel they’re more secure (I prefer pass-phrases, like ‘donkeyvanillatapdance’), but as a reminder for me not to use it for anything but SQL. Hang on to the password right now, though, you’ll want it in a minute.

Then you add the user to the databases. Back on the main MySQL page, there’s a little selection to Add User to Database which is really obvious to use. Pick your user and your database.

Clicking Add will take you to the privileges screen:

Give the user ALL privileges, as you may need this later on.

Plesk

It’s just as easy in Plesk. Once your new database was created you, were automatically brought to the area to create the New Database User. If you didn’t do that, it’s okay, just go back the main database page and find the datase you want to add the user to (in this case, it’s LovePlesk_NewDatabase).  Click on the Add New Database User icon, fill in the information (remember to save your password!), and click okay.

Plesk should automatically grant the user ALL privileges.

Updating Your WebApp

Once you have the new user made, all you have to do is edit your config file (i.e. wp-config.php for WordPress) to use the user and password, and hit save.

Now you’ve made your install a little more secure.

Out of the box, WordPress has all the major tools you need to start publishing. Turn on Akismet and you are good to go. What happens next is up to the needs and goals of your site.

Out of the box, WordPress needs nothing. It works just fine as is, and you don’t need to do a blessed thing to it. But you want to. And that’s where it all gets messy.

Needs and wants are different things, and few of us need everything we have installed on our sites. I have 27 plugins currently installed on my network. Of those, three are ‘mu-plugins’ that aren’t so much plugins but sitewide functions, nine are network activated, and one is Hello Dolly. I average about 10 of the others per site, and I know that at least Hello Dolly is actually not used at all. Some sites are the only one to use a certain plugin (like the ‘Downloads’ plugin I use here), and others aren’t network activated but are used on many sites (like WordPress SEO and W3TC).

Even here on my network, I have different tools for different sites. Heck, one site has only one additional plugin activated on it!

So when you look at all that, you may wonder if there’s a plugin I can’t live without. The answer is a flat out no, but you’re not asking the right question.

What you need to ask is What features are required for my site?

When someone tells me they want help with their site and what plugins should they use, I tell them “You need to make a list of what features you need. Not want. Need.” There’s a huge difference between the stuff you want, to make your site look cool and neat, and the ones you require for the desired functionality. What a website needs is a way to display content in an easily absorbed way.

People forget the purpose of a website is for people to find your stuff, read it, and help spread the word. Now, if your ‘word’ is videos, then yes, you totally should consider a video plugin. But that’s a need, not a want. A ‘want’ for a video site is a fancy slideshow of New Videos. Look at YouTube, though. They don’t do that. YouTube knows they’re going to get a lot of traffic, so they pull things back to their purpose. They want to show videos, that’s all they do. Obviously they added in a couple wants, which are the ability to comment, vote, favorite etc. Those are pretty minor when you get around to it, in so far as they don’t affect site speed as much as the actual videos do.

For most blogs, you really don’t need plugins. If you pull your site back to the things you must have, you get a better understanding of what your site is. Once you look at your site ‘naked,’ with no plugins at all, you can start to add plugins back in.

Each and every plugin I add has to serve a purpose. Even my RickRoll plugin has a purpose (though its not something that would be on every site I make). The point of a plugin is not ‘Oh look, this is cool!’ but ‘How can it serve me best?’ If I can’t come up with a reason this makes my site better, and I am brutal with myself, I don’t use it.

If you’re going to have a website, it’s incumbent on you that you’re mean to yourself. You hear the horror stories of clients who want all sorts of crazy things on their sites, and there’s a reason a lot of us sit and laugh (and cry) when we read the Oatmeal’s How a Web Design Goes Straight to Hell. I push developers to fight back against the crazy, but you clients need to step up and understand that ‘more’ isn’t ‘better,’ and if you’re hiring someone to make a site, you really should listen to their suggestions and recommendations.

But the point in the end is that, to make a website, with WordPress, you need no plugins. What you want is another matter.

Assuming you are, how do we do find out who owns a site?

First, remember that when you see “Powered by WordPress” in a footer of a site, it is not, in fact, hosted by WordPress. This site says “Powered by WordPress” but it’s hosted by Liquidweb. Now if you see “Blog at WordPress.com”, then yes, it’s hosted by WordPress, and you can easily report the site. The same is true of Blogger, who also has a way to report copyright theft. Many of these ‘hive’ hosts do that.

LiquidWeb doesn’t, though. So, pretending for a moment that I’m a dirty thief, how do you find out who I am, my email, and get your content removed? And when I don’t answer, where do you go next?

Start With WHOIS

Your first tool is called ‘WHOIS’ and does exactly what it sounds like. It tells you ‘who is that.’ Network Solutions has a free whois lookup tool and if you were to search for Halfelf.org you’d get the following:

Registrant ID:bf39ab1b08df1394
Registrant Name:WhoisGuard Protected
Registrant Organization:WhoisGuard
Registrant Street1:11400 W. Olympic Blvd. Suite 200
Registrant City:Los Angeles
Registrant State/Province:CA
Registrant Postal Code:90064
Registrant Country:US
Registrant Phone:+1.6613102107
Registrant FAX:+1.6613102107
Registrant Email:28a9f8aa493149b1a58ff9b4c51e0bcd.protect@whoisguard.com

It goes on and on, but you may notice none of that is actually … me. That’s because I pay a wee bit extra a year for my host to hide my personal information via whoisguard. I do it becuase I had some idiot track me down to call me about how I wasn’t updating my website enough (a different site), and I now have a restraining order against him. ¹ Now that said, the last line I listed is Registrant Email and that email actually works! It’s a real email that will forward messages to me.

So step one with these things is email that address and hope the person answers. But when a week goes by with no reply, what next? Sadly, some people never check those emails, or they think you are spam, and ignore it. Thankfully, WHOIS will still save you! Scroll down to the name server entries!

Your nameservers are what translate your domain to the server IP address, and, as a rule, they have to point to where your server really lives. Generally speaking, a nameserver will give away either the registrar (i.e. who you registered your domain with) or the webhost (who you host with).

Mine are:

Name Server:NS1.IPSTENU.ORG
Name Server:NS2.IPSTENU.ORG

Doesn’t really help, does it? I mean, that just says ‘ipstenu hosts ipstenu!’ Here’s what I used to have:

Name Server:NS1.LIQUIDWEB.COM
Name Server:NS2.LIQUIDWEB.COM

That would have been much more explanatory. Thankfully you can use Who Is Hosting This? and run a search for any domain (like http://www.whoishostingthis.com/halfelf.org), even if they have their own name server, and you get this:

Well thank goodness we have some information! Look up LiquidWeb, and you can contact them. “Hey, this evil Half Elf is stealing my stuff!”

I prefer Who Is Hosting This to ‘Who Hosts’ becuase if you look me up on the latter, you get this:

Not useful (though accurate). If you keep getting nested domains, you have to keep digging until you find the end of the rabbit hole.

Really the best thing is always going to be whois, and once you get used to looking at it, it’s really not that scary. At the same time, I strongly suggest people invest in Whois Guard, or some other ‘protection’ to stop annoying people from getting their personal information. You don’t need the hassle of being listed in a phonebook.

In Part One I talked around what I did. Here are the themes I picked, what I feel about them, and what I loved and hated.

All three themes are frameworks, and I’m using children there of. Unlike just making a child theme from TwentyEleven, these are true, robust, themes, designed by artists. This took me maybe 10 hours of work, total, to do everything on all three sites, and as most of that wasn’t me sitting down and concentrating, but multitasking and bouncing around, so it may have been 4 hours serious work.

Oh and all these themes are ‘premium.’ And worth it.

Origin – In use on Half-Elf On Tech

Origin was the first theme I picked, from DevPress, and I decided on it after playing with a bunch of different DevPress themes. I’m partial to them (and ThemeHybrid) because I’ve been using Hybrid Core since before it was released, and I know it. I’ve memorized the hooks, and I like being able to quickly spin up my functions.php for it. All the serious changes are done in a pretty small file, actually, and mostly have to do with inserting FaceBook and Google into the header and footer, my comments ‘rules’ and that cool clickable (and hoverable) asterisks in my site description. I also really like the ‘full page’ view, and used it on some of my content-only-no-comments pages like Licensing.

Since I have a mini rant later on about favicons, Origin lets you update the favicon right there in the theme settings.

This is especially important for Multisite installs, where each site will want their own favicon. Now I don’t need a plugin. And if anyone can think of a cooler favicon for this site than the Spock Eye, let me know.

Balance – In use on Ipstenu.org

Balance, from StudioPress, was next. This was a huge departure for me, and oddly it’s the theme I love the most and have the most issues with. Let me explain.

While I’m perfectly comfortable bashing away at a functions.php file, unlike Origin, Balance is a child theme. See, HybridCore is a ‘starter’ parent theme, where you make your own child off it. Balance is a true child theme. When I got it, it came with a copy of Genesis, which is the parent. So while with Origin I made ‘HalfElf Origin’, I couldn’t do that here. I would have to edit the Balance theme directly, which goes against my nature.

Back in the day when I used Hybrid News, Justin made a massive upgrade. I hated it, as I’d made all sorts of tweaks to the theme, and it was a bitch to fix. Now, I happened to agree 100% with the choice to make those changes, you had to upgrade the menus for WordPress 3.0, but it was painful. This sort of hassle scarred me for life. I don’t like to edit themes directly. So I pinged Andrea and asked her ‘How often do these themes update? She said ‘rarely’ which isn’t the same as ‘never’ and, while calming, wasn’t the best thing in the world for my neuroses. ¹ Personally I’d love to see Genesis go the same way that Hybrid did, and to make a ‘core’ that is included in all their themes. Then Balance would include all the files for Genesis and Balance, and people could happily make their own children.

With that in mind, I did a smart thing. Instead of editing the child theme, I made two files: ipstenu.css and ipstenu.php (I told you I’d get back to why there was no style.css ²) and put them in a fake theme folder called ipstenubalance. Those I included into the style.css and functions.php of the actual child theme.

Calling the CSS was easy:

@import url("../ipstenubalance/ipstenu.css");

And the special functions is just this:

require_once( get_theme_root() . '/ipstenubalance/ipstenu.php' );

Now all I have to remember is that if the default style or functions gets edited in Balance, to re-add those calls in.

The reason I dislike Balance, however, is not my own personal issues (and I’m well aware they’re just mine). It’s that there was a favicon forced on me. I hate that with a passion. You see, everything else is really a small change. I want a larger font, a darker blue, a bigger curve. But a favicon is … your site is naked without it. And it should resemble who you are. That’s why I have my ‘me’ image as my favicon most of the time.

But at the same time I love Balance, because I was able to overwrite the favicon with this:

remove_action( 'genesis_meta', 'genesis_load_favicon' );
add_action( 'genesis_meta', 'ipstenu_load_favicon' );
function ipstenu_load_favicon() {
	echo '<link rel="shortcut icon" href="http://ipstenu.org/favicon.ico" />';
}

Other than that, Balance is my first go-at with a ‘managed’ theme, and I have to say I’m really astounded. If you didn’t know anything about functions and hooks, you could still make this site (in fact, I did, via a Genesis Hooks plugin). It’s crazy customizable, without feeling clunky. And yes, some of the other ‘pro’ themes I looked at felt that way. StudioPress impressed the hell out of me. If you need a ready-to-go theme and don’t want to mess around with code, StudioPress is the way to go. They set the bar for parent themes. And like Origin, they too have a full-screen template, which I used on my terms of use. I suppose this is why the don’t go the route of Hybrid Core. Most of their users aren’t going to play with child themes, and instead will use the built in features, or the Genesis Plugins to customize things from the WordPress admin dashboard. ³

It’s a step ‘back,’ in terms of me being a developer, but at the same time I feel a burden lifted when it comes to managing things. A strange balance. ⁴

Dotos- In use on Ipstenu.Photos

The last one was for my Photo site, Ipstenu.Photos, and I wanted it to look like a photoblog. This was really easy, since as Dotos is also from DevPress, I could cheat and make a child theme called photodotos and copy my Origin functions over, renaming halfelf for photos. I did one minor css tweak on Dotos, and that was to hide the ability to comment on photos. Didn’t want it or need it. I have a lot less to say about it, since everything I said in Origin applies here, and I did less tweaking.

So there you have it. My sites got a facelift, and I’m so happy, I load them up just to smile at how sexy they look. My site feels bright and new, and I want to blog more. And that is a win, no matter how you look at it.

Redesigning a site is not to be taken lightly. As I mentioned before, too many changes confuse your visitors. For the last few years, I’ve kept my sites pretty much the same, and this is normal for me. I mean, look at the designs for JFO! Clearly I find a style and stick by it. I don’t consider myself a ‘theme designer’ person, either. I can tweak the hell out of a theme, but inventing them? No way. I’ve never been very good at the part of art where I’m supposed to take an idea and make it visual. Oddly, I can do it with words and ‘people’ (think directing a play), but while I can see these things in my head, putting it down on paper fails me.

So why the dramatic change from everything the same to everything different?

There’s a theme through these themes, actually. They’re all simplistic, focusing on the content in a way that I can, easily, shove the sidebars out of the way when needed, and showing you what’s important. I didn’t want to get distracted by bells and whistles, but I also wanted a theme that was easy to tweak. Ipstenu.org I wanted to look a little more grown up, Half-Elf needed to be more professional (but still as irreverent as I am ¹), and my photos needed to be about photos and nothing more. I also didn’t want to fuss with colors too much, they can be a big distraction, and just putting up a black/white with accents felt ‘right.’

Once I committed to simplification, I cut down my menus while keeping them similar to what they were, and I kept my favicons as they were (though Half Elf has been sporting a Spock eye for a week now). Menus are tricky. You want people to find what they want, quickly, but you also want to guide them to where you want them to be. By cutting down the clutter, and having a little down-arrow on menus with drop-downs, I can gently nudge people around.

Buzz-words annoy me, and I try to avoid terms like ‘call to action’ whenever possible. Instead I thought of as the purpose. I like using ‘static’ content on front pages for that, as they can explain why you’re here, show you what’s new, and grabs you. The new Half-Elf page really does that, with the big honking ‘ad’ for the book. The haiku keeps you thinking ‘This is Mika,’ and the rest confirms that. On Ipstenu.org, the sales pitch is smaller, but you still have a little ‘who am I?’ blurb to get you started. While I wanted it to look grown up, I really felt the ‘feel’ of me had to stay. That’s the only site where you’ll see my Twitter stream, for example. As for the photos, well, they were simple.

I drew out what I saw in my head on paper a few times. A header, a menu, a ‘grab you’ blurb, and the content. It’s a good layout for me, I felt the eyes naturally flowed. Sorting out where on Half-Elf to put that ‘recent post’ inset was tricky, as I wanted it to be ‘above the fold,’ if you’ll pardon the archaic reference. Speaking of, all these themes are ‘responsive’ so if you shrink your browser, they adjust. Except for the leaderboard ad in the footer. I need to sort that out. ² This does not contradict my drawing deficiencies I mentioned before, by the way. When I ‘drew’ my layout, what I did was grid it out. That part wasn’t ‘art’ and I didn’t try to make anything pretty. I just made a list of what the themes needed in black, what I wanted in blue, and what I knew would be custom work in red.

I ended up with three premium themes that I’ve added functions and style to, but that’s it. While I may have made child themes, there’s no duplication of code. That is, my child themes have two files (functions.php and style.css) and possibly some images. That’s. It. halfelforigin is the child for Half-Elf, ipstenubalance is for Ipstenu.org, and photodotos is for the Photo site. The first half of the name is the site, the second half is the theme. I’ve always done it this way, which is why I also have an ipstenu2011 folder in there.

Oh, and why does the ipstenubalance not have a style.css? We’ll get to that.

But that will have to wait for the next post, where I break down each theme, what I liked and disliked, and what code I wrestled with. It’s a little longer than this post, which is why it’s split up.

By the way, the title is thanks to Ryan, who took my joke seriously.

@helenhousandi Giving WordPress That New Car Smell? No, too silly.

— Ipstenu (@Ipstenu) April 19, 2012

@Ipstenu @helenhousandi I would absolutely read a post/listen to a talk entitled “Giving WordPress That New Car Smell”

— Ryan Giglio (@ryangiglio) April 19, 2012