I set the component as update system: should there be a component install system, or are both considered equivalent?

Anyhow, I tried installing Drupal with the new install system, but I cannot configure the Database. Whatever I input (valid or invalid settings), when I press submit, I am back to a blank form.

Preliminary testings show that the function install_settings_validate is not being called at all when it should. Is that a problem with the FAPI during the install process??

Comments

beginner’s picture

for some reason, the form validation process fails precisely in form.inc here (line 124):

  $form = form_builder($form_id, $form);
  if (!empty($_POST['edit']) && (($_POST['edit']['form_id'] == $form_id) || ($_POST['edit']['form_id'] == $callback))) {
    die(); // the process doesn't die here, but it would just before the if() statement.
    drupal_validate_form($form_id, $form, $callback);

beginner’s picture

ok. This is caused by a redirection because the $profile is not set:

function install_change_settings() {
  global $profile, $db_url, $db_type, $db_prefix;
  echo "profile : $profile"; // $profile is not set

// ...
$form['#action'] = "install.php?profile=$profile"; // so it is not set here either, 
                                            //and the post fails, because it is redirected to a new form.

inforeto’s picture

Anyhow, I tried installing Drupal with the new install system, but I cannot configure the Database. Whatever I input (valid or invalid settings), when I press submit, I am back to a blank form.

With a fresh download of drupal-cvs on july 31 i got this same result.
On the html output --->
form action="install.php?profile=" method="post" id="install_settings"

inforeto’s picture

Also, saving the html output to add the selected profile and then call install.php directly took me to the next page.
A page where you can select profiles, with default and civicspace (which is there only as a test).
From there it goes to welcome page.

This makes me think there's no need to seek the profile from the first page if it will make you choose it from a list at the second page.

paranojik’s picture

Works fine for me. Latest CVS takes me directly to the install.php?profile=default page. After filling out the form, Drupal installs smoothly.

beginner’s picture

the latest cvs still fails for me, at exactly the point I mentioned above.
I investigated but could not reproduce with a mock-up test code.
This issue is very strange and may be related to some arcane server config, but which one, I have no clue!

beginner’s picture

Just in case it is of interest to others who have this problem.
In order to be able to carry testing Drupal HEAD, I must circumvent this problem by modifying install.php:

function install_change_settings() {
  global $profile, $db_url, $db_type, $db_prefix;
// Add the line below with the name of the profile you want to use
  $profile = 'default';
erdemkose’s picture

I also had the same problem on IIS and I solved it by passing $profile parameter to the related functions instead of using global.

nickl’s picture

StatusFileSize
new8.47 KB

Tested but could not reproduce.
Removing profile completely gets the attached screen correctly reporting that there is no profile.
Multiple profiles returns a page to choose profiles.
No problems with DB install form testing it since mid July.

The code being referred to also changed:

$form['#action'] = "install.php?profile=$profile" . ($install_locale ? "&locale=$install_locale" : '');

Instead of the reported

$form['#action'] = "install.php?profile=$profile";

Not related to $profile but still different.

Could it be that this problem is fixed?
If not please give more information.
Do you have a schema installed already?
What database are you using?
Does this happen everytime or only in certain scenarios?
Please give a detailed scenario.

beginner’s picture

I just tried again, with today's cvs, and Revision 1.15 of install.php and I have the same problem.

Obviously, not every developer is facing this problem. It is a fairly critical issue that would have been fixed a long time ago otherwise. It must depend on some local parameter, but I have no idea which. the following code in install_change_settings() is simply ignored or doesn't work:
global $profile I am at a loss as to why the global declaration is not acknowledged.

Another reporter above said he was on IIS. I am on Mandriva 2006 with a traditional LAMP stack.
Is there anybody using Mandriva NOT having this problem?

nickl’s picture

@beginner please give more information about the bug.
Give us a detailed explanation from installation, step by step, explaining each step; what you're doing , which form elements you are filling in, what you are filling into them(rather exactly for more information you can skip password) and what you can see until you get to the problem. Then you can save the html or as you explained before that it is definitely a blank page with no rendered html when you view the source.
It would also help if you give us a rundown of your system. Which database and version you're using, which version of php and apache comes with your lamp stack. The more information you give the easier you will make it for someone to try and replicate the problem and possibly fix it.

It is really not clear from this issue what you are experiencing this is what I'm getting:

I removed the global $profile from install_change_settings() in install.php as you say it is being ignored so maybe I will be able to reproduce the error if I remove it.

This is what the function looks like now:

/**
 * Configure and rewrite settings.php.
 */
function install_change_settings() {
  global  $install_locale, $db_url, $db_type, $db_prefix;

  $url = parse_url($db_url);
  $db_user = urldecode($url['user']);
  $db_pass = urldecode($url['pass']);
  $db_host = urldecode($url['host']);
  $db_port = urldecode($url['port']);
  $db_path = ltrim(urldecode($url['path']), '/');
  $settings_file = './'. conf_path() .'/settings.php';

  // We always need this because we want to run form_get_errors.
  include_once './includes/form.inc';
  drupal_maintenance_theme();

  // The existing database settings are not working, so we need write access
  // to settings.php to change them.
  if (!drupal_verify_install_file($settings_file, FILE_EXIST|FILE_READABLE|FILE_WRITABLE)) {
    drupal_set_message(st('The @drupal installer requires write permissions to %file during the installation process.', array('@drupal' => drupal_install_profile_name(), '%file' => $settings_file)), 'error');

    drupal_set_title(st('Drupal database setup'));
    print theme('install_page', '');
    exit;
  }

  // Don't fill in placeholders
  if ($db_url == 'mysql://username:password@localhost/databasename') {
    $db_user = $db_pass = $db_path = '';
  }
  $output = drupal_get_form('install_settings_form', $profile, $install_locale, $settings_file, $db_url, $db_type, $db_prefix, $db_user, $db_pass, $db_host, $db_port, $db_path);
  drupal_set_title(st('Database configuration'));
  print theme('install_page', $output);
  exit;
}

nickl’s picture

StatusFileSize
new13.54 KB

When I acces my new drupal installation on http://localhost/bugfix/ it immediately redirects to http://localhost/bugfix/install.php?profile=default

I fill in the form as per the screenshot attached:
Not changing advanced setting and only filling in my database name, username and password.

nickl’s picture

StatusFileSize
new3.99 KB

When I now press submit I get back to the same screen as per the screenshot above on a blank form.
Attached is the html source of the response.
Looking at the form action:

<form action="install.php?profile="  method="post" id="install_settings_form">

which, if I put the profile variable back, should be

<form action="install.php?profile=default"  method="post" id="install_settings_form">

And the proceeds to install the site correctly.

My Configuration:
Apache/2.2.2 (Win32)
PHP/5.1.4
MySQL - 5.0.21-community-nt

beginner’s picture

yes. by removing global $profile you can perfectly reproduce my problem.
This is already described in #2.
I know the problem still exists because I install a new drupal several times a week to review patches. I always have to use the trick explained in #7 to be able to go forward.

My setup:
Linux Mandriva 2006,
Web server Apache/2.0.54 (Mandriva Linux/PREFORK-13.2.20060mdk)
PHP 4.4.0
MySQL database 4.0.26

The solution might be the one suggested in #8: pass $profile by reference, instead of using global.

nickl’s picture

Thank you for the information, now we're getting somewhere.
If you think the solution is in #8 then why don't you roll the patch so that others can test it and we can move this along. Since it is not a very common problem you stand in a better position than me and many others to fix this issue and since you're reviewing patches I'm sure you can roll one too.
These patches don't roll themselves...

I will see if I can get a similar environment up and running.

In the meantime this excerpt from install.php seems to be where the $profile gets initialised.

  if (!empty($_GET['profile'])) {
    $profile = preg_replace('/[^a-zA-Z_0-9]/', '', $_GET['profile']);
  }
  elseif ($profile = install_select_profile()) {
    install_goto("install.php?profile=$profile");
  }
nickl’s picture

StatusFileSize
new13.4 KB

Tested on:

mandriva LE 2005 kernel 2.6
mysql 4.1.11
Apache-AdvancedExtranetServer/2.0.53
PHP 4.3.10 (cli) (built: May 11 2006 12:07:42)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies

Drupal doesn't seem to like the setup much, attached screenshot of: admin/logs/status

Yet she installs first time no problems.
More information he needs.
Moving along...

erdemkose’s picture

StatusFileSize
new12.57 KB

Here is my configuration:

Web server	Microsoft-IIS/5.1
PHP	5.1.1
MySQL database	5.0.18-nt
Configuration file	Protected
Cron maintenance tasks	Last run 8 hours 35 min ago
Unicode library	Standard PHP

I cannot install Drupal on this configuration. "Database settings" form doesn't have the profile information in its action (http://localhost/drupal-cvs/install.php?profile=).

I also tried to install at the root directory but it also cannot continue.

erdemkose’s picture

StatusFileSize
new666 bytes

Here is the patch that I use to install Drupal CVS.

erdemkose’s picture

Status: Active » Needs review
beginner’s picture

StatusFileSize
new738 bytes

Trying to apply the patch #18, I had the error:
patch: **** malformed patch at line 11

I am not senior enough to know whether this is the right fix or not. I tested and it works for me though.

I attach a new, clean patch which includes only one change: I remove the redundant $profile and $install_locale from the global line.

drumm’s picture

Status: Needs review » Needs work

Looks like we could pass $profile to that function as a normal argument. No need to remove the global with this patch, but we should move in that direction instead of adding duplicate code to manage global variables.

beginner’s picture

Status: Needs work » Needs review
StatusFileSize
new1.19 KB

I don't know about $install_locale, but I have included it because erdemkose has reported he needed them set this way, too (erdemkose: can you confirm?).
I must remove the two variables from the line with the global definition, otherwise the install fails for me.

I'm not sure what the default for $install_locale should be. 'en'?

This patch works for me.

beginner’s picture

Assigned: Unassigned » beginner
nickl’s picture

StatusFileSize
new1.14 KB

Tested and still works on systems not experiencing this issue.
Making the default $install_locale = '' will be sufficient because it is converted to boolean and omitted if blank.

function install_settings_form($profile, $install_locale, $settings_file, $db_url, $db_type, $db_prefix, $db_user, $db_pass, $db_host, $db_port, $db_path) {

...
$form['#action'] = "install.php?profile=$profile" . ($install_locale ? "&locale=$install_locale" : '');

Fixed comments no need for full doxygen IMO and if it is needed then type indicators should be removed in @param.

@erdemkose please test the patch and RTBC if it works for you.

erdemkose’s picture

Status: Needs review » Reviewed & tested by the community

It works for me.

drumm’s picture

Status: Reviewed & tested by the community » Fixed

Committed to HEAD.

Feel free to reopen this and remove the rest of these globals. I only see them used in one other place.

Anonymous’s picture

Status: Fixed » Closed (fixed)