I have run into a problem with the installation process that is confusing and seems like a bug. On a hosted server (HostRocket), when I attempt to install Drupal, the process loops back to the "Select an installation profile" page after the user has filled in the dbname/username/password page. A check behind the scenes at this point reveals that:

1) settings.php HAS been altered to the local db settings, and
2) None of the db tables have been created

The URL on this second iteration of the page has "profile=" at the end without a profile name.

If I now submit from this page, the site gets initialized correctly. It seems like the installation routines don't recheck the validity of the db connection after settings.php gets changed, and so they short out without fully installing the db. I think that re-starting the script re-triggers the check in install_verify_settings(), which checks out okay, and the installation finishes correctly. But I'm guessing here.

CommentFileSizeAuthor
#6 install-globals-d5.patch593 bytesJirkaRybka

Comments

sunfish62’s picture

sunfish62 commented

Does anyone on the development team have suggestions on how to resolve this question?

sunfish62’s picture

sunfish62 commented

Now, I have been able to duplicate this problem on a different host (1and1), so I don't believe it's a problem with the host. It appears to be a problem with Drupal's installation code.

Is there anyone in the Drupal community who is examining and maintaining the installation code? Can ANYONE offer suggestions on how to remedy this problem? This is a serious show stopper for anyone trying to create a functional installation profile.

sunfish62’s picture

sunfish62 commented

Can someone please advise: is there anyone working on these issues, or is all the energy being put into preparing for version 6?

The problem I outline here is somewhat fundamental to the installation process; its failure to function correctly renders the installation routine largely useless for anything other than a basic, unenhanced Drupal installation.

sunfish62’s picture

sunfish62 commented

Well, five weeks and no response to my most recent posting on this. I will have to assume that the installation code is considered a completed project, and not expect its functionality or capabilities to change or improve. This is lamentable, as Drupal as a platform has a lot going for it; it is too bad that the community ambiance serves as an effective deterrent for all but those who have the programming expertise to debug and rewrite complex PHP code.

JirkaRybka’s picture

JirkaRybka commented

I've fixed very similar issue for Drupal 6: http://drupal.org/node/172262

Since the symptoms are the same as far as I can see (restarts after DB selection page, but after further submit continues well), and the affected code is identical in D5 branch (I checked in CVS for both Drupal 5.1 and 5.2 - no changes in there), I'm tempted to say that this is the same problem, and my patch from the other issue needs to be ported to Drupal 5.

Please check:

- Whether you have 'register_globals' set to ON or not (go to Status Report in Drupal, and click on the PHP version number; search for the 'register_globals' line) - this is the trigger of 6.x bug, so if you've this setting ON, then it confirms it's probably the same bug.

- Whether the 6.x patch helps or not: The patch is http://drupal.org/files/issues/install-globals.patch (#5 at http://drupal.org/node/172262 ) and you need only the second half for Drupal 5 - not the first! So, to summarize, you need to open install.php and just move the line near top starting with 'global' down, to be below 'drupal_bootstrap'.

If that helps, then we need to backport (second half of) my patch to Drupal 5 branch. In that case, please set this issue to version: 5.x-dev and status: patch (to be ported).

JirkaRybka’s picture

JirkaRybka commented
Version: 5.1 » 5.x-dev
Status: Active » Needs review
StatusFileSize
new install-globals-d5.patch593 bytes

OK, today I've more time, so I tested 5.x-dev (as well as 5.1) on the system, where mentioned 6.x bug was discovered. Unfortunately, with the official tarball I seem unable to reproduce the bug, which means that "steps to reproduce" are currently unknown. At this point, more information from the original poster would be helpful, especially focusing on any install-profile / locale bits involved (forgive me - I'm not sure about these in 5.x myself).

But however, the nature of 6.x bug suggests that this is very likely the same, still. I think so, because:
- All code involved is identical in 5.x (as 6.x had before fix)
- The only query on my test install was 'profile=default'. The same happened on 6.x, where the query, after being lost, fell back to profile 'default' too. So basically 6.x also didn't have problem with profile (unless other than 'default' used).

I went forward and rolled a backported patch for 5.x-dev. It's up to sunfish62 to tell whether this fix his problem or not, but I think the fix should be backported anyway. Needs review/judgement! (More background for my approach at http://drupal.org/node/172262 .)

sunfish62’s picture

sunfish62 commented

Jirka--

Thank you for getting involved with this. I was losing hope that anyone was paying attention. I haven't got access right now to the servers that were causing the problem, but as soon as I can, I will apply the patch and test this out. My suspicion is that your patch will fix the problem, as I was getting reset variable problems, and this directly addresses that. I will get back to you all as soon as I can.

David

sunfish62’s picture

sunfish62 commented

BTW, I forgot to check my host's PHP settings: register_globals is set ON.

JirkaRybka’s picture

JirkaRybka commented

Unfortunately, there's quite a lot of issues in the queue, so mostly, after posting a new follow-up, you've maximally a couple of days of chance to get attention, before your issue fall down from the top of queue and out of sight for most people. I think that a week is reasonable frequency to "push" on your issues by posting more information or the like.

Now waiting for your testing results.

sunfish62’s picture

sunfish62 commented

The patch fixed the installation problem I was seeing. Thank you for providing a solution to this problem! I think this can be closed now...

JirkaRybka’s picture

JirkaRybka commented

If the patch fixes your problem, then I think it should be committed to 5.x branch of Drupal, and only then this issue closed.

Anyone out there going to set this simple backport to RTBC?

JirkaRybka’s picture

JirkaRybka commented
Status: Needs review » Reviewed & tested by the community

I feel really uneasy about setting my own patches RTBC, but today I decided to make an exception, because:

- This is very simple patch
- It's a backport, already discussed and commited in 6.x branch (where the code is identical)
- Positive feedback from #10

So I believe there's enough for a commiter to decide.

drumm’s picture

drumm
he/him
Location NY, US
commented
Status: Reviewed & tested by the community » Fixed

Committed to 5.x.

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.