By using the_excerpt(), wordpress will automagically use the except text from your post or it will use the first 55 characters provided you don’t have any text in your excerpt. For someone like me who doesn’t like to use arbitrary “more” tags, this method is great. You can alter the number of characters displayed as well as make other customizations. The codex for the_excerpt() can be found here.

I like using plugins to get thins done in Wordpress, but oftentimes some simple and straightforward coding is the simplest and fastest way to go.

Here’s the short version of why you are getting this browsershots robots.txt error and the solution:
Because you are developing a test site for a client, you are naturally going to have a disallow statement in the robots.txt file in your live development directory. Because you have a disallow statement, browsershots can’t access the directory to create the preview files. Thus, what you need to do is to temporarily change the robots.txt to allow browsershots.org to access the specific directory where your site is located. Once browsershots finishes its work, you can then go back and revise your robots.txt file to its original disallow statement.

Below is a more detailed explanation of this concept:

Background
The robots.txt file is a proverbial “gatekeeper” that tells a search engine spider what directories it can and cannot index. Some search engines do not respect the instructions in the robots.txt file, but most engines such as Google currently do appear to respect these instructions. In general, a production website would have a robots.txt file in order to make sure that spiders are able to find content in the site.

In addition to “telling” the web spiders what they can look at or index, the robots.txt file can also list what spiders shouldn’t see. Let’s look at an example:
Assume you have a web site with a root, /, a /content and a /development directory, and you only want the search engines to index the root / and the /content directories, but not the /development directory.

You could write a robots.txt file that looks like this:

User-agent: *
Allow: /
Disallow: /development

Real-World Example
Moving back to how robots.txt affects Browsershots.org, and causes you to get an error, realize that most web developers have a domain they use for testing so they can put development versions of websites online for clients to see. Because the test site is online and live on the internet, albeit on a test domain and not the client’s actual domain, Google and other search engines may pick up this development site and index it on search engines — especially if you leave the test site up on the test domain for a while. While you eventually want to have your clients site indexed, you do not want a search engine indexing a clients development website. Imagine if you are building a website called helpspa.com (what a great idea), and when someone searches for helpspa.com on Google they get directed to www.developersite.com/test/helpspa.com — you will not have a happy client!

Thus, in order to leave the test site up and allow the client to see it, but at the same time prevent Google and other search engines from seeing this test site, you would create a robots.txt file that blocks the test directory. So using the example above, you can just replace the directory you wish to block from search engine spiders in your own robots.txt file, and then make sure that this copy is the one one the server. But now when you go to browsershots.org, you will get an error about browsershots not being able to access the site. Thus, you’d go back into the robots.txt and make sure that you remove the disallow or modify the robots.txt so that you directory is available for browsershots to view. Then when browsershots is done, just remember to change the robots.txt file back to what it was with the disallow statement.

To give you an example of how I do it, I have a test domain for my client sites. I’ll make up a name here but the concept is the same. Here is the directory structure

www.myfictitioustestsite.com/client1
www.myfictitioustestsite.com/client2
www.myfictitioustestsite.com/client3
www.myfictitioustestsite.com/client4

I have a robots.txt that looks like this:

User-agent: *
Disallow: /

In this manner everything is blocked from search engines while I work. If I want to use browsershots to test the development site for client 2, I’d have something like this

User-agent: *
Allow: /client2
Disallow: /

So that’s the story — let me know if you have any questions.

The Big Picture. I run Windows Vista where I can test IE7, Firefox and Opera.  I run Microsoft Virtual PC 2007 in Vista with an XP VM that runs IE6.   I run a wamp server in Vista, and my XP VM install uses IE6 to access the “localhost” wampserver on Vista.

Goal: so in this tutorial we’re going to setup an XP virtual machine in Microsoft Virtual PC that we are going to use to run IE6 and subsequently “see” the Vista localhost apache server to test our sites.  In our XP virtual machine we are going to setup (2) network connections.  The first one will be the loopback adapter which will allow the Virtual PC to “talk” to Vista.  The second will be a shared usage of Vista’s network adapter so the XP VM can have internet access.

I like to set these up as two separate adapters because:
1.  I don’t always need (or want) to allow the VM to have internet access.  I turn on the internet network connection to download what I need, and then I turn it off.  For security (even though I run security software on the VM), there’s no need in my opinion to  let the VM have full-time internet access.
2. This way I can always leave the loopback (XP-to-Vista) on without having to worry about unmonitored internet traffic.

Here’s what you’ll need:
1. Microsoft Virtual PC
2. XP Virtual PC Image – note that Microsoft will disable the functionality of this image January 1, 2010. My guess is that if the demand is still there they will issue a new XP image for developers to use.
3. Wampserver (unless you already have an apache/php/mysql environment already setup).

Pre-Configuration Steps:

1. Download and install Microsoft Virtual PC 2007, get the XP Virtual PC image and setup the image in Virtual PC.
2. If you already have an apache/php/mysql environment running on Vista, go ahead to the next section. If you don’t, go ahead and install wampserver now.

Setting Up the XP Virtual PC to See the Vista Localhost

These steps assume you have already installed Virtual PC, the XP image from Microsoft, and have a wamp server running on Vista.

1. Install the Vista loopback adapter. The loopback adapter lets the XP VM and Vista to talk to each other. You can install the loopback adapter as you would any other new device. You can go through the add hardware wizard from the Vista control panel, elect to manually select a device, go to network adapters, find Microsoft in the left pane, and then loopback adapter in the right pane. Go ahead and complete the wizard.

2. Set a Static IP on the loopback adapter (in Vista). Go to the Network and Sharing Center, Manage Network Connections, and find the loopback adapter. Go to properties, and under TCP/IPv4 settings, set a static (non-dhcp) ip address. I like to use 192.168.25.1 (you can pick whatever you like — but since most networks work with 192.168.1.1, I like to keep the loopback adapter totally separate).

3. Go to the XP VM and configure the two adapters. Before you load the VM, go to the Virtual PC console and edit the settings for the XP VM (again — before you run the VM or while you have it not running). Make sure you have 2 network adapters configured (you can have 4). The first one should be “Microsoft Loopback Adapter” and the second one should be whatever your system’s regular network connection is (you can pick your wireless or your wired connection — I prefer to use the wired).

4. Configure the Two Adapters in the Virtual Machine In the network connections find the loopback adapter (remember we are in the XP VM now, and not in Vista) and change it to a static IP: 192.168.25.2. You shouldn’t have to configure the second adapter (the wired or wireless one from your computer) as it should already be set to DHCP.

5. Test that Vista can see the XP VM, and that the XP VM can see Vista.
a. In the XP virtual machine, ping the loopback adapter in Vista: 192.168.25.1. If successful, this means that the XP VM can “see” the Vista apache server.
b. In Vista, ping the “XP Loopback” adapter (remember you setup the loopback adapter in Vista, but the XP VM has an instance of this loopback adapter): 192.168.25.2. If successful, this means that Vista can “see” the loopback connection in the XP VM.

6. Tests and Finishing Touches.
a. Check that you can get a regular internet connection in the VM. It should work as long as you have the second network connection (the shared one) enabled.
b. On the Vista machine first test that the wampserver is running and that localhost is working. Make sure that wampserver is set to “put online”.
c. Now, (finally) test that the XP VM can see the apache localhost by going to a browser in the XP VM and typing: 192.168.25.1 . You should be able to see the same localhost page that you got in step 6b.
- If not, the problem may be the way Vista configures networks. Go to the Network and Sharing center and find the loopback network (you probably will see your “regular” wired/wireless connection and your loopback-based connection probably “unidentified network”). Go to “customize” this network and select “Private” network.

7. Know Issues/Reflections
a. Sometimes Vista seems to “forget” that I set this network connection as Private. So I do need to go in to the Network and Sharing Center and re-configure the connection so that it’s Private and not Public.
b. You must remember to turn on the wampserver, and to have the wampserver set to “Put Online” mode. You may want to put it back to “Put Offline” when you are done.

So there it is. It’s takes a few steps to get it right, but once its configured you have a great IE6 sandbox as well as an XP VM for any other testing you need.

Addendum: If you are running Windows Vista (and therefore IE7 or IE8), and want a way to test IE6 sites on your own machine, see this post about how to test IE6 websites in Vista using Microsoft Virtual PC 2007.

One of the most important parts of this testing is selecting which additional browsers to test sites on, and this determination really depends upon the requirements of the client. As much as I’d prefer to eliminate IE6 from the mix, many corporate environments still run on IE6, and asking them to upgrade hundreds or thousands of machines because I don’t want to code for IE6 is simply not acceptable.

There are times, of course, where a certain web application won’t run in a certain browser, but again — that fact just underscores the importance communicating expectations with your client ahead of time.

It’s easy to test on IE7 and Firefox, and also easy to test on IE6 if you have an XP machine that still has IE6. Because it’s extraordinarily difficult to run IE6 and IE7 at the same time on the same machine, I don’t advise trying to run them both on one computer. A terrific option to ease your development process is to run IE7 and Firefox, and then run IE6 in a Virtual PC Windows XP setup. Having all three browsers on one machine is very helpful, as it obviates the need for you to upload the files to a local network and then move from machine to machine to test.

Other than the browsers mentioned above, I don’t believe it’s practical to setup a Mac and a linux box just to test the litany of additional browsers that are out there . Because I want to see what the sites look at in practically every browser I can possibly test in, I use a website called Browsershots to help out. Browsershots is a site that will take screenshots of a URL that you enter; once the screenshots are created you can view them and get an idea of how a site looks.

Browsershots.org lets you choose the platform and browser combinations that you want to test your site on, and includes options for screen resolution, javascript and flash, too.

Note that if you have a robots.txt file that is set to DISALLOW, you will need to temporarily remove this directive (or swap in a robots.txt file that isn’t restrictive). Because I publish preview/test sites for my clients on a development domain, this domain always has a disallow directive, as I don’t want this test site being indexed by Google or other search engines.  Naturally I first finish developing locally on the above browsers before I upload the site to do additional testing on Browsershots. And don’t forget to restore your original robots.txt file once you are done testing!

So generally speaking, if your site looks good in IE6, IE7, IE8 and Firefox, you can feel pretty comfortable that your site looks good.   But you want to take that extra step (that I naturally like to do), Browsershots.org will let you take a peek at screenshots of your site without having to setup a ton of develpment environments.

The problem you get is that while viewing a site with Internet Explorer only, you see the last letter, letters, or words of your text in the wrong place on the page. If you test the site with firefox or opera, there’s no problem. So why is this happening?

The reason is because Internet Explorer doesn’t do well with too many HTML comments in one area. If you are using Dreamweaver Templates, Dreameweaver adds comments to delineate the template region starting and end points. Now if you go ahead and add some more commented text (e.g. for notes for yourself, code notes, or even just content that’ s ‘on hold’ for now), IE will incorrectly render the text that is nested within the comments.

The solution is to one by one, remove some of the HTML comments. You can try to combine them if possible, or put the comments elsewhere. Once you remove enough of the comments (e.g the actual tags –>, you will find that the text now displays normally.

It’s a frustrating bug to figure out, as you’d never expect that comments (which I encourage people to OVERuse), are the source of the problem!

Option 3: Use ASCII Characters
So for the quick and dirty solution, I used the ASCII code for the bullet and placed it in front of each item in the list in my table. The ASCII code (entity number for HTML) for a bullet is: &8226; . Some argue, however, that is it is better to use the entity name for special characters instead of the entity number. The entity name for the bullet is:  •.

Here is an example (I’ve omitted the table and tr tags for brevity):

<td>•Your Text Here<td>

The drawback of this approach is that using ASCII codes may not be visible in browsers that are not using the standard set of English/Western European (Latin) character encoding.

It’s up to you to decide which solution is best for your specific site and audience, noting the advantages and disadvantages of each method.