Unleash WordPress: Quick tips for effective images

(Reading time: 5 – 8 minutes)

An effective image can make a good blog post great. An ineffective image always reduces the impact of of an article. Part of an image’s effectiveness is making sure it’s the correct size such that all the necessary information in the image is clear to the reader.

Does that sound complicated or vague?

It’s not, really, but it’s not often discussed either… which is your opportunity to get yet another advantage in your WordPress skills.

Image scaling considerations

Bitmapped images such as bmps, pngs and gifs typically don’t scale well. Such images are best viewed at 1:1 scale. That is, each pixel of the image corresponds to a pixel on the viewers screen. At smaller scales, pixelation becomes apparent and ugly. At larger scales, linear elements such as letters and lines start to get jagged. But at the right scale, close or at 1:1, bitmapped images are superior to modeled images such as jpgs which have artifacts radiating away from linear elements.

The reason for both these effects is mathematical. In the case of bitmaps, reducing the size of the bitmap forces arbitrary sampling of pixels. In the case of modeled images, the mathematical model provides the artifacts.

When you can, provide the reader or viewer with bitmap images at 1:1 resolution… such that the image fits conveniently into your text or display location. Here’s how.

Each block element in WordPress has either a declared width, or a computed width implied from a declared width. Find out these values:

  • main column width
  • padding and margin widths

then make your image the same or very similar in size.

How big are your blocks?

One way to figure out block sizes is to use the Firefox extension Firebug, which will allow you to measure the width of each element on a web page. These are the values you want to use in your image editing program for cropping down images, or as discussed shortly, in your screenshot program if possible.

In the image just below, you can see the 480 pixel width of the current Thesis text column outlined by the red box, pointed to by blue arrow [1].

Grab the width of your text block using Firebug extension for Firefox

Grab the width of your text block using Firebug extension for Firefox


As it turns out, I could determine this using the Thesis options menu as well, which is another great reason to use Thesis, but examining the delivered content is applicable to any theme (or any web page). You can also examine the raw CSS file, often available using “View Source” (Ctrl-U) from your web browser, then clicking on the CSS link in the document head. In the case you have a fully fluid layout, you will have to determine what your minimum image size will be. There’s now way around it. If users want to read your site at some ridiculous 100 pixel width, well, that’s not your lookout.

Resizing your image

You have two good options dealing with an arbitrary image: 1. resize the image in your image editing program (not MS Paint), which is almost guaranteed to have better algorithms for reducing bitmaps than any web browser, or 2. crop your image effectively to fit your final width. (Or both.)

With very large images such as photos, I typically scale them down by half to get them fully onto the screen, then crop them down to size. If the whole image is useful, or the cropping is very small, I’ll often reduce the size of an image by 75-80% for web display.

When your image is a screenshot, you can’t get away with nearly as much reduction as when it’s a photographic image. First, the screenshot is going to be at 1:1 with your screen already, and second screenshots typically contain a lot of sharp lines, which look crappy when reduced. In these cases, try (hard) to take exactly the screenshot that packs the exact information, no more and no less, into the smallest space possible.

My usual solution for screenshots is using a dedicated application, Jing, which I’m happy to tell you about right now.

Jing makes screenshots much easier

Techsmith’s Jing is a pretty good piece of gear. It fits into that category of “small tools” or “little languages:” it does one thing and does it well. Actually, it’s two things (video and screenshot), but just consider a single screenshot as a single frame video, and we’re back to that one thing again. Jing has two huge advantages for taking rapid screenshots:

  1. Screenshots are what Jing was expressly designed to do.
  2. Jing gives you exactly the tools you need simple annotation, and no more.

Jing is a free download with a professional upgrade and comes to you courtesy of the fine folks at Techsmith. Get your copy of Jing now. (Note: I am not affiliated with Techsmith.)

Jing doing it’s screenshot thing

When you take your screenshot using Jing, watch the width of the sizing or cropping rectangle. Crop your screenshot a little narrower to account for margin, padding (10-20 pixels is usually fine if you want to wing it.) Here’s a much larger screenshot taken using Windows Vista showing Jing in action. The lighter area bounded by yellow border is the cropping window; the darker areas are outside Jing’s screenshot. Jing’s sizing box is down in the lower right corner of the yellow guidelines. It’s solid black and shows the outlined screenshot would be 622×299 pixels.

Jing doing it's thing

Jing doing it's thing


In this case, it was difficult to fit everything necessary for illustrating this article into the 480 pixel width of this column, so the screenshot is considerably wider. These things happen. Note that the first screenshot was taken with Jing, and it’s 470 pixel width fits very nicely in the center of the 480 pixel column.

Adding images and screenshots isn’t difficult, but really nailing it takes a bit of practice and thought. Think about exactly what you want to communicate with each image, either information or emotion. Images communicating information need supporting text, and may benefit from annotation. For images providing emotional context, supporting text isn’t as important. But add captions in both cases.

Leveraging Localhost WordPress for Learning Webmaster Skills

(Reading time: 10 – 16 minutes)

Long time readers know I run several testing installations of WordPress right on my own computer. This is colossally useful for a number of reasons:

  1. New versions of WordPress are easily installed and tested
  2. New plugins and themes can be developed and tested.
  3. Reduces risk of destroying production installations.
  4. And finally, I can learn new skills in a safe, no-risk environment.

If you have been following along in this series, you will have installed Apache, MySQL, PHP and WordPress independently from separate installer packages, and your configuration should be very close to mine. You should have a working WordPress installation, which means MySQL and PHP work essentially correctly.

As it turns out, your Apache configuration is going to be bare bones, and set to very strict default behavior. This is a good thing. Better to learn how to relax your web security incrementally, than to get your web security beat upside your head by malicious exploits. Of course, running from localhost, it’s not that big of deal… if you get hacked you can just get off the network and deal with it. Thus, in addition to WordPress, we’re going to learn some Apache magic as well.

Quick subdomain setup for Windows Apache Localhost

Suppose you want to move a WordPress installation from one subdomain to another. You will need to know something about setting up subdomains, which is the topic of this section.

Setting up a subdomain on your locally hosted Apache webserver is not difficult. There’s plenty of material on the web explaining exactly how to accomplish this task… for specific and different combinations of Apache and Windows versions. As usual, none of these explanations fit my situation exactly. Most likely, none of them will fit yours either.

So here’s mine, which you can use as yet another resource. I’ll add some links I used for reference at the end of this section.

What you need to know:

  • How to use a plain old ASCII text editor. I use XEmacs. You can use Notepad or whatever you want. Just make sure you stay in plain old text.
  • Where your Apache webserver is installed. Mine is installed in C:\Program Files (x86)\Apache Software Foundation\Apache2.2\. You may be using XAMPP, which is fine, these instructions will be adaptable to your situation.

    I’m going to refer to this location as APACHE_DIR for the rest of this article.

Here’s the steps for creating a subdomain:

  1. Create a subdirectory. For example, APACHE_DIR/htdocs/wptest. Creating a directory or folder should be easy for you. If this is confusing, leave a comment below.
  2. Edit Apache config to add the subdomain. This part can be a little tricky; you need to know something about how configuration in general works. We’ll take a detailed look at this in the next section.
  3. Edit the Windows /etc/hosts file. Again, could be a little tricky. There are a couple of ways to set this up, I’ll discuss in detail below.

Add subdomain to Apache httpd-vhosts.conf

As mentioned, everyone’s installation is going to be slightly different, so the best I can do is walk you through exactly what I did for my installation.

First, open APACHE_DIR/conf/httpd.conf. Find the lines that look like this:

460
461
# Virtual hosts
#Include conf/extra/httpd-vhosts.conf

You want to uncomment line 461, such that you are including conf/extra/httpd-vhosts.conf.

Now open APACHE_DIR/conf/extras/httpd-vhosts.conf. Make sure you’re serving from the correct port, in my case 8080:

17
18
19
# Use name-based virtual hosting.
#
NameVirtualHost *:8080

I have a couple of virtual examples in my conf file, which I’m going to comment out. Below those commented out sections, I added the following (Note: your line numbers will likely be different):

44
45
46
47
48
49
50
51
52
53
54
55
56
<VirtualHost *:8080>
    ServerAdmin admin@localhost
    DocumentRoot "C:/Program Files (x86)/Apache Software Foundation/Apache2.2/htdocs/"
    ServerName localhost
    ErrorLog "logs/error.log"
 </VirtualHost>
 
<VirtualHost *:8080>
    ServerAdmin admin@localhost
    DocumentRoot "C:/Program Files (x86)/Apache Software Foundation/Apache2.2/htdocs/wptest"
    ServerName wptest.localhost
    ErrorLog "logs/wptest-error.log"
 </VirtualHost>

For my configuration, I need to have my root directory set up explicitly as a VirtualHost. Otherwise, only the wptest subdomain works. Note that I added a specific error log for wptest. This is for my convenience, the webserver doesn’t care.

Use your own email address for ServerAdmin of course.

Adding to Windows etc/hosts

This is an easy step. Your hosts file should be located in or very near C:\Windows\System32\drivers\etc. Open this file in Notepad and add a single line:

127.0.0.1  wptest.localhost

Restart Apache.

Now, if you used “wptest” as your example as I did, you should be able to click the link http://wptest.localhost:8080/ and it will take you to your new subdomain.

Related links for localhost subdomains

These are the articles I used for reference, you should use them too:

  • Team Offshoot on Setting up localhost subdomains
  • Here’s Jared Hocutt’s article setting up subdomains on localhost.
  • After you have read the previous two links, and after you have your subdomain working, go read the official Apache VirtualHost documentation. There is more there than you probably need to know… but you should get familiar with what you don’t know.
  • Zaib Kaleem has an outstanding little article on moving a blog from a subdomain to your main domain. He points out to remember fixing the author’s URLs as well as to update the uploads URLs. There’s another article on the WordPress Codex that covers the same process from a slightly different perspective. The reader will find it easily using Google.
  • RajeshPG.com shows how to move WordPress from root to a subdirectory. This is a pretty good article, which I saved as a pdf for future reference. NOTE: I haven’t checked this article for accuracy, but the information is good enough that I could fix any typos, blunders or small errors easily.

How to move a blog using .htaccess magic

Suppose you have (as I do) a directory you want to rename from “wp28″ to “wordpress28,” perhaps as illustrative example for your blog. Or whatever. Bradley Charbonneau provides a distinctly telegraphic procedure for moving WordPress between subdirectories, which works fine for me, but bears a bit more in-depth examination for some readers.

So you’re moving a bunch of stuff around, say, like a WordPress blog… using .htaccess. Lot’s of wonderful tutorials on the web on rewriting URLs. For our example, the following .htaccess file handles the move:

1
2
3
RewriteEngine On
RewriteBase /wp28/
RewriteRule ^(.*)$ http://localhost:8080/wordpress28/$1 [L,R=301]

But no matter what you try… NOTHING works. Not even a little bit. Are you going crazy? Maybe, but there may be a simpler answer. Open up your httpd.conf file. Does it look like this:

114
115
116
117
118
#LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
#LoadModule proxy_http_module modules/mod_proxy_http.so
#LoadModule rewrite_module modules/mod_rewrite.so
LoadModule setenvif_module modules/mod_setenvif.so
#LoadModule speling_module modules/mod_speling.so

So, (my) line 116… you need to uncomment that if you want to use .htaccess for rewriting (which is what you want to do). Then make sure to restart Apache!

Did that do the trick? No? Ok, time to dig deeper.

Check the latest entries in logs/error.log. If you see an error similar to this:

[Mon Jul 20 12:38:19 2009] [error] [client 127.0.0.1] client denied by server configuration: C:/Program Files (x86)/Apache Software Foundation/Apache2.2/htdocs/wp28/.htaccess

you’re dead in the water.

But it’s easily fixable, if you know exactly what to do.

The operative phrases here are “client denied by server configuration” and “.htaccess.” Succinctly, you will need to allow Apache to use .htaccess to override default configuration that denies .htaccess usage. It’s not difficult, and there’s a couple of ways to do it. The first way is making the override global. That’s fast and easy, but not as secure. The second way is to override on a per-directory basis, which is what we’re going to do here:

1
2
3
4
5
6
<Directory "C:/Program Files (x86)/Apache Software Foundation/Apache2.2/htdocs/wp28">
    Options -Indexes FollowSymLinks
    AllowOverride AuthConfig FileInfo
    Order allow,deny
    Allow from all
</Directory>

Line 3 is the key, and the AuthConfig and FileInfo options will do what we want, namely, allow the redirect from wp28 to wordpress28. Add another one of these Directory modules for wordpress28 to enable permalinks for wordpress28 directory. Otherwise, you will be able to write the .htaccess file, but Apache won’t read it.

There’s even more…

If you’re run a cPanel-hosted site, you can change all the top-level redirects by doing a search and replace in the .htaccess for that site. Here’s the steps:

  1. Log in to cPanel, click on the “Redirects” link. You probably already know how to do this; if you’re changing redirects, you had to put them there in the first place right?
  2. Back up your current .htaccess file. I do it like this: .htaccess → .htaccess_todaysdate.
  3. Use your FTP program to download it for local editing, or edit it on the server if you feel brave. If you have a number of websites, you may already have flock of .htaccess files lurking, so editing on the server helps reduce the confusion.
  4. Do a search and replace to fix all the new URLs. Upload the new .htaccess and test everything out. Refresh your cPanel Redirects page to ensure everything works. That’s it, you’re done!

Giving WordPress it’s own subdirectory

Perhaps you would like to put all your files in a subdirectory, but have WordPress operate from the top level of the domain. For example, you want mycooldomain.com as your URL, but you want to keep all the files safely tucked away in mycooldomain.com/main1 (don’t ask).

This is so easy and common that the WordPress Codex has just the procedure for you: Giving WordPress Its Own Directory.

That’s great if you are just starting out.

But suppose you have a blog that’s been in operation at mycooldomain/main1 for a long time, with dozens of hundreds of posts and pages, and great search engine results. You need to do a little more work to capture all the results going from the old URL to the new. John Godley’s Redirection plugin is just the ticket.

The idea is to set up a new redirection using regular expressions. Using the directions on the Redirection home page, here’s what it looks like:

Setting up redirection regular expression

Setting up redirection regular expression

It’s not difficult, and using your localhost installation for testing is smart.

One last thing: If you already have a sitemap generator installed, such as Google XML Sitemap, make sure you update the location of the resulting sitemap. If you do not, it will attempt to write the sitemap into your old location, and may fail.

And, when you do this “for real” instead of on localhost…

Make sure you change your settings for Google Webmaster Tools!

You will want to ensure the new sitemap uploads and is valid, then you want to examine the details to ensure all the URLs are correct. If you have your redirections set up properly, you may want to leave the existing sitemap in place for a while, until the new one is indexed. Don’t forget about your RSS feeds, feedburner, and URLs you may have in any other places.

Themes, plugins and more!

Having a localhost installation makes it easy and safe to test new themes and plugins. Your new plugins can meddle with the database with impunity. If you crash it or corrupt the database, no problem, just reinstall or re-import a testing database.

With themes, you can go wild with CSS and formatting and nobody will ever see how terrible it looks.

Other advantages of running a localhost webserver:

  • It’s easy to dig into Apache configuration, and no-risk when you mess it up (and you will mess it up).
  • Learning to handle various HTTP issues such as 404 errors and 301 redirects gives you a lot of power on once you apply your newfound knowledge to your production server.
  • You can develop entire maintenance procedures and scripts locally, testing and debugging before deploying live.

So if you haven’t installed a local webserver, block out a couple of hours and jump in. It’s not difficult, and your knowledge will pay you back in the future. Even if you have no plans to be a “professional” web developer, the more knowledge you have the easier it will be to outsource exactly what you need… without getting ripped off by unscrupulous developers.