One of WordPress’ strengths is its attention to SEO-related issues in its core files. One of those issues is the problem of having the home page of the blog indexed twice in the search engines; once under the actual address, http://domain-name.com/index.php, and the other as the plain domain name: http://domain-name.com. Note that this is a different problem than the trailing slash problem ( http://domain-name.com/ vs. http://domain-name.com ) which WordPress also takes care of.

WordPress handles the index.php problem by rewriting requests for http://domain-name.com/index.php to http://domain-name.com. All well and good, and beneficial for most sites.

But that rewriting/redirecting caused some problems on a site I was working on yesterday, and once I figured out how, it was a relatively easy fix.

Here’s what happened: a client had me upgrade an old installation of SemioLogic’s version of WordPress to genuine WordPress. While it can be time-consuming, switching over is a fairly straightforward process most of the time. The challenge here was that while most of the site is normal .html files, WordPress is installed at the root level, and is not actually serving the ‘home’ page of the site.

So you can maybe see where this is headed: the ‘home’ page of the site is index.html. That’s what comes up when you ask for http://domain-name.com. The server is set to look for index.html first, then index.php if index.html isn’t there. So to get to the blog, you had to ask for http://domain-name.com/index.php.

But when you asked for index.php, WordPress, being the dutiful SEO-friendly software that it is, stripped off “index.php” from the request, and redirected to http://domain-name.com.

The server saw the request for the site index file and promptly served up index.html. So you couldn’t get to the home page of the blog. If you had a specific post URL and typed it in, it worked fine.

Easy fix, says I. Settings -> General, change the WordPress url to http://domain-name.com/index.php from http://domain-name.com.

Oops. Now all the permalinks have ‘index.php/’ prepended: http://domain-name.com/index.php/i-want-this-post. Not good, and not intended, especially as the site has been indexed in Google without the index.php in there.

I never did figure out how SemioLogic handled this; obviously it was working before the changeover. Undoubtedly there was an easy setting that disappeared once the SL files were gone. I can only think this issue had come up before and the author of SL provided a workaround.

Thankfully, the coders of WordPress also recognized that there may be a time when rewriting URLs wasn’t good so they provided a filter to disable or alter the rewrite. Once I found that notation in includes/canonical.php, the fix was a breeze. Write a plugin that disables the redirect to / when /index.php is called for. Here is the entire plugin:

<?php
/*
Plugin Name: Index.php fix
Plugin URI: http://ilikewordpress.com/loading-wordpress-from-index-php
Description: This plugin allows a blog installed at root to be addressed by /index.php. Remedies stripping of filename by includes/canonical.php
Author: Steve Johnson
Version: 1.0
Author URI: http://ilikewordpress.com/
*/

/*
*    Applies filter to redirect_canonical to defeat
*    stripping of index.php file
*/

function fix_index( $requested_url ) {
 if ( get_bloginfo( 'url' ) == $requested_url )
 return false;
}
add_filter( 'redirect_canonical', 'fix_index' );

?>

And that’s all there is to it. Now when a browser asks for ‘index.php’, that’s what it gets instead of a redirection to /.

You could also put this in the functions.php file of a theme, but obviously it wouldn’t work if the theme were changed.

176 Total TweetBacks: (Tweet this post)

Here’s a quick tip for you — if some function in the WordPress Dashboard (especially WP v2.7) isn’t working for you, or if you make some changes to your WordPress theme and you’re not seeing them on your live site, clear your browser cache!

This one simple thing can solve a number of problems for you. Browsers are weird animals. In the name of speed, they cache (store on your local computer) many of the files and images that make up a web page. Sometimes it doesn’t know when to ask for new files from the web server of the site you’re visiting.

If you’re on Windows and you’re using Internet Exploder … er, Explorer … go to Tools >Internet Options and click on the Delete button in the ‘Browsing history’ section. In the dialog box that opens, click the ‘Delete files…’ button in the ‘Temporary Internet Files’ section. Follow the prompts to delete the files. Close and restart IE.

If you’re using Firefox (and you should be!) click on Tools then Clear Private Data (or hold down ctrl and shift and hit delete). In the dialog box, clear all of the checkboxes except ‘Cache’ and click OK. Close and restart Firefox.

Do it twice! Only the browser gremlins know why, but I’ve found that sometimes once isn’t enough to completely clear the cache files.

6 Total TweetBacks: (Tweet this post)

Website security is critical, on that I’m sure we’d all agree.

But it can sure be a pain in the ass sometimes. Can I hear a “hell YEAH!”?

So what do you do when WordPress tells you, “You don’t have permission to do that“? Or when in some fashion you see a message that WordPress is “Unable to create directory – Is its parent directory writable by the server?”

If you’re not geekily inclined, you call in a professional. Like me. Who’s supposed to know everything about WordPress.

So when I was hit with both of these today on my own blog, I did what any experienced professional troubleshooter does — look for the complicated causes first. I mean, this can’t be something easy, right?

The first error I hit was when trying to add a new category during a post. Little red box says, “You don’t have permission to do that”. Wonderful. Well, I know I do. At least I think I do. So in true spirit of a troubleshooting professional, I open a new tab and look into the options table of the database because this can’t be anything simple. Yeah, everything looks right. So what’s the problem? Do I need to reinstall? (I really didn’t consider that, but for some people at the first sign of trouble, that’s what they do)

Well, poo. I guess the next step is to close the browser, clear the cache, and try again.

Hit the ‘Save Draft’ button on the post, it saves and reloads. The error goes away. What the hell, I’ll try again.

No errors, category added.

Ajax really chaps my ass sometimes…

So I finish up the post, and decide I want to add a plugin or two and I’ll play with the new search/auto-install features. I’m not a fan of auto-install. But I’m willing to work with it, because my clients are going to and I’d better know what’s up with it.

I find a plugin I want through the search feature, hit the install buttons and everything works flawlessly. Surprised? Hell yeah! It worked!

I knew of a plugin I wanted to install that isn’t in the WordPress plugins repository. I had a zip file on my machine, so I thought I’d try the “upload zip file and install” functionality. Hit the button, locate the file, hit continue…

Ha! There it was! I knew it! I knew it wouldn’t work. Where I was supposed to be seeing the sucess messages I was instead presented with “Unable to create directory – Is its parent directory writable by the server?”

This is an error that has to do with permissions on files, and folders. I KNOW those were set right, because I set up my own blogs. I know what I’m doing (tongue firmly planted in cheek here). So after going through all of the file permissions just do double-check (FYI, necessary file permission settings are here), I started looking for more simple solutions.

Mod_security. “That’s the trouble,” I thought (mod_security is an Apache web server module designed to help keep the rifraff off of your server). That module has been a pain in my butt ever since WordPress start using the Flash-based uploader. Same sort of problems. That has to be the cause.

Nope. I’d already fixed that.

I wish I could say that I figured it out on my own. I suppose I would’ve, eventually. But fortunately Mr. Google had the answer, in the form of this conversation on the WordPress support forums.

What it finally boiled down to was a file path on the Settings > Miscellaneous page was wrong. WordPress had divined and preloaded the supposedly correct path to my uploads folder. What should have been in the box is wp-content/uploads. What was actually there was the full server path to the uploads folder, prefixed with a slash. The slash is what was causing the problem. On its face it looked correct (*nix file paths are normally notated with a beginning slash), but in this case it wasn’t. Removing the slash cured the problem.

Moral of this rather long story? Look for the easy solutions first.

3 Total TweetBacks: (Tweet this post)