Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#18 | update-files-default.patch | 887 bytes | JirkaRybka |
Comments
Comment #1
Anonymous (not verified) CreditAttribution: Anonymous commentedThis is not a bug, and is definitely not a critical issue. This is the correct action/directory structure and by design.
Comment #2
hass CreditAttribution: hass commentedCreating "drupal6\css" is not by design... this is a bug. It must be created inside the files directory as the others, too.
Comment #3
Anonymous (not verified) CreditAttribution: Anonymous commentedNot 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.
Comment #4
Gábor HojtsyHass: 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.
Comment #5
hass CreditAttribution: hass commentedLook inside the title. If my installation get crippled - is this critical or not? I think so.
Comment #6
hass CreditAttribution: hass commented@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...
Comment #7
catchOnly thing I can think of is system_requrements() now gets called from update.php since http://drupal.org/node/200674 went in.
Any chance this is firing?
Comment #8
Gábor HojtsyBetter title.
Comment #9
webernet CreditAttribution: webernet commentedIs it possible the directory was never recorded in the variables table and was instead using the default?
Comment #10
hass CreditAttribution: hass commentedDrop'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. :-(((
Comment #11
catchOK 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.
Comment #12
JirkaRybka CreditAttribution: JirkaRybka commentedI 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.
Comment #13
Gábor HojtsyJirkaRybka: 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.
Comment #14
hass CreditAttribution: hass commentedI 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...
Comment #15
scor CreditAttribution: scor commentedI 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.Comment #16
catch@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.
Comment #17
Gábor HojtsyIt 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.
Comment #18
JirkaRybka CreditAttribution: JirkaRybka commentedI'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).
Comment #19
Gábor HojtsyLooks good, committed, thanks.
Comment #20
Anonymous (not verified) CreditAttribution: Anonymous commentedAutomatically closed -- issue fixed for two weeks with no activity.