Category: WordPress

Following Ben Brooks’ lead, I’ve decided to replace my site’s search engine with DuckDuckGo. But all of the solutions he’s linked up have been a little fiddly and require editing your theme files. And while I’m okay with doing that, I realize a lot of folks probably aren’t.

So I pulled together this little bit of form code:

All you need to do is change “example.com” to your domain and drop the code in a text widget. Like this:

Easy, right? Now nothing is stopping you from using DuckDuckGo as your WordPress site’s search engine!

While helping someone with WordPress move earlier this week, I noticed a bunch of weird Unicode cruft (like ’ and –) in their posts and comments. Apparently, MySQL databases don’t like it when you switch their default character encoding. But different web hosts have different ways of doing things — so default character encodings can (and sometimes do) change while you’re moving a site around.

Anyhow, after a bit of digging, I found a really handy set of MySQL commands that fixed things up. But I like to save time, so I made myself a Gist for future use and decided to share it with y’all…

Hopefully someone else out there finds this useful! I know I’ll probably use it at least once or twice a week now that I’m doing a lot more work with MySQL imports.

Good luck!

Even though W3 Total Cache seems to have become the more popular and robust option for WordPress caching, I’ve stuck by and continue to recommend WP Super Cache.

Why? In a word: simplicity.

Now I could write a big long entry on why simplicity trumps a crapton of options and flexibility, but I’d rather have a look at the options screen for each plugin.

We’ll start with WP Super Cache:

This is all you see when you visit the settings page post install. If you really wanted to, you could just turn caching on and call it a day. Of course, you could (and should) go poking around under the hood a bit – so let’s look at the Advanced tab:

So that’s a bit more extensive — and in some places, downright nerdy — but all of the crucial options stay above the fold. Furthermore, the blue button after the first set of check boxes and radio buttons does a pretty good job of saying “this is where all the really important stuff ends”.

Now let’s compare that to the options that W3 Total Cache presents to users post install:

While that’s pretty straightforward, it’s also a lot for someone who’s new to the plugin to take in. Not only that, it doesn’t really make it all that clear what the user should try if they’re getting started.

Don’t get me wrong. This isn’t a me thing at all. As much as I could be a hater, I’m talking from experience here.

You see, I deal with a pretty significant number of WordPress users over the course of my work week. And there’s always a handful that are running W3 Total Cache that have enabled some combination of Varnish, CDN & CloudFlare. The only problem is, they don’t actually have access to any of the those services.

In most cases, they were told they needed to install a caching plugin, pronto. It’s not their fault if they’re taking a shotgun approach to using it. It’s the plugin author’s fault for not making things clearer.

So until W3 Total Cache gives end users a better out of the box experience, I’m going to keep running and recommending WP Super Cache. If you’re tired of being buried under an avalanche of options that you never use, I suggest you check it out.

Update: Frederick Townes responded on Twitter and claimed that W3 Total Cache was incomplete and sporting the “advanced” UI. Hopefully they’ll be able to roll out something a little more end user friendly soon.

So Google’s Page Speed Service looks pretty great – but if you get into the beta and upload a lot of media to your WordPress site, you’re going to run into a few snags. The cap for their caching proxy is currently set at 2MB. And while that’s fine for most folks, it’s not really going to fly for photobloggers and the like.

Fortunately, there’s a workaround…

All you need to do is create a subdomain (like admin.domain.com) and point it at your current WordPress install’s directory. If you don’t know how to do this, your web host’s support should be able to help you out.

Now you’ll notice that when you visit that new URL, you’ll get redirected to your main domain. WordPress needs to know to not do that, so just add this code to your “wp-config.php” file:

define('WP_HOME', 'http://'.$_SERVER['HTTP_HOST']);
define('WP_SITEURL', 'http://'.$_SERVER['HTTP_HOST']);

It doesn’t really matter where you drop it, but I like to put this sort of stuff after the MySQL information. Then just save out the file, kill your browser cache and try to visit your subdomain now.

So long as things don’t keep trying to redirect you, log into your WordPress Dashboard (admin.domain.com/wp-admin/) and you should be able to post and upload files without any issues.

Simple enough, right?