So far we have established the structure of the new migrate module, there is a migration configuration entity which holds the configuration of the various plugins: source, process, destination and id map. As Views does, migrate also will have a
MigrateExecutable class, responsible for "turning the gears" -- calling the proper plugins. There is a standalone, non-pluggable
Row class which mostly just holds the source and destination data and does very little logic. There is a process plugin written, called PropertyMap, this contains the code from
Migration::applyMappings -- we are really not interested in rewriting the logic in Migrate. We are very much interested however moving it around and doing some cleanup: for example row was a simply
stdClass now it is a proper class which makes debugging so much easier (you can set a breakpoint inside a getter).
I have written an in-memory implementation of the database
Select class so that we can unit test our source plugins without having a database. (We might want to use sqlite :memory: later perhaps.)
Most of the work beyond this, especially at BADcamp was focused on writing source plugins for Drupal 6 with unit tests. Huge thanks to marvil07, bdone, jessehs, mpgeek, BTMash and fastangel for burning through the queue. We all have learned a lot about how to code for PHPunit for sure!
Moshe and I have written the source for the variables table and the configuration destination. Interestingly, writing the unit test for an already simple class lead to further simplification.
Immediate next steps include moving enough code back into MigrateExecutable so that we can have a complete migration (very likely it will be a configuration migration); writing an integration test for it. Once this is done, I'll submit these parts for core inclusion.
Beyond that, we will ask the community to please convert the existing 51 calls of update_variables_to_config to a migration and write a full test for each. Currently our upgrade path tests, as far as I am aware do not test these. These will likely form one bigger core patch; however it'll be a very easy to review as new logic will not be added here.
Meanwhile, we need to get the Entity destination handler written, get the SQL id map plugin actually working and once those are done, we can add migrations for content and configuration entities. I will try to submit these one plugin and migration a time to make sure the patches are reviewable.