install.php: Call to undefined function file_directory_path()

That happens to me if I go to install.php when drupal has already been installed. Is this what you're doing?

Downgrading to normal for the time being.

Please verify that the next site is using its own settings.php and not the settings.php from the other two sites. For example, temporarily rename the settings.php from the installed sites to _settings.php.

same problem for me
i upgrade from 5.0 beta 2 to 5.0-rc1

On new installation of 5.0-rc1 the database selection screen pops up, and then saves the settings, and in the background with no displayed info, sets up the database tables. When it redirects to the index.php, it goes blank. Further running of install.php comes up blank. Errors in the apache logs look like:

[client xx.xx.xx.xx] PHP Fatal error: Call to undefined function: file_directory_path() in /var/www/drupal/includes/common.inc on line 1429, referer: http://host.sample.com/install.php?profile=default
[client xx.xx.xx.xx] PHP Fatal error: Call to undefined function: user_access() in /var/www/drupal/modules/block/block.module on line 68

I deleted the install dir, dropped the tables, and rolled back to beta2, and all works well.

System environment:
Centos 4.4 system running in Virtuzzo VPS.
php 4.3.9
apache 2.0.52
mysql 4.1.20

Please see if the latest patch at http://drupal.org/node/100476 fixes the problem.

I can successfully reproduce this error when I try to install Drupal on an existing database using the same prefix as an existing installation. In other words, if Drupal tries to create a table that already exists, you get "Call to undefined function file_directory_path()" which is not the best first impression of Drupal. There should be an accurate error message saying something like, "Table whatever already exists. Please choose another prefix or database."

Opened an issue for existing tables at http://drupal.org/node/105697 since it seem the cause is different than this.

Well, the error isn't due to the table already existing per se. Drupal detected that it had already been installed and tried to output a maintenance page saying that Drupal has already been installed, but it doesn't include file.inc. This is already fixed in the patch I referenced in #10.

Okay, in order to get at least this bug fix committed, here is a one-line patch that only fixes the file_directory_path error.

Not sure that is the right place to include file.inc. The maintenance page does not require file.inc, as far as I can tell. If the installer requires file.inc, we should probably include it in the installer.

Looking at this some more, drupal_maintenance_theme() is a really awkward function. I wonder why it can't be implemented as a bootstrap phase. Really, what we are trying to mimick with drupal_maintenance_theme() is a n alternative bootstrap scenario.

@Dries: you're right, it isn't drupal_maintenance_theme() that needs file.inc, but rather theme_install_page(), which gets called by install_already_done_error(). So I think it's best to remove the file.inc inclusion in install_select_profile() and add it at the beginning of install_main(). Here's a patch to do that.

You're right that drupal_maintenance_theme() is an awkward function, but I don't think it can be implemented as a bootstrap phase in the current linear design in which phases can't be executed conditionally, in different orders, or in different combinations. I think the bootstrapping system should be revisited in d6 to be more flexible, if possible.

Patch.

Agreed. Committed to CVS HEAD. Thanks.

i was upgrading a localhost copy of 4.6 to 5.0RC -- i got this error, but the maintenance patch worked perfectly.

thanks.