I'm starting to work on the UI for upgrades. We'll want to get an actual designer to review this at some point, but for now let's get a POC that lets us test the migration implementations in context, and also so we can start demoing to the outside world what this is capable of.

The workflow I envision is:

  1. At http://example.com/upgrade, we have the same database credential form as the install process. For now I've copied-and-pasted the code, hopefully with #2112569: [meta] Convert non-controller forms to FormInterface there will be a form class we can reuse.
  2. Upon successful entry of valid credentials for a source database, we determine what Drupal version the source is and present a confirmation form showing the actual configuration and content to be migrated from that site. There should be some sanity-checking here - e.g., ideally if the forum module is enabled in the legacy site but not the target site, ask whether they want to have forum enabled or skip the forum content.
  3. Submitting the confirmation form runs the migration in batch UI.

It'd be nice to have #1886616: Multistep Form Wizard in core...

CommentFileSizeAuthor
#48 imp-upgrade_ui-2200379-48.patch33.22 KBmikeryan
#48 ui_poc-9.jpg154.23 KBmikeryan
#48 ui_poc-8.jpg182.57 KBmikeryan
#48 ui_poc-7.jpg148.23 KBmikeryan
#48 ui_poc-6.jpg81.02 KBmikeryan
#48 ui_poc-5.jpg177.54 KBmikeryan
#48 ui_poc-4.jpg119.45 KBmikeryan
#48 ui_poc-3.jpg84.96 KBmikeryan
#48 ui_poc-2.jpg105.99 KBmikeryan
#48 ui_poc-1.jpg153.14 KBmikeryan
#45 interdiff-2200379-38-44.txt3.61 KBultimike
#44 imp-2200379-upgrade-ui-44.patch19.71 KBultimike
#38 imp-2200379-upgrade-ui-38.patch19.28 KBmikeryan
#37 ui_07.png173.08 KBmikeryan
#37 ui_06.png95.2 KBmikeryan
#37 ui_05.png90.83 KBmikeryan
#37 ui_04.png111.25 KBmikeryan
#37 ui_03.png68.77 KBmikeryan
#37 ui_02.png96.26 KBmikeryan
#37 ui_01.png158.06 KBmikeryan
#37 ui_00.png91.36 KBmikeryan
#34 imp-2200379-upgrade-ui-34.patch19.81 KBmikeryan
#28 imp-2200379-upgrade-ui-28.patch13.38 KBmikeryan
#27 imp-2200379-upgrade-ui-27.patch4.88 KBmikeryan
#26 imp-2200379-upgrade-ui-26.patch17.64 KBDavid Hernández
#25 imp-2200379-upgrade-ui-25.patch17.64 KBbdone
#22 2200379-upgrade-ui-16.patch19.26 KBbdone
#16 Upgrade_Step5.jpg20.06 KBmikeryan
#16 Upgrade_Step4.jpg17.34 KBmikeryan
#16 Upgrade_Step3.jpg19.58 KBmikeryan
#16 Upgrade_Step2.jpg16.86 KBmikeryan
#16 Upgrade_Step1.jpg54.56 KBmikeryan
#15 2200379-upgrade-ui-15.patch18.91 KBmikeryan
#12 Screen Shot 2014-02-24 at 00.00.43.png111.04 KBBojhan
#12 Screen Shot 2014-02-24 at 00.01.59.png89.67 KBBojhan
#6 Upgrade_Drupal___Mike_Ryan.jpg57.3 KBmikeryan
#2 2200379-upgrade-ui-2.patch11.37 KBmikeryan
#1 2200379-upgrade-ui.patch8.46 KBmikeryan
Members fund testing for the Drupal project. Drupal Association Learn more

Comments

mikeryan’s picture

Status: Active » Needs work
FileSize
8.46 KB

What I've got so far...

mikeryan’s picture

FileSize
11.37 KB

Some refinements - it now does requirements checking and does not present migrations which fail, and it writes the database connection to settings.php.

chx’s picture

What do we present to the end users needs discussion -- maybe groups, maybe manifests -- but one thing I know -- the individual migrations would be insanely confusing to end users.

mikeryan’s picture

Here's a thought, dovetailing also with some of our dependency/requirements discussion... Add an optional module key to both the source and destination. checkRequirements() would take that as requiring the named module to be enabled, and the UI would present the list of distinct modules whose data is being migrated.

The requirements side should be a separate issue...

mikeryan’s picture

Thinking about how we would implement separate Import Configuration and Import Content buttons, a fundamental sticking point is, how will the UI know which migrations are considered "configuration" and which are "content"? A first guess would be keying off a destination plugin of "config", but of course some configuration is in entities. So, should we have an explicit flag in the migration config? Any other thoughts?

mikeryan’s picture

Here's a screenshot of where I am so far on the confirmation page - listing modules rather than each individual migration, with a note where there's a module that needs to be enabled.

Bojhan’s picture

Issue tags: +Usability

Could you ping me on IRC to discuss this? I have time to provide feedback this sunday.

chx’s picture

As for the core UI, my plan was to write a configuration.yml being a simple list of configuration migrations and a content.yml being a simple list of content migrations (and then lie -- block will go in the latter). Do not try to generalize this. The per module thing is perhaps a good thing for contrib -- it is not for core. I *really* would like to get the Drupal 6->8 path working and shipping.

eliza411’s picture

It's still my understanding that the core Migrate UX will be:

  1. Visit the Migrate UI -
    The specific location hasn't actually been discussed, as far as I know - there's an issue to move it to that location and actually add it into the interface [#https://drupal.org/node/2203071]
  2. Enter the data for the site to be migrated -
    either the database URL (or maybe, I guess, the database name, user name, and password) for the Source site - I am unclear if these settings can/should be saved or not
  3. Present one button to "Migrate configuration" and another to "Migrate content" with appropriate help text. I think people generally are expected to migrate configuration first, then content, but I'm not sure that's so or what cues need to be provided so they are sure what to do
  4. Confirmation screen -
    Show the user what will be migrated and let them know if there's a module that could be migrated to D8 but will not be because the D8 module hasn't been enabled. - Mike attached a rough screenshot of the idea
  5. Provide feedback to the user while the migration is happening
  6. Provide appropriate success and failure summary at the end

I'm not sure totally the what the admonition to "not try to generalize this" is referring to - if there's something in the plan I just described (which I think is the same as what Mike has outlined) that doesn't belong, then we should definitely talk about it!

Regarding the "per module thing" - If the per-module-thing is referring to telling users in a way that they can understand what is about to be done to their site, and the suggestion is that we not do that, I have some concerns.

If that refers to allowing users to choose what is migrated, that was clearly and definitely ruled out of scope for core by the Migrate team on the last call, I thought.

We should figure out when and how to work on the Contrib UI. There's a lot of enthusiasm to start thinking about it, and I don't want to lose that! I also don't want to derail the actual migration process by interrupting focus. A great UX requires that the plumbing works as advertized :)

chx’s picture

> If that refers to allowing users to choose what is migrated, that was clearly and definitely ruled out of scope for core by the Migrate team on the last call, I thought.

And that's what I wanted to rule out. Any selection beyond the two manfiests I described is out of scope. This was decided before a single line of code was written or even before the whole thing was announced. Bojhan can overrule this if he thinks strongly about needing a finer selection.

mikeryan’s picture

Yes, agreed that the core upgrade path is at most a 3-click operation - submit the source credentials (using the same database form as the core install), import the configuration, import the content.

Frankly, I'm less interested in this than in the full contrib UI - my primary concern at this point is that the core infrastructure provides all the information and capability necessary to cleanly support the full UI in contrib, even if not all of it will be used in the core upgrade path. So, I'm trying to get going with that sooner rather than later to find the gaps - I actually began attempting it on Friday afternoon and was immediately blocked by #2202475: Registering/instantiating migrations.

Bojhan, I'm on IRC for the next few hours if you want to chat, as well as regular EST working hours (at least) tomorrow.

chx: As for identifying configuration vs. content with hard-code manifests - what about contrib modules? They will be providing config files for their own configuration and content, how will the core upgrade know which is which? I think we need to indicate that in the migration config files - something like type: configuration vs. type: content.

Bojhan’s picture

Ok, I think these are the first two relatively obvious screens. I wasn't sure whether we could force the source site into maintenance mode, and/or if there would be more advanced settings.

I think its best to present this in a flow, if you wish to skip content migration you can, same for configuration migration. But we shouldn't offer a jump board to pick one out of the two, as that requires a "listing" of some sorts.

We debated on IRC for a while, what we can and can't present in regards to what has been successfully migrated. To my understanding, its hard to say if a module its data has been migrated because often it is migrated to several different places and occasionally some data isn't migrated at all. Frankly, I prefer to either give good feedback or no feedback. Providing half-feedback, is a very dangerous path. I'd like to better understand the situation before making a call around this. Although from a UX standpoint, you ideally want to provide point-to-point feedback as to what happened to the data - I doubt this is realistic in the forthcoming months to achieve.

I think if we can give a message at the end saying "Successfully carried out 231 migration processes" see "log" for further details. That would be a good initial step, the more advanced step would be to provide a per "module" or per "data-set" type feedback on the migration. I wonder if its up to core or contrib to provide that, given that you really want to include contrib if you do that.

eliza411’s picture

I mentioned the feedback primarily because right now, I encounter situations where data is successfully migrated yet I see "New object was not saved, no error provided" in the Green success format. I figured we should talk about what's supposed to happen.

I have no desire to complicate things, but it seems best to determine what valuable feedback can be given, see how difficult it is, and then decide. I think iterative work starting with the minimal effort is a good approach here. It seems like we should do the best work we can with the least complexity, then deeply consider the rest of the UI as part of the Migrate Extras.

It doesn't hurt to identify what we'd like in core, what we can achieve, and a plan to move new functionality into core if/when desired.

Perhaps for now the feedback could looks something like:

{n} migrations processed. (and, sure, a list of them if it's easy and helpful)
{n} errors.  See <a href="/admin/reports/dblog">Recent Log Messages</a> for more detail.

Error messages aren't currently being logged to the dblog. I figured that was just in the category of "work to be done."

I like avoiding variations on the word Success and avoiding a "No errors" statement because success and errors are ambiguous in this context.

chx’s picture

> Error messages aren't currently being logged to the dblog. I figured that was just in the category of "work to be done."

Now they are.

mikeryan’s picture

FileSize
18.91 KB

New patch. This is the bare minimum UI - single button configuration and content migrations. Unfortunately the content migration dies, but config looks pretty good. Screenshots to follow.

mikeryan’s picture

mikeryan’s picture

Bojhan’s picture

@mike could you show full screens? It looks like we don't depart from the usual flow (i.e. it not being in the wizard design). How does the finished page look like?

mikeryan’s picture

The full screens will just add menus and whitespace, but I can do that with my next iteration.

There is no finished page - for one thing, at the moment it crashes before finishing;). I'm not sure what the finished page should look like - certainly not a list of migrations. Just a "Congratulations, you've imported your Drupal 6 site, go to admin/content to review!"?

We need to think about restartability and "continuous migration" (i.e., doing an initial migration and a delta later). I'm thinking that:

1. While we're hardcoding the "migrate" connection, if it already exists skip the credentials screen and go (maybe) to the configuration button screen. But, this would preclude ever changing the credentials (without editing settings.php) or importing a second site (well, the latter isn't a use case we're looking to support in core anyway...).
2. If we've already run the configuration import, skip that and go straight to the content button screen.
3. If we've already run a content import, on the content button screen indicate that rerunning the content migration will import any new or changed content from the legacy site.

Thoughts?

Bojhan’s picture

How is a continuous migration applicable here? Isn't that for contrib to solve?

1. I think its reasonable to assume, if you filled out settings.php that this is the settings you wish to go with. Offering the ability to edit them, sounds like a edge case.

2. Does this take into account changes to configuration? If not, I would still just offer skip functionality.

3. I think overall both the configuration and content screen could go with a little information before running it.

I still this should be outside of the normal interface, and actually go into the same interface we use for maintenance. I'd like this to be part of the patches.

mikeryan’s picture

Sorry, afraid I haven't had a chance to make much progress here, and I'm off for the next two weeks. If anyone wants to continue the work on this patch they're welcome.

A hui hou kakou!

bdone’s picture

FileSize
19.26 KB

haven't had much time to look at this, but this needed a re-roll, so i'm attaching that.

bdone’s picture

Assigned: mikeryan » bdone

i'm attempting one of the @todos to establish "configuration" vs. "content" in migration configs...

bdone’s picture

added a related issue, #2219129: Identify content vs. configuration for the "content" vs. "configuration".

bdone’s picture

Assigned: bdone » Unassigned
FileSize
17.64 KB

this removes the static arrays and builds off of #2219129-1: Identify content vs. configuration, assuming that patch is applied and configuration/content exists in destination as a new type property. after talking with @chx in irc, it sounds like a static manifest is preferred. so, this attempt may have just been nothing more than learning exercise.

David Hernández’s picture

Quick reroll to replace deprecated drupal_set_title

mikeryan’s picture

Quick reroll to make migrate_drupal.module apply, and add menu_name admin to hook_menu_link_defaults (which makes drush cr happier). Doesn't actually import anything at the moment - @bdone, what's the status in terms of manifests?

mikeryan’s picture

Here's a new patch that mostly works (in the sense of running all the way through). There are a couple of separate fixes to make for it to actually run, I'll add those separately (dealing with missing profile_values table, and url_alias migration just plain broke). #2201699: Theme migration is still an issue - running the configuration step unthemes the site. Using my personal site, the configuration does appear to migrate successfully, nothing blatantly wrong there (other than creating a second Tags vocabulary). As for the content migration - the tags are migrated, but no users or nodes yet.

Note we're at the 30% stage here - looking for feedback on the broadest aspects of the UI. Like, where should it go at the end - certainly not back to the upgrade page as it is now, but maybe to admin/content? admin/config/system? Front page?

Bojhan’s picture

Assigned: Unassigned » Bojhan

I will look into this.

mikeryan’s picture

Just as an FYI, I didn't really do much UI-wise here, this round was mostly about making it work functionally using the manifests added to migrate_drupal.

@Bojhan: Going back to this comment:

I still this should be outside of the normal interface, and actually go into the same interface we use for maintenance. I'd like this to be part of the patches.

You're saying that the upgrade pages (which are under /admin/config/system) should be unthemed, correct? I'll need to research how to do that...

mikeryan’s picture

@Bojhan: It doesn't seem possible with the current D8 API to have the upgrade form be a normal page at admin/config/system and give it maintenance theming with no toolbar. I'm thinking it probably should follow the pattern of update.php - the address would be upgrade.php, and it would be a standalone file outside of normal routing. I'll start working on that and see how it goes - I'll post the latest stable version of what I've got at the moment for safekeeping in case that avenue doesn't work out.

mikeryan’s picture

mikeryan’s picture

mikeryan’s picture

Checkpoint of the UI work. Added fields to support file migration on the initial form (although they're not yet used), and better feedback on what's happening. Content migration dies though, not sure why.

Bojhan’s picture

Assigned: Bojhan » Unassigned

@mike It might be good to get some feedback on that. I wasn't able to review this fully because the UI is really still very much in the works. Just ping me when you moved it a step further :)

mikeryan’s picture

Sometimes it's good to sleep on things;) - I did start making an "upgrade.php" version of "update.php", but I woke up this morning and immediately realized that's dumb. The reason update.php is a special snowflake is that it can't count on pretty much any module but system being functional pre-update, so it needs to run without loading any (other) modules. Migration, on the other hand, is running in a fully-functional environment, and indeed needs all modules active to be able to save data. So, it should run in a normal page context - I'm going back to that approach.

I'm postponing attempts to use the maintenance theme and remove the toolbar until #2218039: Render the maintenance/install page like any other HTML page lands - it's generalizing stuff around the maintenance theme for installation and updating, it probably won't give us a direct solution but it should take a step in that direction and be a better basis for offering a patch enabling us to do what we need here. I'll focus for now on what happens within the form area of the page.

mikeryan’s picture

FileSize
91.36 KB
158.06 KB
96.26 KB
68.77 KB
111.25 KB
90.83 KB
95.2 KB
173.08 KB

OK, looking step-by-step at the current state of the UI POC, keeping in mind we're at the 30% stage. Let's work out the high-level workflow, and what specific information we should (and shouldn't) present, then we can deal with details of layout etc. Note: it would be GREAT if interested parties could have a little brainstorming session at NYC Camp to discuss ideas around the UI, it would be something non-developers could (and should) get involved with - if this happens let me know and I'll see if I can join remotely.

First off, to what extent is this functionality to be presented as a one-time major version upgrade, versus a more general import from Drupal 6 or Drupal 7? In the former case, I don't think it should be a permanent part of the admin configuration UI, but perhaps at a /upgrade URI one needs to manually invoke (as they do with /update.php). In the latter case, then this should probably be renamed back to Migration (see bojhan's original screenshot).

The central piece here is a clone of install.php's database selector, for getting the pointer to the source database. The text fields at the top are new to this iteration of the UI - the database alone doesn't tell us how to find the files. Given the domain of the source site, we can find and scrape them (in theory - this is not yet implemented).

Private files, of course, we can't - those will have to be manually copied to a suitable place before beginning the migration process, and a separate pointer provided for those. Private files are relatively rare, though - maybe we could wait until the next screen (after opening and poking around the source database) and only prompt for them if they were configured in the source site.

So, what more (if anything) should we say here?

Progress!


...

So, here's where we need some thought on what information needs to be provided on what was just done. At the moment we've got a line for each D6 config file fed through the process - probably too much detail, but I'm not sure how we would consolidate it. Also note the message "Migration d6_contact_category did not meet the requirements". This is generated when a call to checkRequirements() fails, but we have no idea what the actual failing requirement was - we need a way to bubble that up. In this (and the other cases on this page), the issue is that the corresponding Drupal 6 module is not enabled, thus there is no data to migrate - so ideally we don't want to say anything. To do that we would need to bubble up the distinction between an OK "failure" like this, and a true failure which would require attention. Or, we could try to preprocess, run checkRequirements on each migration and silently skip any that fail...

Another thing that would be nice would be to report counts where relevant (more important for content below) - this wouldn't make sense for a lot of low-level of configuration, but the numbers of menus, vocabularies, node types etc. imported would provide a bit of a sanity check.

Should we encourage the administrator to review the imported configuration here before proceeding ("please visit admin/structure/types"...)?

Apart from the reports from the configuration step, anything else we want to say about the upcoming content step here?


...

File migration is not fully implemented (specifically, the part where we figure out where to migrate them from), hence the errors for now.

As with configuration, we need to figure out the right feedback to give here on what just happened.

We're landing on admin/config/system at the moment - is there a better landing page, like admin/content? Or (probably) should we stay on admin/config/system/upgrade for this page?

We should probably have links to typical places you'll want to go to review the migration results - admin/content, admin/structure/types, admin/people...

mikeryan’s picture

FileSize
19.28 KB

New patch for anyone who wants to try it out - you can also pull the ui_poc feature branch.

Bojhan’s picture

I would land on admin/config not admin/config/system. But it might make more sense to have a "complete" page here. Also I thought we where going to log all that instead of showing it all in a message?

mikeryan’s picture

OK, let's talk about logging - what goes in the log? Do we just save a list of messages like those being displayed here, and dump them on a log page linked from the result pages? Maybe we can just use watchdog if that's the case?

Anonymous’s picture

This is awesome. I did a fresh install with the patch in #38 and was able to bind to my D6 database and get through the config migrations.

I noticed that I had aggregator settings in my d6 instance but they were marked as requirements not met. That was because in D8 the module was not active. In D7 I enabled modules like this at registration time. Not sure if there is a plan to do this, but it would sure be nice.

The content migrations did not run, which is probably known issue. I *was* able to get them running after the fact by running those on the command line though, so using both methods I now have a site that is quite far along now, with much less configuring than I was expecting.

Overall I like the interface - very direct and to the point. Prompting for file paths at the top is a really good idea. I hope that if we're using HTTP to pull the files that if we get an error we note the reason why it failed. HTTP code would be ideal (I rambled on a bit about this for D7: #2175359: Files migrations silently fail / migrate should use custom error handler rather than hide errors).

Bojhan’s picture

@mike Well I guess it needs to be more intelligent. I think we can generally log all the specifics (migrated module X) to the log. We just need to say migrate successful or not successful (perhaps this is a rate of fails). I am bit puzzled why there are fails in between succes messages.

ultimike’s picture

Mike,

Wow - looks fantastic so far. Here are my thoughts on my first pass through it with a (very simple and small) real-world D6 database:

  1. For some reason, I'm not crazy about the location of the main entry point on admin/config/system. I like the idea of upgrade.php (similar to update.php), but there still needs to be an entry point to the process from the UI somewhere. Having it anywhere in "Configuration" gives it the appearance that it is something that needs to hang around after it it run (rather than a one-time thing). Maybe an entry point could be on the final page of the Drupal installer? If there's a persistent entry point from the UI, perhaps there should be a warning if the site has any content or configuration already defined (what happens if a migration is run and configuration/content already exists?) Granted, some of this is too far in the weeds for now, but something to think about.
  2. Other than the need for some additional help text, I like "Upgrade step 1" and the fields present. The "Private files directory" field doesn't bother me here, I'm not sure it is worth the extra work (at this time, at least) to move it to a later, post-sniff, step. One idea to organize this step a little more would be to break it up into 2 sections: database and files. I think that most Drupal site builders are more than familiar with the fact that their content is in one of these two places, so it would provide a bit of context to the process ("tell us where your DB and files are..."). Help text that can (should?) be added includes a brief overview of the process. My first question when seeing the page was "should the source site address be the production site or a local/dev/test site?"
  3. Upgrade step 2 - I'd love to see a summary of the configuration to be migrated on this step. Perhaps just a list of content types and other "major" things, but I realize many sites differ on their definition of "major things". Maybe a series of collapsed fieldsets with legend text hinting at what is inside ("Content types (6)", "Views (13)", etc...)? I'm not sure if this step is pre- or post-database-sniff (I'm guessing post- because it knew my source database was Drupal 6), but this also might be a great time to warn the user about disabled or missing module dependencies here (how many times am I going to forget to enable the "Link" module before starting a migration)? Regarding the configuration migration feedback messages, again, maybe a summary ("27 configuration migrations completed, 6 migrations did not meet requirements, 3 PHP notices, etc...") along with all the details in a collapsed fieldset? I also think a "rollback" button would be great here (as long as I'm blue-sky-ing), so that users can act on some of the messages (time to enable the Link module...) and then try again.
  4. Finally, I like all the feedback from the content migration as well, but I think maybe a summary/hidden-details method is the way to go. Sending the user to the dblog for details is fine, but if nothing went wrong, I think users are still going to want to see what the migration did. Dumping the user back on the admin/config/system page doesn't seem like the best solution, but that brings us full circle to the idea of upgrade.php...

-mike

ultimike’s picture

I've attached a patch (and an interdiff) that starts reorganizing the "Upgrade: step 1" fields into "Database" and "Files" (see point 2 in my comment 43 above).

Thanks,
-mike

ultimike’s picture

FileSize
3.61 KB
mikeryan’s picture

I merged @ultimike's changes into the ui_poc branch, thanks.

It's going to be difficult to keep track of particular elements of the UI we're discussing here, I am creating more focused subissues.

Let's set a threshold for committing the basic UI to the sandbox, then we can more easily refine specific elements of it in their own issues - let's say, when the content migrations actually basically work.

mikeryan’s picture

mikeryan’s picture

Assigned: Unassigned » mikeryan
Status: Needs work » Needs review
FileSize
153.14 KB
105.99 KB
84.96 KB
119.45 KB
177.54 KB
81.02 KB
148.23 KB
182.57 KB
154.23 KB
33.22 KB

Friday I reached a major milestone - I completed a full migration of my Drupal 6 site to my Drupal 8 development environment using the work in this issue. Of course, there are plenty of details left to work out, but right now the attached patch (with the addition of the branch at #2244555: Use copy() directly instead of file_unmanaged_copy() for the file migration to work) does support a basic D6->D8 migration through the UI.

Assuming we're agreed on the general shape of this UI, I'd like to see this committed to the sandbox soon - it will be much easier to work on refining individual details of the upgrade process working against the main branch rather than keep growing this big patch.

Looking at the screens step by step:

Note that private files aren't supported yet, let's do that as a followup issue once the main UI is committed.

[ui_poc-2.jpg and ui_poc-3.jpg aren't embedded here - they haven't really changed since last time, but they're attached if you really want to look]


Summary info, and a link to the log of operations performed.


The operation log for the configuration imports, stored in dblog. Let's discuss how to improve this in #2242611: Communicating migration results.

[ui_poc-6.jpg attached but not embedded - no change in how the batch API looks]


Like the install process, we land at the home page. We see migrated content present...


... and a little farther down the home page, we see a migrated node with an embedded image.

The operation log, after the content imports.

awasson’s picture

@mikeryan: What patches have you been using for your process? I've been following this thread for a while using copies of IMP from chx's sandbox (https://drupal.org/sandbox/chx/2105305) on a super clean Ubuntu 12.04 VM. My hope is to document the process so that we (Drupal devs) can move D6 into D8 somewhat smoothly. I think I'm missing some pieces of the process here.

Thanks, this is pretty exciting stuff!

mikeryan’s picture

For this morning's run I used the ui_poc branch plus the patch at #2244555: Use copy() directly instead of file_unmanaged_copy() (the latter just makes the file migration work, shouldn't affect the presence of the UI). The patch is the diff between 8.x and ui_poc, so applying that patch shouldn't make a difference. But, let me try it in a fresh environment...

awasson’s picture

Ok, so the ui_poc branch is at chx's sandbox, right? ie: I can clone it to my server with: git clone --branch 8.x http://git.drupal.org/sandbox/chx/2105305.git imp

If not, that could explain where I'm falling off track.

mikeryan’s picture

These are the steps I followed to build a fresh test environment to test the UI, it ended up going as smoothly as it had this morning for me.

git clone --branch 8.x http://git.drupal.org/sandbox/chx/2105305.git imp2
cd imp2
git apply -v ~/imp-upgrade_ui-2200379-48.patch
git apply -v ~/tmp/imp-use-copy-2244555-1.patch
ln -s default sites/imp2.local
# Add imp2.local to /etc/hosts, Apache vhosts
drush si --account-name=admin --account-pass=admin --db-url=mysql://user:pass@127.0.0.1:33067/imp2 -y
drush en -y migrate,migrate_drupal
# Login at http://imp2.local:8083/user
# Go to http://imp2.local:8083/upgrade

Now, that's migrating from my legacy D6 site - your mileage of course will vary according to what you have on your site. In particular, I see an error involving custom blocks in your comment - I don't have any custom blocks, so I wouldn't see any such errors. This almost certainly would have nothing to do with the UI - you might test this specifically at #2221815: Manual Testing (D6->D8): Custom Blocks and report any problems as a child issue to that one.

awasson’s picture

Thanks,
That does clear things up a bit. I was looking for the UI at: /admin/config/system/upgrade rather than: /upgrade

ultimike’s picture

@awasson - the error you reported in comment 53 is a known issue (https://drupal.org/node/2214229).

For future tests, please search to see if the issue has been reported previously or open up a new issue.

Thanks,
-mike

awasson’s picture

@ultimike: Great. Thanks for the heads up and yes, it's not my intention to junk this discussion up with irrelevant info. I'm just trying to test migrations and document it.

awasson’s picture

@mikeryan: Further to @ultimike's comments, would you like another issue created to discuss migration experience using the UI enhancements or is that even of interest. For what it's worth, once I deleted blocks from the source, migrations ran smoothly so I think as far as workflow goes, this is really working well.

mikeryan’s picture

@awasson: A general thumbs-up is definitely good here! If you have any specific feedback relative to #2242605: Context for the upgrade form or #2242611: Communicating migration results, please add it to those issues. Apart from that, any problems you find that don't already have open issues in the queue, please open a new issue.

Thanks for running through this! It's always good to here something works outside one's own box...

mikeryan’s picture

Status: Needs review » Fixed

OK, the last patch is committed to 8.x. Any specific problems that are found, or suggestions on changes to the workflow, should now be distinct issues.

Status: Fixed » Closed (fixed)

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