Global: Custom text fields in view not available for migration

OK, I'll have to look at it... But, off the top of my head, Migrate operates by pulling the db query for the view, altering it to join the map and message tables, then executing it. The custom text thing almost certainly is something Views applies after running the query, so this may take some work. With a little luck, maybe it's as simple as calling one Views function to invoke the right handler...

I've looked more closely, and while I haven't worked out exactly how to obtain such fields from Views, it's clear that implementing this would require quite a bit of work - the central processing loop in migrate_content_process() would need redesign. This isn't something I foresee taking on in the forseeable future, but if someone else can come up with a patch I'll add it.

What a pity.

Really - this would be very great - but I'm not able to write a patch.

Anyway - a wonderful module.

Just found this issue. I need this functionality, too. ;) I've got an old customer database with first and last names. I made a little custom text field in my view to glue them together into a single field I wanted to use for the Drupal username field, but alas, no go. I guess I'll just have to do the munging myself in hook_migrate_prepare_user()...

Also note that this applies to field rewriting.

Indeed this would be great, for all the stated reasons. I did the same thing as dww for the same issue... and then found my way here. Unfortunately, I don't think I can do anything about it.

subscribe

Patch here for 1.x-dev. This isn't a solution that a views developer would actually like, but works for me (partially). There are some problems with it and things that must be decide, like telling the view somehow not to rewrite <tag> to <tag>. I'm not sure if it's not an issue for the table wizard. Or migrating datetimes, which worked when importing directly from the query. The view is messing these dates.

I'm not sure if this is the right direction.
What do you think?

no feedback?

That patch kills the itemlimit support.

here is a fix

I've committed this patch - I hope people will give the dev build a try before we cut a new (final?) release of Migrate 1.

Thanks.

I think this is not finished yet.

The issue with bad dates solved here, but as i have mentioned here before, there is still a problem that views are encoding the content of fields with check_plain($value) when rendering strings by default (views_handler_field). I think we don't want to leave it like that.

I see two solutions for that:

1. Bruteforce apply decode_entities($field) function on rendered fields before pushing results to the database.
2. Or bundling the table wizard with a handler that will render the content without check_plain.

What do you think, which way to go?

Should've tested more thoroughly, I've reverted to the previous version of migrate.module.

The entity encoding thing is probably the tip of the iceberg, I wouldn't count on that being the only case where Views munges things.

and the answer on my question please? your opinion

Well, no - this probably isn't the only thing affected, hacking a work-around for it is not how I would go. I would go back to the drawing board and not run the results through Views rendering.

Another try for solving this using a different handler in Table wizard issue #770472.

I'm guessing this is the same problem here for views_customfield?

it aint pretty, but here's my work around - make your view, use your custom shiz and then use views_bonus to create a csv feed. and export that file - then import your csv file into your database as a custom table - use table wizard to analyze it and you should now have everything you need to successfully complete the import...

If someone understands what I am saying here and it works for them - and you can explain it more clearly than I am here please feel free to do so :)

@whoisrobertpope wow, I think you might be onto something here.. Is that really the best way? I hear tell of Data + Migrate, but nothing concrete.

To whom it may concern: I have created the most beautiful migration view with all my original table fields and a pair of customfield fields to handle perfect many:1 mapping of old-system Event Type IDs to Drupal taxonomy terms, but as is pointed out in this thread, Migrate won't hear of it. I will try the import -> massage -> export -> import suggested by whoisrobertpope as a next stab.

don't forget you may need to set a primary key in the DB in order to use your re-imported table in a view :)

@whoisrobertpope Just a follow-up.. Your backwoods workaround worked like a charm! I used Talend Open Studio to create the iterim import table so I wouldn't have to worry about column names and whatnot.

Migrate V1 is in bugfix-only mode, no new features will be added.