Posted by febbraro on March 23, 2009 at 4:55pm
| Project: | Migrate |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | mikeryan |
| Status: | closed (fixed) |
Issue Summary
Hey, just putting this out there as I have some situations that need to import external data into taxonomy.
Dont know if I will have time to make it happen, but if I do, any pointers more than look at migrate_destinations.inc and copy?
Comments
#1
For a singleton vocabulary (one term per node), this can be done directly through the content mappings. If you potentially have multiple terms in a given vocabulary for a single node, you need to implement hook_migrate_destination_prepare_node(&$node, $tblinfo, $row). Don't have time to throw together a detailed explanation, but basically:
$node is the node object, which has been filled in with the direct mappings. You can add terms to $node->taxonomy
$tblinfo is info on the content set. You probably don't need it, but there it is...
$row is the raw input data.
#2
Thanks Mike. I have what you suggested working for applying terms to nodes, I was actually talking about importing content from external tables as terms of a vocabulary having nothing to do with nodes.
#3
Are you looking for taxonomy_xml?
http://drupal.org/project/taxonomy_xml
(It also does CSV and RDF)
#4
@dman, Yes, I guess that could work too. Thanks for the pointer.
I figured since I was importing the rest of my data with tw/migrate that it would just be another destination and a chance to hook in an change things if needed. Allows me to keep all of my migration in one place and it is like the documentation for what the import it.
#5
Yes, in terms of creating terms themselves, you can create a new destination type for that along the lines of nodes/users/comments, using migrate_destinations.inc for help. As a matter of fact, it seems like a common enough need that it makes sense for it to be part of the migrate module itself - if you do develop this, please feel free to submit a patch.
Thanks.
#6
Regarding #2 by febbraro. Were you able to import multiple terms for one node? I have been successful in importing one term to a node, but not multiple terms. I have tried to format the terms using either a comma or vertical bar as a delimiter, but it is still trying to process them as one term - not multiple terms. Thanks for any help.
#7
@fnikola I was lucky in that I was only importing one term into a vocabulary for a node. With all of the hooks built in though you should be able to do anything you want once you get your code on the node being imported.
#8
Has anyone started work on this yet? It's something that would be useful for a migration that I'm doing, and I'd love to attempt to contribute something useful to this module.
It would be great to have some input on what the requirements for this feature would be. My initial thoughts:
#9
Here's a half-working patch. Perhaps someone can help me figure out why it's not working properly. I've not run it through coder yet - I'll tidy everything up when it's working.
Currently I've not addressed hierarchical taxonomies - I will deal with that if I can get the basic patch working.
This patch successfully imports taxonomies, but doesn't save the source/destination ids properly in the mapping table.
The taxonomy_migrate_destination_import_taxonomy() function in taxonomy.inc is passing the correct table name, source id and destination id to migrate_add_mapping() in migrate.module.
The only thing that I suspect may be going wrong is that drupal_write_record() may be treating sourceid and destid as serials from drupal_get_schema(), and therefore unsets their values (line 3380 of common.inc).
However, after an hour of debugging I'm thoroughly confused, so I'm going to try a clean install of Drupal for this (I've been upgrading different dev releases for a a month or two).
If anyone can review the patch and suggest what I've done wrong, that would be a huge help.
#10
tom_o_t's patch actually works perfectly. I imagine the only reason that the map and msgs tables weren't being updated was because it appears that after creating a new content set, you need to clear the caches. Otherwise the import will work, but those tables won't be populated.
I've re-rolled the patch and added basic support for hierarchies. Hierarchy support currently requires that the source value be a numeric term id - could easily be modified to support source term names. Also it assumes that the parent term has already been migrated - this appears to work if you manually modify the source view to order the rows by the parent id desc.
I'm afraid I don't have more time to work on this, but will be happy to help with testing.
Cheers,
Stella
#11
Thanks for letting me know that the patch works stella - I hadn't cleared my cache, but I suspect my problems were related to the version of the module I was using. And thanks for adding hierarchical support! I'll check out the patch when I'm next spending time on this project.
#12
Thanks for the patch, it looks good for the approach it takes, but before committing it I'd like to:
Thanks!
#13
#14
Committed, thanks! I've gone with a single Taxonomy Term type, with optional vocabulary (expressed as vid or name) as a field. Parents can be fetched by name, with checking for duplicates and the correct vocabulary (if one is provided). I've settled for producing helpful messages when a parent term can't be found.
#15
Hi! This is a cool addition, but:
First, it imports terms as-is, without trimming. Second, I import node data which contains these terms in a field with $multiple_separator, and this is the code parsing them:
<?phpif ($vocab->multiple) {
$terms = array_map('trim', explode($multiple_separator, $value));
}
?>
So the terms are trimmed here. And so, the terms which had a space in the front were imported with this space by the taxonomy migration, and the node migration reports that it cannot find _trimmed_ version of the term. So you have to either trim the terms while migrating taxonomy (which I suppose is a right thing to do) or skip trimming when migrating nodes.
#16
Now I can't add a new content set for taxonomy destination, because taxonomy_migrate_destination_types() returns array('term' => t('Taxonomy Term')) so the $desttype is empty, and as the desttype field in the migrate_content_sets tape is NOT NULL, taxonomy content sets can't be created. So I'd either remove NOT NULL or return array('term/term' => t('Taxonomy Term')) from taxonomy_migrate_destination_types().
#17
Also, I miss URL path support for taxonomy destinations...
#18
Automatically closed -- issue fixed for 2 weeks with no activity.