Problem:
After configuring during the install process. On first load the new site name is not used.

To reproduce:
Do a clean install, enter site name sth else than Drupal. And the name will not display on the next page as it should.

Where could the problem be:
In install_configure_form_submit in install.php we do some variable_sets which does not clear_cache because stub cache-install.inc is used during install. Nevertheless somewhere during the install process sth gets written to {cache} but not the new sitemail and sitename variables. I've been doing some debugging and cache_set is called once during install process but not from install.php but from index.php during normal bootstrap.

I hope I've been clear enough.

CommentFileSizeAuthor
#2 patch_141.txt1.89 KBwebernet
#1 install.php__10.patch1.96 KBRok Žlender
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Rok Žlender’s picture

Status: Active » Needs review
FileSize
1.96 KB

I created a patch which modifies install.php to use normal cache.inc if database is already up and running and stubbed cache-install.inc otherwise. I tested it and it seems to work fine.

webernet’s picture

Title: After install old cached variables are used » After install, old cached variables are used instead of those chosen using installer
FileSize
1.89 KB

Marked http://drupal.org/node/152510 as a duplicate.

Tested patch and it does fix the problem site name, clean URL settings, etc. not being used immediately after install.

Rerolled with improved comments.

Gábor Hojtsy’s picture

When is index.php called during installation? This is not clear to me.

Rok Žlender’s picture

I do not understand it either. I just noticed that if I set a brakepoint in my debugger on first line of index.php it stops there after every sucessfull load of install.php. To clarify install.php page is already loaded and after that index.php is called.

Gábor Hojtsy’s picture

Status: Needs review » Needs work

That should only happen if there is a referenced image in the installer HTML output, some referenced resource in the CSS, which is not on the site at the place referenced. So when the browser tries to load it in, index.php gets called to handle the 404, due to the .htaccess. It should be found out what results in this, that should fix the real problem. Fixing the real problem we could overcome other bad side effects of this misbehavior...

Rok Žlender’s picture

This is what I found out.
Drupal index.php is called twice after configuration page is loaded and after install complete is loaded. Both times apache access log looks the same

127.0.0.1 - - [20/Jun/2007:00:16:06 +0200] "POST /drupalBUG/install.php?profile=default&locale=en HTTP/1.1" 200 3927
127.0.0.1 - - [20/Jun/2007:00:16:06 +0200] "GET /drupalBUG/misc/maintenance.css HTTP/1.1" 200 428
127.0.0.1 - - [20/Jun/2007:00:16:06 +0200] "GET /drupalBUG/modules/system/defaults.css HTTP/1.1" 200 756
127.0.0.1 - - [20/Jun/2007:00:16:06 +0200] "GET /drupalBUG/modules/system/system.css HTTP/1.1" 200 9012
127.0.0.1 - - [20/Jun/2007:00:16:06 +0200] "GET /drupalBUG/misc/favicon.ico HTTP/1.1" 200 1150
127.0.0.1 - - [20/Jun/2007:00:16:06 +0200] "GET /drupalBUG/misc/jquery.js HTTP/1.1" 200 21217
127.0.0.1 - - [20/Jun/2007:00:16:07 +0200] "GET /drupalBUG/misc/drupal.js HTTP/1.1" 200 11553
127.0.0.1 - - [20/Jun/2007:00:16:07 +0200] "GET /drupalBUG/modules/user/user.js HTTP/1.1" 200 6719
127.0.0.1 - - [20/Jun/2007:00:16:07 +0200] "GET /drupalBUG/modules/system/system.js HTTP/1.1" 200 3396
127.0.0.1 - - [20/Jun/2007:00:16:07 +0200] "GET /drupalBUG/themes/garland/minnelli/style.css HTTP/1.1" 200 397
127.0.0.1 - - [20/Jun/2007:00:16:07 +0200] "GET /drupalBUG/themes/garland/style.css HTTP/1.1" 200 17266
127.0.0.1 - - [20/Jun/2007:00:16:07 +0200] "GET /drupalBUG/themes/garland/minnelli/logo.png HTTP/1.1" 200 5399
127.0.0.1 - - [20/Jun/2007:00:16:07 +0200] "GET /drupalBUG/themes/garland/images/bg-navigation.png HTTP/1.1" 200 104
127.0.0.1 - - [20/Jun/2007:00:16:07 +0200] "GET /drupalBUG/themes/garland/images/body.png HTTP/1.1" 200 712
127.0.0.1 - - [20/Jun/2007:00:16:07 +0200] "GET /drupalBUG/misc/watchdog-ok.png HTTP/1.1" 200 3217
127.0.0.1 - - [20/Jun/2007:00:16:07 +0200] "GET /drupalBUG/themes/garland/images/bg-content.png HTTP/1.1" 200 485
127.0.0.1 - - [20/Jun/2007:00:16:07 +0200] "GET /drupalBUG/themes/garland/images/bg-content-right.png HTTP/1.1" 200 3169
127.0.0.1 - - [20/Jun/2007:00:16:07 +0200] "GET /drupalBUG/themes/garland/images/bg-content-left.png HTTP/1.1" 200 3275
127.0.0.1 - - [20/Jun/2007:00:16:07 +0200] "GET /drupalBUG/misc/favicon.ico HTTP/1.1" 200 1150
127.0.0.1 - - [20/Jun/2007:00:16:07 +0200] "GET /drupalBUG/node? HTTP/1.1" 200 4167

As you can see at the end node? is called. And both times drupal return variable looks like this.

<div id="first-time"><h1 class="title">Welcome to your new Drupal website!</h1><p>Please follow these steps to set up and start using your website:</p><ol><li><strong>Configure your website</strong> Once logged in, visit the <a href="/drupalBUG/?q=admin">administration section</a>, where you can <a href="/drupalBUG/?q=admin/settings">customize and configure</a> all aspects of your website.</li><li><strong>Enable additional functionality</strong> Next, visit the <a href="/drupalBUG/?q=admin/build/modules">module list</a> and enable features which suit your specific needs. You can find additional modules in the <a href="http://drupal.org/project/modules">Drupal modules download section</a>.</li><li><strong>Customize your website design</strong> To change the "look and feel" of your website, visit the <a href="/drupalBUG/?q=admin/build/themes">themes section</a>. You may choose from one of the included themes or download additional themes from the <a href="http://drupal.org/project/themes">Drupal themes download

I searched through the install code and could not find the problem.

Gábor Hojtsy’s picture

Thanks for the deep investigation. Now that we see that this runs on the configuration page, I see it is the clean URL check doing its work to find out what does it get in return. Look into system.js and you will see it invokes the node page. So this bootstraps Drupal in the middle of the install process, which fills up the database caches, and the settings made in the installer did not get through to the cache as we empty the cache of the empty stub installer cache "backend".

It would be nice to add a little more documentation to the if ($verify) case about why we use the normal cache, and this patch seems to be a nice fix to go in.

Gábor Hojtsy’s picture

Status: Needs work » Fixed

OK, added that little bit of documentation and committed the patch.

Anonymous’s picture

Status: Fixed » Closed (fixed)