tommcgee

Any idea what it was about the theme?

I have the same problem in one of two sites where I’ve tried it. What theme are you using? In a modified Arras theme, it’s broken; in a modified twentyeleven it works.

Fixed — thanks!

Yes. That’s been a problem for several versions. And BBQ is checking for query string lengths that are mandatory for some built-in functions, so that has to be overridden.

Oh, the plugin in question is wordpress-mu-domain-mapping v. 0.5.4.

One more thing. WordPress on its own generates query strings longer than 255 characters. For example, if you empty your Akismet spam folder you’re going to have a URL somewhere around 700 characters. Same with any bulk approve/delete/spam actions you might take on comments.

When you click you get the “white screen of death.” Click the back button and refresh, all your comments are untouched.

A couple of questions: Isn’t a 255-character limit a little arbitrary? The allowable limit for URLs is much higher than that.

But maybe it fails because of this: blockbadqueries.php is looking for a REQUEST_URI of greater than 255 characters. But the REQUEST_URI is the portion after the domain name. The Ultimate Security Checker test is only generating a query string 250 characters long:

‘long’ -> $this->gen_random_string(250),

So when tested against the 255 value the URL generated by the test won’t it always pass, because it’s going to be at most 252 characters long?

But that’s not it; I tried some URLs that are supposed to be trapped (after logging off my admin account):

https://this.blogs.com/?12341234base640-982321
https://this.blogs.com/?12341234base640-982321eval(xyzz);f4
https://this.blogs.com/?eval(CONCAT(this+that))

In each case, my server cheerfully returned a “200” server response. So is the problem with the blockbadqueries.php plugin itself?

Is the $user_ID defined? Do the guys with black hats have one? If not, then it doesn’t even run the test. Same with current_user_can — what if there is no “current user”?

When I commented out the tests for the existence of $user_ID and the ‘level_10’ access, bingo: my test URLs successfully failed, as it were.

I’m also having that issue, on all my sites. Some are self-hosted on RedHat Linux, others on third-party hosting installations.

The way I used to add existing users to a blog was to go to that blog’s Dashboard and use the Super Admin/User panel. I could do a search for the name, click the edit link on the one I wanted, and assign that user a role.

Now I have to search in the Network Admin users, search for the user with wild cards, copy their email address, then navigate to the individual blog’s Users panel and paste it in, while assigning a role.

I know it’s not the end of the world, but it’s a step backwards in terms of manageability.

Midphase was having a DDOS problem last week that gave me a similar problem.

This has happened to me twice in a row now, with two different sites. It’s hanging at “Installing the latest version…”

The solution is, find the file at the root level of your blog called “.maintenance” (that’s dot-maintenance) and delete it. For some reason the auto-update isn’t.

Reload the dashboard and you should see that you’ve got the latest version.

Aha, thanks David.

The plug-in you suggest allows you to set a single default role for any user who clicks the “add me” link. The obvious choice is “subscriber,” but once they’re added to the blog, the local administrator STILL cannot change that role — they show up on the Users screen, but the “edit” link is unavailable.

What’s more, since they’re in the system already you can’t enter them anew with the role you actually want them to have. So they’re stuck as “subscribers” even though you may want them to be editors, and the super administrator still has to be involved.

Andrea, we’re trying to add specific users to specific blogs, one-by-one.

For a sub-blog, the user doesn’t show up in the Users panel because they haven’t been assigned any role at all on that blog yet, not even as a subscriber. They’re in the global system because they are a member of the root blog, but there is no way to search for them.

It can be done if you know the exact login name and e-mail address they used to register, but if you get it wrong (we’re using active directory authentication) then you’ve created a useless new user. It’s too clunky that way.

But even from there, the only link an administrator has in the users tab is “Remove.”