Detailed directions for getting set up are at https://groups.drupal.org/node/387488

Step 1: Review the detailed directions: https://groups.drupal.org/node/387488

Step 2: Choose an unassigned, active (white) issue from the list below and assign it to yourself when you start writing code.

Step 3: Write the migration. Please, if you get stuck or think you won't have time to continue working for a while, don't be shy about posting partial work. If you're stuck, explain where you got hung up. It helps us improve documentation and helps others pick up where you left off!

Step 4: Write integration tests for the migration. These will be Simpletests, not PHPUnit tests. This is test-driven development, so you're writing the test and the code, even though the migration cannot actually be run yet.

Step 5: When you're done, set the issue to needs review.

Many migrations will require migration-specific plugins. These require deep and specific knowledge of Drupal. You should feel free to move on to the next issue and leave those plugins to others. If you want to take a shot at them, moshe and chx will be your resources.

Issues

#2150407: Migrate D6 roles and permissions
#2150541: Migrate D6 node types
#2155615: Migrate D6 aggregator feeds Assigned to: penyaskito
#2155619: Migrate D6 contact categories
#2155801: Migrate D6 field formatter settings
#2158733: Migrate Drupal 6 field settings
#2165345: Migrate D6 field widget settings
#2166875: Migrate D6 languages Assigned to: penyaskito
#2166691: Migrate D6 menus
#2167391: Migrate D6 Vocabulary to Field
#2167709: Migrate D6 date formats Assigned to: penyaskito

Comments

chx’s picture

eliza411’s picture

Issue summary: View changes
eliza411’s picture

Issue summary: View changes
eliza411’s picture

Issue summary: View changes
eliza411’s picture

Issue summary: View changes
eliza411’s picture

Issue summary: View changes
benjy’s picture

Issue summary: View changes
penyaskito’s picture

Issue summary: View changes
jbloomfield’s picture

Issue summary: View changes
jbloomfield’s picture

Issue summary: View changes
penyaskito’s picture

Issue summary: View changes

Added date formats.

klonos’s picture

What about triggers/actions?

hint: #1413214: Provide upgrade path from Trigger to Rules

benjy’s picture

Personally, I think that should be handled by Rules.

klonos’s picture

Sure, but how would that work? Do we:

- ask D6/D7 users that used triggers.module to upgrade their site to D8
- keep their trigger.module data intact in the db or convert them to config (??)
- ask them to install contrib Rules 8.x if they want their D6/D7 site's functionality back.
- Rules 8.x picks up that old site data and takes care of the rest (??)

Do I get this right?

benjy’s picture

I believe the workflow is going to be to install a fresh Drupal 8 installation and migrate your content across from the old D6/7 instance.

So, if you wanted to migrate trigger data into rules you would need to have rules installed on the new D8 instance which would provide the migration.

klonos’s picture

Thanx Ben for taking the time to reply.

Ok, got it. I think I've seen this someplace mentioned before. So, one would setup a fresh D8 and point to the location of the old site and everything would get imported. That sounds reasonable, but I'm wondering what would give users the hint that they need to have Rules 8.x contrib installed before they start the migration/import? Will the fresh D8 installation detect the presence of trigger.module related data in the old site's db and give a warning a la "/sites/default/settings.php missing/not writable"? I hope I make sense.

naheemsays’s picture

I would suspect that there will be a need for a comparable module for every module used by the Drupal 6 install and each module will have its own migration path.

I understand that all migrations will not need to be "complete" or done in one go either, so you can redo the actions/trigger rules bits instead of importing or import them at a later point.

As with any other migration, I suspect there will need to be a fwe test "throwaway" migrations where the best method for an individual site is tested (best practices have changed over the years along with preferred modules, so such experimentation is probably necessary).

klonos’s picture

Yep, my point was simply that since most of the modules that were removed from core were actually moved to a respective contrib project/namespace we should at the very least provide hint messages (not blocking installation though) during migration that people should install the respective contrib module if they wish to maintain old functionality. These hints need not be thrown for every removed module - only limited to those removed that were in fact installed (status=1 in the [system] table) and had actual data in the old site's db.

benjy’s picture

Status: Active » Fixed

Development of the D6 to D8 migrations was completed in the sandbox and the patch will be posted here #2121299: Migrate in Core: Drupal 6 to Drupal 8

Status: Fixed » Closed (fixed)

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