install.php: Language selected twice [#172262]

I wonder whether I'm the only one who observed this...

I did quite a few 6.x-dev test-installs now on my local machine for testing (MySQL 4.1.19 / PHP 4.4.4 / Apache 1.3.37 / FireFox 2 - all sitting together on the same comp running Mandriva Linux 2007.0), and it goes always like this:

- Select language (English)
- Database settings
- AGAIN SELECT LANGUAGE
- Configuration
- Done, visit your new site.

It's quite confusing, after submitting database form, the language selection reappears, also the progress overview (left sidebar) being visually reset to begin, so it looks like install starts from scratch again. But after selecting the language again, Configuration appears and the process continues well.

I understood that the language-page reappears, because the 'locale' GET parameter is lost somewhere in the process of form-submitting, but I'm unable to really track the problem (there's the Form API involved, which I don't know properly). However, I observed that in install_settings_form_submit() there is not the global variable $install_locale available, but $_GET['locale'] is.

So I'm attaching a patch, which solved the problem for me. Please keep in mind, that this is only just based on OBSERVED behaviour, issue-starter solution, without in-depth analysis - so it's entirely possible that my solution is not clean one!

Comment	File	Size	Author
#5	install-globals.patch	1.49 KB	JirkaRybka
#5
	install-locale.patch	461 bytes	JirkaRybka

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

ChrisKennedy CreditAttribution: ChrisKennedy commented 1 September 2007 at 16:23

http://drupal.org/node/171267 looks like it might fix this problem - perhaps give it a try?

Comment #2

JirkaRybka CreditAttribution: JirkaRybka commented 1 September 2007 at 16:40

I just tried with redirect_d6.patch from #2 at http://drupal.org/node/171267, which applied smoothly.

Unfortunately, it didn't help. There's no difference, install still behaving as said above.

But still I think, that the problem is of similar nature and probably related. BTW, there are TWO parameters at the critical point, one passed (profile) and the other not (locale). I even tried to swap them, and still profile goes through, and locale not. This seems really weird to me.

Comment #3

JirkaRybka CreditAttribution: JirkaRybka commented 7 September 2007 at 18:35

I must say, that I'm unable to get any further with this, than the hack attached above (which might be acceptable for one-time job like install, and works fine for me), so feel free to continue without me (if there's someone willing). The installer behavior is really annoying.

Comment #4

Gábor Hojtsy

he/him

Hungarian

Hungary

CreditAttribution: Gábor Hojtsy commented 7 September 2007 at 19:04

Just as the $profile global is set earlier, $install_locale should also be set. This path should be examined IMHO.

Comment #5

JirkaRybka CreditAttribution: JirkaRybka commented 8 September 2007 at 12:43

File	Size
install-globals.patch	1.49 KB

Despite my statement above, I didn't resist and proceeded to examine the problem further (a lot of struggle), and finally FOUND IT :-)

It's pretty simple in fact: install.php calls drupal_bootstrap(DRUPAL_BOOTSTRAP_CONFIGURATION), which unsets all globals (excepting few explicitly allowed ones), so the $install_locale variable wasn't global at all. Just swapping lines, to get the global AFTER drupal_bootstrap() solved the problem. I also added a comment, because this behavior is really NOT obvious.

In bootstrap.inc I also discovered, that update.php previously fixed the same by adding its global variable to the allowed list. Since the update setting is now both renamed and moved elsewhere (http://drupal.org/node/170638), old variable is no more used - was just a dead entry in the list, so I removed it now.

I didn't choose to add the install.php globals to the list, as the line-swapping solution is more simple and readable - doesn't require to update variable names at two different places (not easy to find), and also doesn't spam the allowed list with one-time-used entries.

Patch attached.

Comment #6

Gábor Hojtsy

he/him

Hungarian

Hungary

CreditAttribution: Gábor Hojtsy commented 8 September 2007 at 13:20

Seems reasonable to me, but it would be good to have someone else's eye on this. How was the profile remembered at the first place, if the globals were removed?

Comment #7

JirkaRybka CreditAttribution: JirkaRybka commented 8 September 2007 at 14:54

I just did a few more tests... Discovered that profile was NOT remembered - if I clone the 'default' profile to another name and select that one for installation, after the critical point the profile parameter is reset to 'default'! I'm not sure where this default value 'default' originates from (which is irrelevant IMO), but it's NOT the setting from previous install-steps. So this is another bug fixed by the patch - patched version remembers profile OK.

As for the third global variable $conf, it's already set global elsewhere ( conf_init() in bootstrap.inc ), so this one is not affected.

Comment #8

JirkaRybka CreditAttribution: JirkaRybka commented 9 September 2007 at 09:32

The nature of drupal_unset_globals() suggests, that the problem only happens if php is configured to register_globals on (which is the case of my test install; otherwise the globals unsetting is not executed). This is probably why others didn't notice this before, and also a suggestion for anyone trying to reproduce the bug: Just install D6 with register_globals on.