Abigailm

And just to make you extra happy, I jut did a brute force disabling of plugins — you know, the kind where you rename the plugin directory to something else to that wordpress can’t find it? That didn’t fix the problem either.

I understand that this is not a universal problem and probably not even a big problem. I posted here because Becki reported an issue and I thought it would be helpful for a 2nd person to post the same issue. I could not have known when I started that Becki’s fix wouldn’t work for me — that is something that was learned after I tried Becki’s suggestion and could report back that it didn’t work. Also, the fact that I am not a MU user and Becki is could have been helpful for debugging, because that also helps to know whether to look at MU-specific features or elsewhere.

Your response seems to be something along the lines of, “well no one else has reported it so therefore it must be something weird on your end that we don’t have to worry about” — but your attitude is going to discourage others from posting if they have a similar problem. I mean, I posted because I thought your response to Becki was dismissive, and I thought it would be helpful to know that 2 people on the internet, and not just 1, had the same problem. But anyone who reads this thread now is going to see that they will simply get a similarly dismissive response, so the #3 person who comes along is probably going to be deterred from posting.

I understand that wordpress a free, open source program and I appreciate that. It is not your job to fix everyone’s problems. It is acceptable in a forum to simply say that you don’t know what is causing a problem and that you don’t have a suggested fix. Becki has helped me by providing a useful script, and for that I am grateful. If I had not come to this thread, I would not have received the help. I actually think that it is might be useful for programmer to know that the issue is not confined to a single widget — and certainly useful for others who may run into similar problems.

I’d note that on any internet forum, you have dozens or even hundreds of readers for every person that posts, and most people are going to try out what has already been suggested before posting on their own. If their problem is then fixed, that’s great – they don’t have to post.

Also, again, I did not come here looking for MU advice — I found this thread on Google by doing a search related to dashboard widgets and WP 3.2, and it happened to lead me here. Anyway, sorry for taking up your time. There’s no need for you to respond to this post. I am NOT looking for an argument. I’m just trying to debug a piece of software that I’m using. If it works for others and doesn’t work for me, that means that somewhere there is a bit of code that it causing the problem, and I’m simply interested in narrowing down what that might be.

Yes, but I don’t know where to start there. The javascript error console throws up dozens of warnings but no hard errors. So I would need more guidance on what to look for.

One more comment:

If this really was a major bug with WordPress, you’d be seeing a LOT more people complaining. That we’re not is indicative.
….
Becki disabled QUICKPRESS which is NOT the same as what you’re disabling.

See? Even more differences!

Maybe its a “minor” bug and not a major one. It’s something that only shows up on the back end administration panel and is not a major impact on functionality, and 3.2 was only released 2 days ago. I had another symptom of the problem related to the dashboard nav bar which I didn’t mention, because it went away with the fix — but in Googling I found others complaining about that. So obviously what is happening is that the upgrade works well for most, but runs into problems with individual configurations. There are hundreds of thousands of different iterations of wordpress running with different themes, different plugins — and it isn’t reasonable to simply decide that everyone will have to discard their themes and plugins if it causes a conflict.

That does not mean that wordpress developers need to ensure backwards compatibility for 100% of users, but it would help to take reports seriously so that at least there would be more guidance for users as to what specific issues could cause problems, and how they can be addressed.

My own opinion is that the real problem isn’t that a dashboard widget didn’t work, it’s that the nonfunction impedes the “screen options” functions, so there is then no way to turn off the malfunctioning widget from within the administration page. I’m not a programmer so I don’t know what the alternatives are, but from a design standpoint I think it would be better if each individual widget would simply throw up an error message and then shut down, rather than one widget preventing the loading and functioning of all the others. Maybe that’s not possible, I don’t know — just saying that it would make the debugging process somewhat easier.

Sure — here it is:
http://davismethods.info/phpinfo.php

I upgraded my PHP about a month ago and I remember now that I had some questions about which PHP modules should be enabled, so perhaps that’s the source of the problem.