Call to undefined function field_attach_load()

Okay, to reproduce the error, I had to uninstall everything (again). I get through the database configure page ("set up database" step) that asks me for the database prefix name (which I set as "drupal_"), and when I click "save and continue" I got this error:

Error message
PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY fit DESC LIMIT 0, 1' at line 1: SELECT * FROM {menu_router} WHERE path IN () ORDER BY fit DESC LIMIT 0, 1; Array ( ) in menu_get_item() (line 443 of /var/www/www.donbishop.cc/htdocs/includes/menu.inc).

(I double-checked the MySQL database and it had 32 tables created, all with the "drupal_" prefix, so that seemed to go okay...)

Then I clicked on "Skip to main Content" at the top of the error page, and I just got the same error again. So I clicked on the browser back button and returned to the database configuration page/database set up step (as you would expect). I clicked "save and continue again, but this time progressed to the "Configure Site" page pointing to the "> configure site" step. I entered the site name ("Clearinghouse"), an email address (dbishop@donbishop.cc), the site maintenance user name is the same as the mysql username to create the database, and the password I used is the same too. The server country is USA and the timezone is NY. then I clicked "save and continue" again. (the two check boxes were left default/checked).

Then I got the output in the attached debug01.txt file.

Sorry about the Gentoo thing, it became part of me a long, long time ago. I am considering switching to Funtoo if that makes it any better :-)

Cookies disabled in the browser used for configuring? I have two cookies set from the site: one is named 'has_js' and one named 'SSESS1660827e4542886536c7bd5e2d7e892e'.

Are there any special permissions that need to be on the files and or directories on the server side for cookies or for the site files? Is there a problem with any of the configuration data I've entered? Is it expected to use the same user/pxwd for the admin and for the myql user that is set up when the database is created, or should they be different?

I have mediawiki installed on this machine (and several others) -- a very complex LAMP content management system of sorts in its own right -- and I have never had any real problems, even through version upgrades from 1.05 through 1.16.2 (nor have I ever had to create the databases by hand or had configs get wiped out).

I'm hoping that this is just something simple like permissions or something like that... Any other suggestions?

Okay, I'm getting the feeling that this has to do with the fact that the server is sitting in a DMZ. As I mentioned I have mediawiki (which relies on cookies) running on the same box without issues, and I have tried to configure the Drupal site (after removing the failed install again) using a browser on the same subnet (machine also in the DMZ network) but that didn't work. So next I will try to configure it from a browser running on the same machine. Does this sound sensible?

(I am thinking that the cookies are not surviving the NATing and I'll need to learn/use some apache reverse proxy kung fu. If I was familiar with it I'd just do it, but this seems ripe for problems if the server isn't bullet proof, and this is just a test server so I'd like to be sure before I do a lot of apache push-ups.)

Okay, well, I tried to configure drupal completely from within the server, and the same basic error. Always creates the same 32 database tables (in alphabetical order) ending with users, user_roles, and variables. This machine is in a DMZ but the address is *not* NAT'd from within the DMZ (bind runs internally and answers name queries accordingly). MySQL and Apache are on the same machine (as is now X and Firefox from which I've tried to configure drupal).

Any other ideas? Any way I can check the cookie theory out o know for sure where it's breaking, if indeed it's a cookie issue?

Okay, problem resolved (finally). Here's what happened: Apache wasn't set up for SSL for this particular vhost so 'session.cookie_secure' in php.ini needed to be commented out and apache had to be restarted. There were tow php.ini's with this set, '/etc/php/apache2-php5.3/php.ini' and '/etc/php/cli-php5.3/php.ini' (Gentoo)

I hope someone will benefit from this :-)