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.

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.

The WordPress  team did a great and wonderful thing when they included auto-save and revisions for posts/pages. If you’re in a collaborative environment, referring to previous revisions can be a useful tool. And auto-save? If you haven’t had a computer crash in the middle of writing a blog post, you’re probably in the minority

On the flip side, most of us don’t need to see countless revisions that we may have made. Fix a typo? One more revision. The list can get pretty long.

And really – do we really need an auto save once every minute? I don’t know about you, but I don’t type that fast…

Fortunately, as for most annoyances in WordPress, there is a relatively easy fix for both auto-saves and post/page revisions. You’ll need to edit your wp-config.php file (for those of you who installed WP by hand, that’s the file where you entered your database information).

FTP into your WordPress installation on your server, then download the wp-config.php file to your computer. Immediately, before you do anything else, make a backup copy. Always always always keep a backup copy of files you edit. An error as tiny as a misplaced comma can render your blog unusable.

Changing the AutoSave interval

You’ll need to add the following line to your wp-config.php file:

define('AUTOSAVE_INTERVAL', 180 );  // # of seconds between saves

Change the ’160′ number to whatever autosave interval you want. I usually use 180, or 3 minutes.

Change the post Revisions settings

Unlike AutoSave, you can actually turn post/page revisions off if you really want to. Or, you can specify the number of revisions you want to keep.

To turn revisions off, add this line to wp-config.php:

define('WP_POST_REVISIONS', false );

If you want to keep revisions on, but limit the number that WordPress saves, use a number instead of the keyword false:

define('WP_POST_REVISIONS', 6);

There. Pretty simple, eh? Save your wp-config.php file, then upload it back to your server. Your changes will take effect immediately.

So you’ve started a new blog, and now the worst has happened – the spammers have your email address. You know, the one that’s on every post where you’re listed as the author.

You can do what a lot of people do to combat the dreaded email harvester. Give them a throw-away address to chew on, and when the spam gets too bad close that account and start another. Throw-away addresses are the free accounts – Hotmail, Yahoo, GMail.

But that’s a pain.

Why not just make it so the spam bots can’t find your email address in the first place? Fortunately, it’s pretty easily done, using a built-in WordPress function: antispambot(). This function takes the email address enclosed in the parentheses, converts it to HTML entities ( the &#xx characters ) and returns the value.

How do you use it? Again, pretty simple. Somewhere in your templates, if the template author chose to display your email address at all, is a call to the WordPress template tag the_author_email(). This tag, as you might suspect, outputs the post author’s email address. Open your single.php template (the most likely template to display the author’s email address ) in your fav text editor, and search for the tag. Once you’ve found it, you’ll make the substitution. Change the_author_email() to the following:

echo antispambot( get_the_author_email())

Nothing to it, right?

Those of you with sharp eyes will notice we’re using a slightly different function to get the author’s email address – get_the_author_email() vs. the_author_email(). The difference is that the latter actually outputs the email address to the screen, and we don’t want that. We want to pass the email address to the antispambot() function rather than print it to the screen, so we use the get_the_author_email() function which returns the value rather than echoing it. Small but important distinction.

I am done completely with print design and design in general. Because it’s also spring-cleaning time for my office in preparation for a move, these books really need to find a new home. I would prefer to sell them as one package, but let me know if there’s one or two that you want.

There are almost $250 worth of books here, all in good shape. They have been read, though, so they’re not pristine.

Buy-it-now price: $75 + $10 shipping, total $85. Hit the preloaded PayPal button below or at the end of the post. Yes, you can use credit card or debit card.

Or – give me an offer. I’d like to see these go to someone who can use them and will appreciate them.

Graphic effects and typographic treatments. Jim Krause, $22.99 USD. ISBN 1-58180-046-0

Brochure, poster/flyer, web design, advertising, newsletter, page layout, stationery ideas. Jim Krause, $22.99 USD. ISBN 1-58180-146-7

An index of 150+ concepts, images and exercises to ignite your design ingenuity. Jim Krause, $24.99 USD. ISBN 1-58180-438-5

Over 1100 Color Combinations, CMYK & RGB Formulas, for print and web media. Jim Krause, $23.99 USD. ISBN 1-58180-236-6

A graphic designer’s guide to designing effective compositions, selecting dynamic components & devloping creative concepts. Jim Krause, $24.99 USD. ISBN 1-58180-501-2

375+ pages of design ideas, edited by the famous David E. Carter, $29.99 USD. ISBN 0-06-008763-3

Design and Typographic Principles for the Visual Novice, Robin Williams, $14.95USD. ISBN 1-56609-159-4

The Non-Designer’s Type Book, Robin Williams, $24.99USD. ISBN 0-201-35367-9

Everything you need to know to create dynamic layouts. Graham Davis, $21.99USD. ISBN 1-58180-260-9

Design principles, decisions, projects. David Dabner, $23.99USD. ISBN 1-58180-435-0

I don’t restart my computer very often; it mostly runs 24/7. So when I did have occasion to do a restart, I was hit with the issue that my development instance of Apache wouldn’t start. I would get the error: “Windows could not start Apache 2.2 on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code 1.”

Never one to follow instructions, after several retries, much teeth-gnashing and hair-pulling, I decided I might make more headway were I to have a look at the Apache error log.

Nothing. Zip. Zilch. Zero. Nada. Just a note that the httpd.pid file had been overwritten.

So, maybe following suggestions is a good thing. Opened up the WinXP event viewer. Hallelujah, there it is.

“The Apache service named  reported the following error: >>> no listening sockets available, shutting down.”

I have Apache configured to listen on port 80, so I don’t have to go through shenanigans when I’m developing a site. What this error is telling me is that port 80 isn’t available to attach to – probably because some other program got there first.

I’ve never had this problem before. What’s different between now and the last time I restarted my machine with no problems?

Aha! I upgraded Skype.

Sure enough: shut down Skype, Apache starts up normally.

Skype was hijacking my listening socket, and because it’s higher up on the auto-start list than Apache, Apache choked.

AFAICT, this wasn’t previous Skype behavior. I’ve never had the issue before, so logically the last upgrade changed things.

So I set Skype to start manually instead of automatically. Problem solved.

45 minutes wasted, never to return. I know that’s not much, but still.