Why does OS X's Apache server give different results using real and virtual addresses?

I'm developing a WordPress site on my Mac, running OS X 10.6.4. I'm using OS X's built-in Apache server to run the site locally during development. I've set up WordPress and connected it to OS X's MySQL with no problems. The site seems to work fine, and I can post, edit, etc.

The WordPress installation is in a folder called ~/Sites/mysite.dev.

I've also customized my .hosts file and Apache's httpd-vhosts.conf file, to redirect requests for mysite.dev to this folder. So when I enter http://mysite.dev in a browser window, the site loads. No problems here.

So I can access the site, in a browser, from two different addresses, http://mysite.dev, and http://localhost/~Gabe/mysite.dev/.

Here's what's weird: When I go to http://mysite.dev, the WordPress site loads normally. When I go to http://localhost/~Gabe/mysite.dev/, WordPress can't find any posts from the database: It gives me the "Sorry, no posts met your criteria" message (which is built into the theme for when a search for posts returns nothing). N.B.: Apache processes the PHP code normally in both cases -- but in one case WordPress can get posts from MySQL, and in the other case it can't.

My first thought was that this was a problem with WordPress's configuration, so I changed the WordPress URL to http://localhost/~Gabe/mysite.dev/, but this made no difference.

I don't understand why using the two addresses produces different results. Any help appreciated.

(Here's why I care, in case you're wondering: I want to preview the site in BBEdit's web preview window, and BBEdit will only load the site via the http://localhost/~Gabe/mysite.dev/ address.)

Solution 1:

This is not a problem with OS X or Apache. A redirect doesn't change any PHP code behavior and since you apparently get response from the code, nothing is wrong with the server setup. The problem lies in the way Wordpress reads the domain name from the request (which is the only thing that should differ) and what it does with it.

Solution 2:

I was able to solve this problem—it turns out that WordPress behaves better when I set both the WordPress address and the site address to http://localhost/~Gabe/mysite.dev/.