The Pain of WordPress: "You do not have sufficient permissions to access this page" when trying to upgrade

I searched far and wide for a working solution for this, and in the end had to cook one up myself. For a short description of the issue, every time I tried to use the new (and otherwise higly cool) one-click upgrade feature in one of my blogs, I was greeted with the blunt response of “You do not have sufficient permissions to access this page.” This was made all the more curious by the fact that simultaneously upgrades of plugins did work in very the same blog.

Now, I know how to google and this issue seems alarmingly widespread. Luckily there are also quite a few solutions, but unfortunately, as I said, none of them worked for me. Anyway, here’s a list of the solutions othes have found useful, just in case:

In addition, I tried changing the permissions of wp-content and subfolders, clearing my cookies and cache, logging in and out, reloading and so on — all to no avail. When all of these failed, I began to compare the database tables between my other blogs, in which the upgrade worked smoothly, and the one in which it didn’t.

I first discovered that prefix_options had two options called fileupload_realpath and fileupload_url. In my other, working blog they referred to the correct upload path on my webserver. In the broken one they were at default, example values which of course were flawed. So I fixed the paths thinking I’d found the culprit, but not so: the issue remained. However, this fix probably didn’t hurt either, as the upgrades probably use the ‘upgrade’ subdirectory inside the upload path.

The solution

Then I found that the values of prefix_user_roles in prefix_options differed between the working blogs and the one that didn’t, but didn’t differ among the working ones. So, without any idea of the values’ syntax I simply copied the value from one of the working blogs’ tables and pasted it onto the broken one’s. And that did it: the upgrade now works as intended. Yay!

Just in case someone with only a single blog has this issue, I’ll paste the actual contents of my working prefix_user_roles below. It shouldn’t have anything too unportable, as the value is probably a default set by the installation of one of my more recent blogs.

Note that the newlines in weird-looking places are apparently either part of the syntax, or ignored completely, so copying and pasting the value below should work. Unless WordPress — the installation I’m publishing this post in — somehow screws it up. The browser will break the lines when viewed on this page, but it shouldn’t affect selecting and copying, as it’s only part of the visible rendering.


Google Calendar not working in Epiphany?

Seemingly out of the blue Google Calendar ceased to function for me the other day. I finally tracked the issue down to Greasemonkey and more particularly to _blank Must Die. Adding the two lines I listed below to it seems to have fixed it for now.

// @exclude*
// @exclude*

I’m left to wonder what brought this on so suddenly, since I haven’t touched the script prior to this in ages — in fact, I had a hard time even remembering I was using Greasemonkey at all.

WordPress and wrong $numposts?

After a fresh WordPress installation, I was dumbfounded for a while when a simple “global $numposts; echo $numposts;” would always print N+1 despite the total number of posts actually being N. Turns out I had forgot to delete the initial “About” page, which obviously isn’t listed among the posts, but among pages, yet gets included when $numposts is calculated.