Problem/Motivation

When preparing for a migration using the core d7_file migration, the developer is required to create the directory structure sites/default/files/ for the public files, and something similar if there are also private files to be migrated. This is inconvenient.

Proposed resolution

Support whatever directories are convenient and let the developer enter those directories on the credential form, /upgrade/credentials.

Do something similar for migrations from Drupal 6.

Remaining tasks

User interface changes

We will have to update the UI text on the credential form, /upgrade/credentials.

API changes

None

Data model changes

None

Release notes snippet

TODO

Comments

benjifisher created an issue. See original summary.

quietone’s picture

quietone commented

I would think it is not sites/default/files/ but the file paths defined in the source site variables for the file paths.

@benjifisher, why not just put the files in the destination at sites/default/files? And, I think, what you are asking for is a way for that path to be ignored when building the full path to the source files. Is that right?

Should we make a documentation page, with examples?

benjifisher’s picture

benjifisher
he/him or they/them
Primary language English
Location Boston area
commented

Yes, sites/default/files/ is the default value. Many of my migration projects keep the default, but it could be something different.

Why not put them there? It is a question of convenience.

  • When preparing for migration, I have to create the directories (mkdir -p sites/default/files) and expand a tarball there.
  • When a file is not found, I have to check whether it is my fault or if the file is missing on the source: ls files/site/default/files/subdir/missing-file* instead of ls files/subdir/missing-file*

There are a lot of ways around the first point. If I am using rsync, then I have to add the path to the command. If I am using drush rsync, then I have to add the path in my site-alias file. However I do it, it is an extra step.

The second point means that it is not strictly a one-time inconvenience.

Maybe the real argument is not the convenience but how easy it is to write and then follow the documentation. In fact, the advantage is greatest when the source site does not use sites/default/files/.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.