The way aegir handles writing the files folders is not flexible. The settings.php template actually hard codes /sites/domain.com/files right in the template. To change a site's files folder, you would have to write an entirely new template, then figure out how to get provision to use it.
This branch will make the important Drupal settings for files full context properties so they can be overwritten in the future.
This will allow an add-on module to be created to allow sites to customize their own files folder, and makes it possible to manually edit a site context's file_public_path property, if they would like.
Update
See Patch here:
https://git.drupalcode.org/project/provision/compare/7.x-3.x...3016995-f...
Comment | File | Size | Author |
---|---|---|---|
#20 | Screenshot from 2019-09-20 12-34-17.png | 40.33 KB | Jon Pugh |
#8 | 3016995-file-path-properties.patch | 1.56 KB | tucho |
#6 | 3016995-file-path-properties.patch | 5.57 KB | Jon Pugh |
Comments
Comment #2
Jon PughComment #5
Jon PughComment #6
Jon PughComment #7
helmo CreditAttribution: helmo at Initfour websolutions for DNV GL commentedNice, that reads better :)
Comment #8
tuchoHi @Jon Pugh !
I made the attached patch against the last commit of the 3016995-file-path-properties branch.
It correct one of the paths that you have changed in previous commits: The one that was sites/$url/files/tmp and the directories for the config syncronization.
I think that another thing that you be modified is the synchronization of the files from the web servers to the hostmaster when a backup is made (or before a migration). Currently this is taken care in the provision_drupal_fetch_site function.
Comment #9
colanComment #11
Jon PughComment #13
Jon PughTHANK YOU tucho...
Let's get this reviewed and merged?
I'm going to include it in the devshop-7.x-3.x branch so that we start using it right away.
Comment #14
Jon PughComment #15
helmo CreditAttribution: helmo at Initfour websolutions for DNV GL commentedI've not been able to fully test this, but it looks OK. Probably ok to commit and verify before the next release.
Comment #16
Jon PughLet's make sure to fully test it. :)
I'm about to add a commit to drush_provision_drupal_provision_delete(), now that files paths can be outside of site root, they need to be explicitly deleted.
Comment #17
Jon PughThere's also some code for hosting coming through.
Comment #19
Jon PughComment #20
Jon PughAdded Hosting schema, form elements, Hosting settings checkbox for "Allow sites to have custom file paths for public, private, and temporary files.".
Works great!
Comment #21
josebc CreditAttribution: josebc at Vardot commentedNice work on this, is testing on remote cluster and its not syncing the path to remotes
im trying something like "sites/something/files"
Maybe we need to change something in provision_drupal_push_site??
Comment #22
Jon PughStill seems to change ownership of sites/folder files still.
Comment #24
Jon PughThis new feature should implement the new sync path hook, since the files can now live outside of the root as well: #3016995: Make file directories first class context properties.
Comment #25
Jon PughComment #26
Jon PughCan we identify what is blocking this from moving forward?
Comment #27
froboy@jon-pugh I've tested merging this into master and ran into a few conflicts. I'm not sure what the best way to make changes is since this is a branch and not a patch.
provision_drupal_settings_8.tpl.php
are conflicting: config_sync_directory and file_temp_path. Those are trivial resolutions.config_sync_directory
should probably have its own option now too?platform/provision_drupal.drush.inc
has... a lot of conflicts.Comment #29
Jon PughThe config sync dir is very often used by developers and managed in the same git repo as the site codebase. Common practice is to put it in the git root, ./config/sync.
I don't agree this should be put in settings.php by default. The decisions should be cognizant that not everyone will use multisite, not everyone will want to use sites/DOMAIN.COM folders.
I am moving forward on the 4.x branch and will likely not merge any additional changes FROM 3.x.
There have been too many changes to 3.x I don't agree with so I'm moving all my work to 4.x.
Comment #33
Jon Pugh