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.Let's come to a consensus on the UI context for the upgrade form (how it relates to the general Drupal admin interface), at least for the initial introduction to core (it will of course be subject to change once a wider audience engages with it). Where (at what URI) will the upgrade form live? How will people get to it? How will it be rendered? Where do you land when the upgrade is done?
URI and how to get to it: The current location in the POC for beginning the upgrade process is admin/config/system/upgrade, where it would be permanently linked. Alternatively, given that it is likely a one-time operation, we could treat it more like the existing install and update processes, with a top-level URI (say, /upgrade) which would not be linked within the admin interface. Perhaps the install process could link to it at the end... "If you are upgrading from an existing Drupal 6 or Drupal 7 site, click here"?
State of migrate_drupal: And that last bit reminded me - the migrate and migrate_drupal modules must be enabled to be able to run the upgrade - when/how does that happen? Enable them in the standard profile? Does clicking that "if you are upgrading..." button enable them automatically?
Site configuration: And continuing down that road - if we're offering the upgrade option at the end of the install process, what opportunity is there for the site maintainer to do any pre-migration configuration of the site (in particular, enabling any modules they want to migrate into)? We previously decided that the migration process should not unilaterally enable modules...
Rendering: The current thinking is that the upgrade forms will be rendered with the maintenance_theme if configured, otherwise the admin theme, with the admin toolbar suppressed. I think we have a consensus on this, it's just a little trickier than one might think to implement...
Landing page: This should probably be a standalone "congratulations, you've imported X kinds of content", with similar (if not identical) links where to go next as the installation process.
Until a consensus emerges, I plan on updating the ui_poc branch as follows:
- URI at /upgrade, not in the admin interface.
- Implement a standalone landing page, modeled on install.php's last page.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 2242605-migrate-congrats-message.png | 61 KB | yoroy |
Comments
Comment #1
mikeryanOh, the install process just goes directly to the front page now, with a "Congratulations, you installed Drupal!" message. Well, for consistency's sake, let's just ape that with s/installed/updated/ for now.
Comment #2
mikeryanui_poc branch updated as promised.
Comment #3
mikeryanBump... Any feedback?
Comment #4
mikeryanComment #5
chx CreditAttribution: chx commentedI will solicit input from others but this is a core issue for sure.
Comment #6
Bojhan CreditAttribution: Bojhan commentedI think this is in line with my suggestions. To get this nicely in core we should probably have a structured issue summary, with a screen/screencast.
Comment #7
yoroy CreditAttribution: yoroy commentedYes, I imagine this would live at /upgrade
I'm not familiar with Migrate, but from reading this issue it seems that you need a working (empty?) D8 first and then start the migration process (guess that makes sense though).
And yes, the separate 'Congratulations, you installed Drupal' page has been removed, it's now a message on the default /node page after that. Is that where the migrate process can begin?
The necessary Migrate modules should probably at the least be enabled automatically once a 'Migrate' button gets clicked. Maybe enabled by default in standard install profile.
Is contrib Migrate module still a good reference point for how the UI (should) work?
Comment #8
mikeryanNot this UI - this will be a very simple, minimal UI just for performing Drupal upgrades. There will be a new contrib module (tentatively named migrate_plus) which will have the D7 contrib functionality that is not going into core, such as the dashboard and field mapping editor.
Comment #9
yoroy CreditAttribution: yoroy commentedOk, was this enough feedback? If this needs more specific UI guidance I need a bit more info on what form elements etc. live on this upgrade screen.
Comment #10
ultimikeRegarding a couple of the points mentioned in the issue summary (enabling the migrate and migrate_drupal modules and giving users the opportunity to do some site configuration prior to running the migration), do we want to consider a separate "upgrade from D6/D7" profile that enables the migrate and migrate_drupal modules then brings the user to a new page describing the process with some instructions (thus giving them a chance to do some site configuration prior to hitting the "Migrate!" button?
-mike
Comment #11
webchickWe talked about this a little yesterday at Drupal South. What we thought would be best is:
Before the migration even runs, show a "status report" screen that shows a list of modules and which ones' tables are covered and which ones aren't. benjy pointed out that we should be able to do this with the
source_providerproperty, and diff a list of those against the list of enabled modules in the system table. Something like this:This list would be longer in real life and resemble admin/reports/status. In this (theoretical) scenario, Blog is enabled in the D6/D7 site, and it has a system.schema > 0 (indicating it defines data), and we detect "blog" in the list of source providers. In the case of Color, it's enabled, but its system.schema is only 0, indicating that there's no hook_install() and therefore nothing to migrate. In the case of Version Control Git, we can see the module's enabled, and it defines tables, but there is no source_provider defined. Meaning, we need the contrib module author to write one still before migration can be considered complete.
This will not catch everything. If someone had a module that hook_schema_alter()ed the node table, obviously we won't catch that hasn't moved over. But it should at least tell you about the "90% case" which is a contrib module's migrations are quite simply missing, without requiring site builders to trawl around in the DB/code checking for this.
Comment #12
chx CreditAttribution: chx commentedThis is not so simple. What about, for example, CCK? Profile?
Comment #13
benjy CreditAttribution: benjy commentedas always :) CCK isn't going to be as easy but still doable. Do we want to create a new issue for the status page? Maybe in the migrate upgrade sandbox?
Comment #14
mikeryanReparented to the core meta issue for the UI.
Comment #15
benjy CreditAttribution: benjy commentedOne thing to note is that the status page will need the legacy database credentials. How about two buttons at the bottom of the current form, one for "Perform Upgrade" and another for "Show me an overview". That way, if you click the overview button we store the credentials, generate the report and when they're done we could easily kick them onto the batch, otherwise, clicking "Perform Upgrade" would work as it does now.
Do we need some design input or do we just copy the status page in terms of design?
Comment #16
benjy CreditAttribution: benjy at PreviousNext commentedI think we can close this now the UI is in core.