D5->D6: files path not carried over
hass - January 17, 2008 - 22:45
| Project: | Drupal |
| Version: | 6.x-dev |
| Component: | update system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
After the update has finished there is a sites\default\files directory created.
It does not looks completely wrong, not moving all drupal6\files content over, but why is drupal6\sites\default\files\languages and drupal6\sites\default\files\pictures and "drupal6\css" (???) created if this is not my sites files directory. Additional to this there is a de_bc87c4fd79ebbb2e0ce5e28ac07fbc4e.js file created in languages.
Sorry for reporting this only, but i haven't the time to look in and it looks very strange to me.
I tried this on IIS 5.1 with ISAPI_Rewrite 3.x.
#1
This is not a bug, and is definitely not a critical issue. This is the correct action/directory structure and by design.
#2
Creating "drupal6\css" is not by design... this is a bug. It must be created inside the files directory as the others, too.
#3
Not a show stopper.
Please provide more information.
What are you upgrading from/to?
What database server and version?
What modules do you have enabled?
Please provide steps to reproduce the error.
#4
Hass: the update should leave your files directory and setting intact and it should not create the sites/default/files directory, neither create subdirectories or files there, neither change your settings. I'd watch for how your settings are used in the update, whether there is a level of bootstrap done there as required to use the settings from the variables table properly or not.
#5
Look inside the title. If my installation get crippled - is this critical or not? I think so.
#6
@Gabor: Ok, then we have a bug fore sure. Upgraded and the directory has been created in sites/default/files, nevertheless "files" already existed. Additional a "css" folder has been created in website's root what is totally wrong, too.
I clicked the admin page link after upgrade... may give an idea...
#7
Only thing I can think of is system_requrements() now gets called from update.php since http://drupal.org/node/200674 went in.
// For installer, create the directory if possible.if ($phase == 'install' && !is_dir($directory) && @mkdir($directory)) {
@chmod($directory, 0775); // Necessary for non-webserver users.
}
Any chance this is firing?
#8
Better title.
#9
Is it possible the directory was never recorded in the variables table and was instead using the default?
#10
Drop'ed my D6 DB and imported D5 DB again and checked the variables table:
'file_directory_path', 's:5:"files";'. Looks good.Upgraded again and it works. Drop'ed again and upgraded again, works. Drop'ed again and upgraded again, works. I'm sorry, but i cannot reproduce this anymore. If something goes wrong once it should be reproducible, but i have no clue what's happen here and why it works now. :-(((
#11
OK I'm sticking this back to normal and active (needs more info) until someone can reproduce (obviously hoping that they can't). hass, nice one checking it again so thoroughly.
#12
I seem unable to find any update function for the case of a 5.x site without files path setting (i.e. running with the default, without having a variable set). Do we have one, somewhere? And do we need one, is it possible to have 5.x site without the variable set? If so, then the changed default in 6.x needs to be accompanied by some update function.
#13
JirkaRybka: yes, that's a possible case for a problem here. The files variable is only set if the user ever submitted the files setup page (which the site status report page tried to press people to do :) or done some similar action in a contrib module, but that is not ensured. We can check if there was no files variable and set it to the old default to make sure everything will be fine.
#14
I used my production backup for this test... This install have set a files directory for sure as reported above. Shouldn't be the problem i found...
#15
I can confirm that the update should not create sites/default/files.
@catch #7: mkdir($directory) is not executed since
$phase == 'install'is false. I checked during an update, and sites/default/files was never created. It is created during the install only. Also when visiting admin/settings/file-system (without submitting), Drupal will try to create the directory which is in the current file_directory_path value: sites/default/files on a fresh D6, or files or whatever you had in your D5 database if you've updated.#16
@scor, yeah that's what I figured but stranger things have happened, seems to have been a fluke on hass' system rather than something reproducable anyway.
#17
It would still be good to ensure there is a files variable setup on upgrades, if there was no files variable before. So that the new default is not used.
#18
I've rolled a small patch for this. Tested on my real site (using the dafault 'files' path), with the variable manually removed (via PhpMyAdmin, pre-update of course).
#19
Looks good, committed, thanks.
#20
Automatically closed -- issue fixed for two weeks with no activity.