3.2 broke site, calling fatal error in wp_blog_header.php

And, I totally failed to make notes of the errors WP called when it failed to install 3.2 initially, which was stupid, and probably held the keys to whatever buggered this up.

Your upgrade did not complete successfully.
Try:
– switching to the default theme by renaming your current theme’s folder in wp-content/themes using FTP or whatever file management application your host provides.

– resetting the plugins folder by FTP or phpMyAdmin.

– re-uploading all files & folders – except the wp-content folder – from a fresh download of WordPress.

– re-running the upgrade manually using wp-admin/upgrade.php.

Okay, thanks – right now, I’ve just started trying to upload the files from my backup zip, via DreamWeaver, though I’m a little anxious as to why it’s not asking me if I want to overwrite stuff or not. I’m going to stop that and try one of your last two suggestions. I’m loathe to switch themes as I think I’ll have to go back and do a lot of work in Atahualpa if I turn it off and on again, or at least that’s what I remember from past versions. But I’m willing to do what I have to.

Thank you for taking a moment. I’m not an idiot but, as I said, I’m not a developer, and this sort of thing is extremely unnerving for me, nice to even have moral support.

FWIW, I haven’t seen any issues with Atahualpa in WP 3.2

Thanks – me neither! I really feel bolshi about not wanting to mess with it in this site! I use it for, uh, everything these days… That is, ALL my other recent sites are running on ata and 3.2 and no issues.

In trying your “upload everything sans wp-content” suggestion, I noticed that there was a config-sample file still sitting in the top level – not sure how that happened, though I remember getting interrupted or something the day I set up this site, and I’m not sure that that or some other related screwiness in original file loading hasn’t been screwing things up. We’ll see, thanks again.

I noticed that there was a config-sample file still sitting in the top level

A wp-config-sample.php file is shipped as part of the core install for those of us who like to hand edit our own config file. Don’t worry about it.

So, from a clean 3.2 download, I overwrote the top-level wp files (renaming/replacing the config file), and the admin and includes folders + their contents. I am now getting:
A user login request and then a 500 Internal Server Error, even for my index.html page. I’m not sure what the hell I’ve done now. I have logged into my file manager in the control panel, but don’t see a lack of “read” priviledges. I also went and reset db user permissions to “all” (one had somehow switched off), still screwed up.

I am considering uninstalling everything, or even wiping this account off my server, doing a clean reinstall and replacing the wp-content folder with the backup I have from earlier. Is there a serious danger in doing this? Is all my content in my backup? I am sure I’ll have plenty of cleanup to do but am wondering whether this will work, period…

Is there a serious danger in doing this?

Not if you’ve got a decent backup. Does this site have its own php.ini file? Anything unusual in the .htaccess file?

duh, so, I have an 881K sql file in the backup that is obviously the db backup, and I realize what I’ll have to do is restore THAT to have my content, of course, and I’m uncertain of how to do that restore. I am going to do some searching on here for tutorials on that.

huh. as I hadn’t modified .htaccess, I hadn’t looked. Here’s what it says, though (this is the top-level .htaccess file, haven’t looked at the ones in any of my server’s _vti_ files, and it doesn’t have a php.ini file, btw), which doesn’t mean anything to me:

# -FrontPage-

Options None

<Limit GET POST>
order deny,allow
deny from all
allow from all
require group authors administrators
</Limit>
<Limit PUT DELETE>
order deny,allow
deny from all
</Limit>
AuthType Basic
AuthName cellphonetaskforce.org
AuthUserFile /home/cptf/public_html/_vti_pvt/service.pwd
AuthGroupFile /home/cptf/public_html/_vti_pvt/service.grp

Duh again – thought to compare this to the .htaccess from a working client site, and have amended it to reflect the settings from that one.

That fixed the internal server error, and all is well, thank you so much! The replacement thing WORKED! I’ll have that big glass of red now, yes, thank you. Cheers to you, Esmi.

Glad I could help ??