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.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | patch_141.txt | 1.89 KB | webernet |
| #1 | install.php__10.patch | 1.96 KB | Rok Žlender |
Comments
Comment #1
Rok Žlender commentedI 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.
Comment #2
webernet commentedMarked 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.
Comment #3
gábor hojtsyWhen is index.php called during installation? This is not clear to me.
Comment #4
Rok Žlender commentedI 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.
Comment #5
gábor hojtsyThat 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...
Comment #6
Rok Žlender commentedThis 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
As you can see at the end node? is called. And both times drupal return variable looks like this.
I searched through the install code and could not find the problem.
Comment #7
gábor hojtsyThanks 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.
Comment #8
gábor hojtsyOK, added that little bit of documentation and committed the patch.
Comment #9
(not verified) commented