On this past weekend, I pulled out most of what little hair I had remaining, after trying to troubleshoot a Drupal site at www.pflogging.com which stopped working after I uploaded some new modules for testing. I have a test site, but overlooked it and thought I could just upload this stuff... heck, I'm backed up. Unfortunately, it appears that this upload occurred while I had a flakey router, and not all files were uploaded intactly. After the upload, I was getting lots of strange errors associated with missing include files (which were really there), but despite all things I tried, including reuploading drupal, stripping out all optional modules, and restoring a backup of the database, I still have a disfunctional site. All I get is a blank page with a single number, '2', when accessing the basic site, and get the theme header under some combinations of /admin url input, but never get any content, blocks, etc.
I've spent three days searching the site for ideas, and have implemented everything I found, including:
* clearing cache tables
* cleared browser temp files, cookies, etc
* truncated node access table
* resetting system variable re URL rewritting
* reloading .htaccess with version provided on install file
* rebooting server
I suspect part of the problem may be that my site content depends upon modules like frontpage, views, and CCK that are no longer there - yet I've tried reloading those, too, and that hasn't helped. Tonight, I contacted our site's admin staff to ask for a complete restore to last week, only to find out that this AM, they overwrote all previous backups, and so they now only have a backup of the current disfunctional site.
The watchdog is always reporting the same error in the database table for each access ('page not found'), but I have no idea why this is the case. I am desperate for other suggestions. Can anyone help? Is there options for someone with deep systems knowledge that I could provide a password to, and directly work with? What options do I have?
I will never, ever, make updates to a live site directly again. But somehow, I have to be able to recover the content from the site, which is quite extensive - 2000 nodes, most with one or more taxonomy terms, views, and many hours invested in content. I've tried installing a fresh install, and confirmed that works - but then copying my backup over (the backup made while things were working) gets me back to where I am.
Please help!
Comments
Thank you for sharing your
Thank you for sharing your painful lesson.
I found in a similar case that "page not found" also came up when an enabling module was missing (in my case, members)
COnsider creating a clean install elsewhere and seeing how it works with your database. Add modules in one at a time till it feels good. Best of luck.
:)
I've set things back to just 'core' modules enabled
I updated the system table to just contain the core modules initialized. That should mean that only those parts of the database tables are accessed, until I enable more. That should eliminate all other modules from consideration, until I can get a basic configuration up and running. However, it still is leaving me with just the crazy empty page (except for the number 2).
what results do you get
what results do you get when you point a fresh install at the oldest database copy you have?
_ _ _ _ _
Stuart Mackenzie - rojojam.com
I get the strange response of the number 2
The current site is the results of a fresh load of drupal with the restored database. It produces a properly formatted html page that contains only the number 2 as body text. That is what you'll see if you browse to the current site.
Any idea how to progressively add back in a 'basic' table config
My current thought is to progressively add tables to a ''clean' drupal database install from my backup database, until I get something that doesn't work. This would let me preserve users initially, then add selected content. Can anyone suggest the table 'groupings' I might add incrementally? For example, I'd envision moving over in the following sequence, but would appreciate input from others about whether this makes sense architecturally:
1. users + permissions + roles (to enable basic access to the system from existing users)
2. variables + menu + filters + filter formats (to get everything set up for what follows, and make sure theming is working properly); hopefully, at this point, I can still
3. taxonomy stuff (every table with term_ prefix)
4. basic node tables (node, node_, and comment tables)
5. other tables added incrementally prior to each associated module being re-enabled?
Any comments from the pros re the rationality of this approach?
Platform problems?
You don't say what server platform you are running on, but I think it might be worth checking that all files have the right permissions (e.g. on UNIX, world-readable for files plus executable for directories). Also, in cases of severe site failure, the web server error logs are often more useful than the Drupal logs, so try looking in those files. If the error is so deep that watchdog can't start up properly, then watchdog can't log it.
If you find any errors that look relevant, you could post them here for diagnosis.
I hope that helps.
Anj
Great idea, no errors
I had already checked the access to directories, and all that seems right.
Great suggestion on checking web logs. The mode I'm in, any data is good data. Unfortunately, there are no errors there - there were some filter_xss_bad_protocol errors from Monday, but I resolved those errors with clearing the cache. I think at this point the web server is working properly - I've uploaded index.html test files to confirm that, had clean installs run the install script properly, etc. I'm now in the mode of assuming something about the table contents themselves is corrupted somehow, but the question is - which ones, and where?
Other ideas?
Longer shots...
Hum, well, I'm running out of ideas, and you may well have tried them already, but...
Re-instate the full database and file backup, but run www.pflogging.com/update.php first. This will hopefully catch any out-of-date modules and upgrade the tables they rely on. Here I'm assuming that one of the modules you recently tried out you'd actually tried out some time ago. It is plausible that the recent version of that module will break your site until it's tables are fixed.
I noticed that http://www.pflogging.com/ and http://pflogging.com/ behave slightly differently (one uses Garland, the other has a minimal or broken theme). This leads me to wonder whether it might be good to remove any custom themes temporarily. It also suggests that you should check your settings.php file, and perhaps replace it with a 'clean' one and re-edit it to point at the right site and database.
I also tried to directly access this url via wget:
But this responded with a 404 file not found error. On a normal drupal install, it is possible to access this file directly. Is it there? is it world readable? Or are you blocking wget in your htaccess? Does removing your htaccess file altogether help?
I should note that I can access index.php from my browser, but I'm behind a web proxy which may be obscuring the issue. I just tried to access you site from the w3c validator, and it thinks there's nothing there at all:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.pflogging.com%2Findex...
It could be that index.php is corrupt and the 404 handler is kicking in, but as this handler also depends on index.php you get nonsense.
I hope that helps.
Anj
Bump
Any joy? If you found a solution I'd be interested to hear it.
Andy J.
Only pain
I ended up having to start with a clean install, and reload tables manually in groups, roughly as outlined in my original comments (with snapshots at critical points along the way). That caused a few bumps - I didn't realize the importance of the sequence table, so I overwrote some content (but luckily could recover). After about 8 hours of this, I was able to get things working again, but never really found what was wrong. I suspect it was something to do with not clearing the sessions table originally, because that's about the only thing I can think of.
I did get the added benefit of effectively eliminating a lot of tables that were still in my database from modules I'd tried and discontinued. My total tables reduced from 238 to 110! So at the end of the day, something good came out of it, but the cost was high!
Thanks.
Eww, nasty stuff indeed - you have my sympathy. It's a shame a more elegant solution could not be found. Thanks for getting back to us about what happened though.
update.php worked for me
Just thought I'd chime in here to say that I've run across this problem (or something very close to it) recently in the process of moving sites from dev to production. I've done this many times before, and usually all that's required is to hit the admin/build/modules and admin/build/themes pages to reset the system table, and all is well.
For some reason, however, a few sites I've been working on lately give me trouble when I do this. Could be related to my "smarter" approach of adjusting the system table with a script in between dumping the dev site and reloading it into production. This mostly works, but as I say- on a few sites (for no reason I can discern) I get this "page not found" issue.
First few times it happened, I reverted to my previous strategy of just dumping and reloading the DB as-is, but last night I hit a site where that didn't even work. I then found this thread, and discovered that if I hit update.php, something magically resolved itself and the site was fine once again.
I'd really be glad to know what the heck is going on here, but for the moment am just relieved that my sites are running smooth once again :)