The Case Of the Missing Post

A client came to me with a strange problem. He’d written and published a post, but when he tried to view it on his site he got a 404-Not Found error.

Usually, when there is a problem with posts or pages disappearing the culprit is permalink-related. Most of the time, a simple click of the update button on the Settings > Permalink page will fix it. Not this time.

I could see no logical reason for the post to be ‘Not Found’. The permalink matched the post slug, there were no kinky characters or spaces. All of the other posts displayed as they should have. A quick switch of the theme back to Twentyten proved useless also, same problem. A look through the rewrite_rules option in the _options table proved fruitless also. Or did it?

I found the post slug within the rewrite_rules option entry; all seemed normal, until I saw this line:

s:48:”(page-slug-redacted)/page/?([0-9]{1,})/?$”;

Huh? This was a post, not a page.

i have an idea that..... just .... might.... work!

No, that's not me.

Creative Commons License photo credit: mil8

Then came the lightbulb moment. What if there’s a page with the same slug as the post? Not supposed to happen, but you never know.

Nothing resembling that title on the pages list.

Ahhhh, the trash can. The WordPress guys and girls had a pretty decent idea when they implemented the trash can. It takes a page or post out of circulation, but still keeps it around just in case.

Keeps it around with the original slug.

Gotcha. Sure enough, in the Pages trash can was a page with the identical slug as the post. Evidently my client had learned how to manipulate post slugs. How he was able to use a slug identical to an existing one is a question I haven’t answered yet.

Permanently delete the trashed page, and as if by magic the post now shows up where it’s supposed to.

Moral of the story: check the trash.

You Do Not Have Sufficient Permissions to Access This Page

More than a few people have contacted me after seeing this message. It usually appears after upgrading to WordPress version 3 or above, when accessing a plugin’s Dashboard menu.

This article isn’t an exhaustive treatment of this issue, but if you’re a developer you’ll at least walk away with an idea of what needs to be fixed in your plugin or theme options menus.

The cause of the “You Do Not Have Sufficient Permissions to Access This Page” error message

The common cause appears to be plugins that use an older method of generating menu and submenu items. Those are the links in your Dashboard’s menu column that appear when you activate a plugin.

When a plugin is activated, certain values are stored in the options table, one of them being a sanitized, shortened version of the plugin name. Later versions of WordPress use slightly different functions for doing this than previous versions. This is where the weirdness starts, and where some plugin developers drop the ball in their testing – previous installs of the plugin will throw errors on upgrading WordPress. Plugins installed after upgrading will be fine, with no errors.

Here is how a main menu item is generated:

add_menu_page( $page_title, $menu_title, $capability, $menu_slug, $function, $icon_url, $position );

And a sub-menu item:

add_submenu_page( $parent_slug, $page_title, $menu_title, $capability, $menu_slug, $function);

There are two stumbling blocks here: the $capability and $menu_slug attributes.

First, the $menu_slug. The following is from the Adding Administration Menus page of the WordPress Codex:

The slug name to refer to this menu by (should be unique for this menu). Prior to Version 3.0 this was called the file (or handle) parameter. If the function parameter is omitted, the menu_slug should be the PHP file that handles the display of the menu page content.

Prior to Version 3.0, the value in the menu_slug attribute was used ‘as-is’, no sanitization was performed. This value populates the $_registered_pages[$hookname] value in wp-admin/includes/plugins.php. Here’s where the problem comes in: this is the value that is stored in the options table, including space characters.

Beginning in Version 3.0, space characters in $menu_slug are stripped before storage. Hence, a menu_slug with the value “My Plugin Slug” is stored as “MyPluginSlug”. Prior to 3.0, they were stored as they were passed, spaces and all.

The problem comes when the stored value is compared with the passed value in the add_menu_page and add_submenu_page calls. The new routine strips space characters from the value passed to the function, then compares against the options table entry. Surprise! They don’t match. “MyPluginSlug” <> “My Plugin Slug”.

The $capability attribute:

The capability required for this menu to be displayed to the user. User levels are deprecated and should not be used here!

This is a little easier to fix, as WordPress translates the old number-based user_level value to the new capability value. However, it’s problematic to rely on this conversion as no one knows how long it will be there.

Fixing the Blank Screen Syndrome on a WordPress Blog

With the advent of WordPress version 3, my most common fixit request has been, “Help! I just see a white screen on my blog!”

I’ll share with you what I’ve found to be the most common cause, but first there’re a few things you can do to at least get back up and running again.

If you have Dashboard access, first disable ALL of your plugins. 9 times out of 10, you’ll see your site reappear.

If you still see just a white screen, the next step is to switch themes. Activate WordPress’s default theme (the twenty-ten theme, now) and check your site again.

If that didn’t fix your problem, you’ll need to start verifying core files and such, or employ the services of a WordPress professional to help you get your site back up and running.

Loading WordPress From index.php

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. Read more

Help! My WordPress Isn’t Working!

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.

You Don’t Have Permission To Do That

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.