Around the time that I upgraded this blog to WordPress 3.1.3 with the WordPress.com Stats Plugin version 1.8.1, I began noticing that I could no longer view the stats graph for individual pages properly. My overall site stats still displayed, such as the total Views per day graph of my site, the Top Posts & Pages with correct view counts, etc.
However, when I clicked the small graph icon to view the stats graph for individual posts, I would get a blank graph and the error message “We don’t have that post on record yet” followed by the post id. Similarly, when I logged into wordpress.com to check my blog stats using their interface, the title for the posts would be missing (it would only show the post id followed by “loading title”) and trying to view the stats for individual posts would result in a 403 error.
Almost coincidentally, I was browsing through some of my site logs and noticed a few requests for a file, “xmlrpc.php” in my root directory. I noticed requests for this file coincided with my attempts to view individual stats. As it turns out, xmlrpc.php is a WordPress file found in the main WordPress directory, and is used for remote posting, pingbacks, and trackbacks. Apparently, it is also used to read post data for WordPress’s stat system. The problem is, the stats system was looking for xmlrpc.php in the root directory of my site, but my blog resides in a subdirectory on my server. Since the file appeared to be missing, the correct data could not load, and individual stats would not display.
To solve this problem, I simply copied xmlrpc.php from my WordPress subdirectory into the root directory of my site. I only needed to edit one line, the include statement for wp-load.php. I adjusted the path so it pointed to the actual wp-load.php in my WordPress subdirectory. After doing this, individual stat graphs worked perfectly!
Instead of this method, it might also be possible to use an .htaccess edit to redirect requests for the xmlrpc.php file, but I did not try this. I hope this information might help someone who stores their WordPress blog in a subdirectory and has experienced this same problem. I was unable to find any information about something like this on Google or the WordPress forums.