Problem/Motivation
This issue is about the text on the credential form, /upgrade/credentials
.
This is a follow up to #2925899: MigrateUpgradeImportBatch does not use source_private_file_path & source_base_path correctly, making it impossible to have public & private files in separate locations.
In that issue benjifisher stated,
The current form suggests (at least to me) that the files will be directly under bar/, when they are actually under bar/sites/default/files/.
Let's review the help text and make sure it is clear to everyone where the files need to be. Use the description in the makeFiles method from the patch in 2925899-Comment#39 for inspiration.
For reference here are the current descriptions.
When the source site is Drupal 6:
Files directory
To import files from your current Drupal site, enter a local file directory containing your site (e.g. /var/www/docroot), or your site address (for example http://example.com).
When the source site is Drupal 7:
Public files directory
To import public files from your current Drupal site, enter a local file directory containing your site (e.g. /var/www/docroot), or your site address (for example http://example.com).
Private files directory
To import private files from your current Drupal site, enter a local file directory containing your site (e.g. /var/www/docroot).
Proposed resolution
Leave the help text unchanged, but use the following text for the field labels:
- Drupal 6 source: "Document root for files"
- Drupal 7 source: "Document root for public files" and "Document root for private files"
Remaining tasks
User interface changes
On the credential form (/upgrade/credentials
):
Before
Drupal 6
Drupal 7
After
Drupal 6
Drupal 7
API changes
Data model changes
Release notes snippet
Comment | File | Size | Author |
---|---|---|---|
#10 | after-drupal7.png | 28.66 KB | benjifisher |
#10 | after-drupal6.png | 16.01 KB | benjifisher |
#10 | before-drupal7.png | 27.99 KB | benjifisher |
#10 | before-drupal6.png | 15.48 KB | benjifisher |
#8 | 3151360-8.patch | 3 KB | quietone |
Comments
Comment #2
quietone CreditAttribution: quietone as a volunteer commentedAdd tag
Comment #3
tonytheferg CreditAttribution: tonytheferg commentedYeah I ran into this. The difficulty is people will default to thinking they should provide sites/default/files portion of the path. Maybe a note to make sure they don't include that would be helpful.
Here is a Q&A I posted on Drupal Answers
https://drupal.stackexchange.com/a/284012/93997
Comment #4
benjifisherI think the current help text (description) is clear enough. What I find confusing are the labels: "Public files directory" and "Private files directory". (I am adding the missing word "directory" to both in the issue summary.)
One suggestion: change those to "Document root for public files" and "Document root for private files".
Comment #5
tonytheferg CreditAttribution: tonytheferg commentedComment #6
quietone CreditAttribution: quietone as a volunteer commentedAdding patch and screenshots.
Comment #8
quietone CreditAttribution: quietone as a volunteer commentedFixed the D6 string to not use 'public'. Added fix for the tests. No interdiff because this is small and it would be noise.
Comment #9
tonytheferg CreditAttribution: tonytheferg commentedLooks better!
Comment #10
benjifisher@ToneLoc:
Thanks for the feedback!
I agree, the wording is an improvement. The code change is simple, just text changes to the form and the related tests. RTBC.
I am replacing the screenshots with new ones using the Seven theme, and adding a "before" screenshot for a Drupal 6 source.
Comment #11
benjifisherPeople who run migrations with drush can use
drush mmsg ...
and figure out from the logged messages where the files are supposed to be. Until #3063856: Add ability to view migrate_message table data is fixed, there is no way to get that information for people who run migrations through the UI.That makes it especially important for this UI to be clear.
Comment #12
alexpottHere's a question - how and when is the document root for private and public files going to be different? I don't understand how providing the document root to the private files is going to work?
+1 though to moving away from the existing terminology because it definitely makes you think you need to put your public and private directories from the file system admin page in here.
Comment #13
benjifisherThat is a good question. Another good question: why should we stage files for migration in a directory structure that looks like the source?
When I prepare a migration, I typically download all the files from the old site and put them ... somewhere on the site I am building. It would be convenient if I could use (relative to the docroot)
../files/public/
and../files/private/
or something similar. Instead, I use something like../files/sites/default/files/
(for public files).I was 90% serious in #2925899-33: MigrateUpgradeImportBatch does not use source_private_file_path & source_base_path correctly, making it impossible to have public & private files in separate locations:
In the long run, I would like to change things to make it more convenient for myself: specify the path to
public://
and the path toprivate://
and go back to the original labels. In other words, I should not have to createsites/default/files/
(for the public files). I have not thought about how that will look for D6 sources, and I have not thought about what has to change in the code to make that happen.I have thought about how much of a change this will be, and that gives me a headache. Change record, release notes, automated tests. Maybe it is so disruptive that we should wait for Drupal 10.0.
For the current issue, I hope to keep the scope small: update the labels so that they better describe the way the system currently works.
Comment #14
benjifisherI added #3159217: Be more flexible in where files are staged for migration.
Comment #15
alexpottOkay I'm going to commit this to 9.1.x as it is a string change. My original reaction of "why are we deviating from the language used on the system files form?" shows the confusion is real.
I'm going to ping this to the other committers to discuss backport because I think the current labels are wrong enough to be considered a bug.
Committed 9805714 and pushed to 9.1.x. Thanks!
Comment #17
catchThis seems wrong enough to be considered a bug for backport, and it seems likely that some sites will still be trying to migrate to 8.9.x, at least until 9.1.x is released.
Comment #18
benjifisherDuring one of my DrupalCon sessions today, the speaker asked who had migrated to D9. At least one response was "I am still waiting for a few modules that are not yet D9 compatible.".
Comment #19
alexpottOkay backported this to 8.9.x as per #17.