Problem/Motivation

#2701027: Drupal 8 UPGRADE.txt is misleading in many ways (in its name to begin with) reminded me how often people get confused between update and upgrade. This confusion is reasonable since they don't really mean anything different outside of Drupal.

However we've just added 'Drupal upgrade UI' which is a user interface for migrate/Drupal Migrate.

Additionally, if we eventually add Drupal 8 sources, it might be possible to migrate from Drupal 8 to Drupal 8, which is not an upgrade. I don't know if we'd ever want to allow that via a UI shipped in core, but it'd be possible to do if we wanted to.

Only a very small proportion of sites will be able to simply install Drupal 8 and 'upgrade' from Drupal 6 or 7 without further work. In the majority of cases they'll also need to re-install themes and contrib modules as well. So whatever happens it's a migration to a new install, not an upgrade of an existing install (which arguably 6-7 upgrades still are since with those at least you theoretically could keep the same git repo and have it make some degree of sense).

Proposed resolution

Rename the module to 'Migrate Drupal UI'.

Remaining tasks

User interface changes

API changes

Data model changes

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

catch created an issue. See original summary.

yoroy’s picture

Thanks, this needs to be cleared up indeed.

cilefen’s picture

Is this possible during 8.1 RC (or allowed because of urgency) or does it have to go to 8.2?

catch’s picture

It's an experimental module, so could be changed during RC or even during 8.1.x

The actual module name is migrate_drupal_ui already, so this is mostly interface text afaik.

mikeryan’s picture

Let's keep in mind that this UI implements a very narrow use case - importing an entire Drupal site into the current (presumably fresh and empty) Drupal 8 site. General purpose migration UIs are under development in contrib - it's going to be very confusing to have a UI in core that at first glance appears to be a general-purpose migration UI but isn't.

Gábor Hojtsy’s picture

Right, so looks like the question is what do we call the other migrate UI module that is for migrating for other systems, if we call this the migrate UI :)

yoroy’s picture

Maybe we can use this subsystem(?) as an exercise for simplefying user facing terminology: #2513398: Conduct a full-scale terminology review of Drupal (Fix Drupal terminology so that it is more accessible to users).

catch’s picture

it's going to be very confusing to have a UI in core that at first glance appears to be a general-purpose migration UI but isn't.

It's also very confusing to have a module in core that provides a UI for upgrading between Drupal versions, when we already have a UI in core for upgrading between Drupal versions.

xjm’s picture

Issue summary: View changes
Status: Active » Needs review
Issue tags: +rc target, +8.1.0 release notes
FileSize
489 bytes

The labels for views_ui, field_ui, menu_ui, etc. are all (e.g.) "Views UI" in the... UI. So I don't think we need to introduce a different pattern here. That would make the simple choice for the label "Migrate Drupal UI" since the modules are migrate_drupal and migrate_drupal_ui.

I definitely think #2513398: Conduct a full-scale terminology review of Drupal (Fix Drupal terminology so that it is more accessible to users) is important in the long-term. On the other hand, though, I think we should probably do this in 8.1.x ASAP for two reasons:

  • catch is right that the more we can distinguish "Migrate" as an operation for major versions (and anything else the user might migrate) from "update" as in update.php, the easier it will be for people to learn/understand the drastic conceptual difference between these things. "Upgrade" and "update" being different has always been confusing and arcane. Edit: To clarify, the UI is just for migrating Drupal as @mikeryan points out, but it's also valuable to emphasize that it is for migrating Drupal.
  • It's also just consistent with the machine name, which is easier.

Discussed with @alexpott and he agreed with making this an RC target for those reasons. The downside is that we also have to go through and do all the handbook updates again, as well as make sure our release communications get updated, but better to improve it now rather than having even more people confused if it gets changed in a few months.

alexpott’s picture

+1 for this in the RC. We've already changed the language in #2701027: Drupal 8 UPGRADE.txt is misleading in many ways (in its name to begin with)

Status: Needs review » Needs work

The last submitted patch, 9: migrate-2701541-9.patch, failed testing.

xjm’s picture

Category: Plan » Task
Status: Needs work » Needs review
FileSize
1.61 KB
1.14 KB
xjm’s picture

Hm should have grepped it in the first place. This should be all of them.

Gábor Hojtsy’s picture

@xjm: while the Views UI, Field UI, etc. are named like so, they are the primary UI for said features. As Mike points out above, the migration user interface will be a contributed module to build migrations from other systems. So then the differentiator between the core and contrib module would be 'Drupal Migrate UI' vs. 'Migrate UI', the later being the more general purpose module not to be used to upgrade between Drupal versions?

yoroy’s picture

Could it be done in such a way that the contrib solutions enhance, extend the core Migrate Drupal UI? I imagine the core module would have a start screen where different migrate scenarios could be added to, provided by whatever extra contrib you install. So instead of calling the contrib solutions something else entirely, present them as extensions of the existing core feature set. Instead of looking to differentiate contrib solutions from what's in core, it would mean focussing on making it all part of the same thing.

Else we may get into situation similar to blocks vs panels vs context vs beans territory, which I doubt is something we can afford to keep doing nor should be, given that we might add what's in contrib now to core for 8.6.

mikeryan’s picture

@yoroy: The problem with contrib solutions "extending" the core UI is that we're kind of backwards - normally one would have general functionality in core, that contrib would extend for specific use cases, but in this case the core UI serves a very narrow use case (narrower than the names being suggested for it), and very unlike most typical migration scenarios. There's really nothing in it useful to the general-purpose migration UI.

yoroy’s picture

FileSize
21.19 KB

So how about considering what's in core as "Migrate UI". Within Migrate UI, core only provides Drupal to Drupal migrate functionality. Looking at the experimental section on Extend page we now have:

- Drupal Upgrade UI
- Migrate
- Migrate Drupal

I assume Migrate is the API and (Migrate Drupal + Drupal Upgrade UI) together are the modules for Drupal to Drupal upgrades specifically.

A first consistency check then would suggest renaming Drupal Upgrade UI to Migrate Drupal UI.

Would a hypothetical Sitecore to Drupal migrate solution also come with its seperate API and UI modules? Migrate Sitecore and Migrate Sitecore UI?

This issue is purely about the naming of things, but I worry that from the naming decision we make here we might also set a pattern where we might get multiple places in the admin ui where you can find individual Migrate solutions. So I wonder if it would help reinfore the idea of placing all the possible migrate options all under the same "Migrate" link in admin somewhere, where Migrate UI provides both the "dashboard/container" for all migrate scenarios even if it only provides Drupal to Drupal functionality out of the box:

Maybe I'm conflating UI issues with API concerns where we are only talking about naming things. Hope I'm making sense regardless :-) I want to find out if it might help to call this core thing plain "Migrate UI".

catch’s picture

Hmm so the conflict with the contrib module is that the contrib module is a UI for configuring/creating migrations (which could potentially let you set up and run a sitecore migration), whereas the core module is just for running two very specific migrations. The core module is primarily a runner, the contrib module primarily a builder. However I don't think 'migration runner' and 'migration builder' cover this either.

xjm’s picture

@xjm: while the Views UI, Field UI, etc. are named like so, they are the primary UI for said features. As Mike points out above, the migration user interface will be a contributed module to build migrations from other systems. So then the differentiator between the core and contrib module would be 'Drupal Migrate UI' vs. 'Migrate UI', the later being the more general purpose module not to be used to upgrade between Drupal versions?

But it is currently called "Drupal Upgrade UI". Renaming it to "Migrate Drupal UI" does not make this problem any worse.

Maybe I'm conflating UI issues with API concerns where we are only talking about naming things. Hope I'm making sense regardless :-) I want to find out if it might help to call this core thing plain "Migrate UI".

I think it would not work in this case. Core does not currently provide a UI that is a general-purpose Migrate UI.

It does provide a UI for Migrating Drupal, that already has a machine name that is migrate_drupal_ui.

Personally, I think that the imperfect name "Migrate Drupal UI" is better than the confusing "Drupal Upgrade UI", because of the reasons catch has stated. We also have less than 24h to make this change before 8.1.0 ships. Can we agree that it is at least an incremental improvement?

Gábor Hojtsy’s picture

Status: Needs review » Reviewed & tested by the community

Let's do Migrate Drupal UI then and adjust the contrib name later on as appropriate.

webchick’s picture

Reviewed this with @effulgentsia. It seems like there's general alignment that Migrate Drupal UI is less confusing than Drupal Upgrade UI, so I'm inclined to commit the patch on those grounds, but I know mikeryan had concerns about the name still being too generic/over-reaching for what it actually does. I was curious if maybe we could clear up this discrepancy in the module description instead, and get the best of both worlds.

Reached out to mikeryan via email to get his 2 cents since he's not an IRC dude. :)

yoroy’s picture

Title: Rename Drupal Upgrade UI to Drupal Migrate UI » Rename Drupal Upgrade UI to Migrate Drupal UI
mikeryan’s picture

Sorry I missed the further discussion, I was off (and offline) for a few days...

I'll accede to the community wishes on this, especially given it's so late in the game now, but some further comments:

  1. I'm not convinced "upgrade" is a bad word for what this does. In my mind, the fact that the D8 site is a fresh environment is an implementation detail. To someone with a D6 or D7 site, what they are doing is upgrading to D8, and the fact that it doesn't happen within the original database doesn't change the fact that it's an upgrade. I still feel "Drupal Upgrade" is the clearest, most specific, and least confusing description of what that module does. xjm reminds me of the confusion between Upgrade and Update... I don't have an answer for that, I'm afraid, except that I don't see how "Migrate" makes it clear that this is a major version upgrade scenario. Would "Major Version Upgrade" or "Upgrade to Drupal 8" be bad?
  2. If we have a core module named "Migrate Drupal UI", what will a contrib module implementing a general-purpose Drupal migration UI be named? The D7 version of this was "Drupal-to-Drupal migration UI" - that would be different, but someone looking at a module list isn't going to understand the difference between "Migrate Drupal UI" and "Drupal-to-Drupal migration UI".
  3. One point that's been missed here - note that "Drupal-to-Drupal" in the D7 name. There's a reason for that - it's not immediately clear with a single "Drupal" in the name whether Drupal is the source or the destination of the migration. We're taking for granted that it obviously refers to the source.
  4. @yoroy: We didn't have complete consistency in the D7 space, but the pattern I eventually settled on for source-specific migration modules was a machine name of migrate_foo (and migrate_foo_ui if there was a separate UI module), with a rendered name of "Foo Migration".
  5. @catch: The contrib migration UI(s) will include both building and running functionality.

Anyway, I understand it's probably too late to back off now, just wanted to get my last two cents in...

xjm’s picture

So I think that part of the difficulty here is what the modules might do in the future versus what they do now. The UI is very much a first effort and we intend to improve it. Similarly for the migrate_drupal module, we intend to add D8 sources to it in the future. But none of that functionality is in core yet. Add into the mix contrib modules that don't exist yet, or that have their featureset changing as core supports more, and we have a lot of different expectations.

I think there are a few requirements for the name:

  • It must contain the word "Migrate". Understanding that data is being migrated from one source site to another destination site is an essential part of understanding how to make a D8 site from D6 or D7 data.
  • It should not contain the word "Upgrade". "Upgrade" is an operation that no longer exists in Drupal.
  • It should indicate that it is a UI-only module and not useful by itself.
  • It could further clarify exactly which types of migrations it supports.
  • It could change in future releases when the functionality of the core module suite is extended.

The patch in this issue meets the "must" and "should" requirements as I see them.

All of the committers (@catch, @alexpott, @webchick, @effulgetnsia, and myself) agreed that the problems with the name "Migrate Drupal UI" are at least lower impact than the problems with the name "Drupal Upgrade UI", and that the biggest risk with the name "Drupal Upgrade UI" is right now, when we are shipping both the first minor release and the first push for core migrations. So based on that, we agreed to go ahead with the rename in this issue despite @mikeryan's concerns. However, let's consider this patch a stopgap measure and be open to further improving the name (and other things related to how we communicate the various core modules' purposes) in future releases. Since the module is experimental, we have some flexibility to explore @yoroy's suggestions, etc.

yoroy’s picture

Go for it! :)

  • effulgentsia committed 74d408e on 8.2.x
    Issue #2701541 by xjm, yoroy, catch, mikeryan, Gábor Hojtsy: Rename...
xjm’s picture

  • effulgentsia committed 09c2962 on 8.1.x
    Issue #2701541 by xjm, yoroy, catch, mikeryan, Gábor Hojtsy: Rename...
effulgentsia’s picture

Status: Reviewed & tested by the community » Fixed

Thanks for all the perspectives. I pushed this to 8.2.x and 8.1.x. Even though mikeryan disagreed with this decision, he did contribute thoughtful commentary to the discussion so I credited him as well.

effulgentsia’s picture

Reticking credit boxes, since they didn't seem to take in #29.

Gábor Hojtsy’s picture

So @effulgentsia asked about the screenshot we are preparing for the 8.1.0 release announcement. And apparently he is right. It is still largely the upgrade UI, it is called the upgrade form, the path is /upgrade, the buttons/titles are upgrade.

I don't think this was intended, just wanted to note that the patch in itself did not really rename the thing being done from updating to migrating.

effulgentsia’s picture

Status: Fixed » Needs work

Setting to Needs work for #31. Even if that doesn't land before 8.1.0 being tagged, I don't think #29 needs to be reverted.

xjm’s picture

Status: Needs work » Fixed
Issue tags: +Needs followup

Drat. Good find. Let's keep the scope of this issue as it is, but also do a followup to check for any lingering instances of "upgrade"/"upgrading" (in Migrate and elsewhere).

xjm’s picture

xjm’s picture

Issue tags: +Needs followup

Actually I think there is another followup in here for "Improve naming, descriptions, and help text for the core Migrate module suite" or something as a related issue for the overall usability issue for the UI.

mikedotexe’s picture

Issue summary: View changes

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.