Migrate version migrate-7.x-2.x-dev
Drupal 7.14

under Convert WordPress tags to the vocabulary:
Convert WordPress categories to the vocabulary:

The only option is: do not import

Even the built in 'tags' vocabulary does not appear.


mikeryan’s picture

Status: Active » Postponed (maintainer needs more info)

I can't reproduce this, is there any more information you can give? What browser are you using?

mikeryan’s picture

Actually, one other thing you can check - make sure that you have term reference fields on your blog post type for the vocabularies.

stellarvisions’s picture

This is one of our first experiences with Drupal7 and we had trouble finding where to associate the vocabulary with the content type.
Now we're going to try bringing in the blog data to see what happens.

stellarvisions’s picture

Status: Postponed (maintainer needs more info) » Closed (works as designed)
kikko’s picture

I had the same problem, but - I do not know how - it was self resolved:
I have cleared the cache (twice) in Configuration and with drush;
double checked if the term reference fields were configured;
I have put the term referenc fields in both kind of nodes: Page and in Article;
I had populate with one terme each taxonomy I had to use;
but still appear "do not import".
I used Chromium browser.
Then I have tryed to import (but failed for file size limit) and then the list was populated by the taxonomy I was looking for.
Hope this can help

break’s picture

I had the same issue and this is what fixed it for me: I had to switch the widget from "Autocomplete term widget (tagging)" to "Check boxes/radio buttons". Once I did this the I saw all my taxonomies instead of just the "do not import" option under both "Convert WordPress tags to the vocabulary" and "Convert WordPress categories to the vocabulary".

Offlein’s picture

Status: Closed (works as designed) » Active

This is not fixed.

I followed break's suggestion, but had no luck. Finally I visited the "Wordpress Migration" tab again and this time just clicked "Save" even without a file uploaded. It gave an error, but when the page reloaded the appropriate taxonomies were present.

I am pretty sure the module is just not loading or rebuilding the potential lists until you've run it once. I don't know if changing my Taxonomy Tags field to checkboxes affected anything; it should not.

mikeryan’s picture

Status: Active » Postponed (maintainer needs more info)

I still cannot reproduce this. What precisely are the steps you're taking? When you first open up the Import Settings fieldset, what is the node type selected for "Convert WordPress posts to"? Are all vocabularies attached to term reference fields on that node type listed at that point? When you change the selected node type, do the vocabulary lists change to reflect those with term reference fields on that type?


ryank76’s picture

I've just tried the wordpress migration process on a fresh install of 7.15. All I'm getting is Do not import.

I've gone into the Articles fields and changed the Tags options to check box/radio buttons, didn't work.

Same deal as #7 - once you run it once, your vocabularies appear.

earwax’s picture

Version: 7.x-2.x-dev » 7.x-2.0

I am doing exactly what ryank76 is doing. I have a fresh install of Drupal 7.16. I get no options to import any tags or categories into the Drupal vocabulary, but once I press the IMPORT button without specifying a file, then I get an error, but now I am able to choose my Drupal vocabularies after the page refreshes. After that, the option of only "do not import" is not there anymore. I think to replicate this issue, you need to enable the module, and then disable it and uninstall it, and then re-enable it and the problem should return. Or, just a do a clean install of Drupal.

Strange bug, but nothing serious once you know how to work around it.

mikeryan’s picture

I still cannot reproduce this - I disabled and uninstalled wordpress_migrate, and deleted all the variables it left behind (while I was at it, I implemented an uninstall hook so that should happen automatically in the future), re-enabled and the select lists were properly populated.

There's some other factor involved here...

Offlein’s picture

Sorry Mike for all the hassle. :(

Maybe it's a PHP environment thing? I actually just changed mine and can't test that well.

Another option is setting up a completely new site install (or at least database). Your way should work, I would think, but this would be more foolproof..

jpstrikesback’s picture

Saw this last night, even tho I couldn't select a vocab I did a migration (which failed) but the second time I went in to set it up the vocabularies were populated in the select lists for Tags & Categories.

I'm going to test on a local install as I think it was environment as well. I'm testing on Pantheon and things are wacky with ajax lately.


Migrate last nights dev
WP_Migrate same
Extras latest dev

mikeryan’s picture

Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

I was never able to reproduce this, so could not fix it for version 2.1. The UI is being completely redesigned for 2.2 with a step-by-step wizard, so this won't be dependent on AJAX refreshing and is extremely unlikely to be an issue in the future.

steveshen73’s picture

Hi #6 break.

Where did you make the change ? ("I had to switch the widget from "Autocomplete term widget (tagging)" to "Check boxes/radio buttons".") I did not know where to make this change. Can you show me the details what directory to go to change this. Content, taxonomy or blog entry content???



tbfisher’s picture

I found that causing the form to error out caused the vocabulary pulldowns to populate as expected.

Try giving a bad field value (like url) and submit...

milkmiruku’s picture

Version: 7.x-2.0 » 7.x-2.2
Status: Closed (cannot reproduce) » Active

You have to map to the taxonomy entities as term reference fields from the blog content type. Where to set 'unlimited' is a bit confusing though.

milkmiruku’s picture

Status: Active » Closed (cannot reproduce)
grinxols’s picture

#7 works for me. Thanks!

Screenack’s picture

#7 helped me here, too. Whatever that action is triggering allowed for me to choose the taxonomy vocab.

jnettik’s picture

Same here. #7.

earwax’s picture

I think it is obvious that this bug really does exist, and that nobody is going to fix it. But I think this is okay since it probably is not a high priority item. What should happen is to just document this and include it in the process "as-is" and let users know that this is normal. As long as it works, people will overlook this minor confusion.

blue_waters’s picture

Same as the others. Just run the 'Import WordPress Blog' once - without any options set and then the taxonomy options will be populated.

mortona2k’s picture

The only time variable_set is called is in the form submit:

wordpress_migrate_pages.inc:420 variable_set('wordpress_migrate_tag_vocabulary', $values['wordpress_migrate_tag_vocabulary']);

But it is used to populate the select list:

    $tags_default = (isset($options['tags']) ? 'tags' : '');
    $form['wordpress_migrate_taxonomy']['wordpress_migrate_tag_vocabulary'] = array(
      '#type' => 'select',
      '#title' => t('Convert WordPress tags to'),
      '#default_value' => variable_get('wordpress_migrate_tag_vocabulary', $tags_default),
      '#options' => $options,

There is $options['tags'], but since it is never set anywhere, will always default to an empty string.

To reproduce:
1. Fresh install of Drupal, wordpress migrate.
2. On first run of wordpress migrate, taxonomy select list doesn't populate.

dafeder’s picture

Just wanted to confirm as well. No vocab options, until I submit the form with no WXR file. It doesn't validate, but from then on the list is populated. Did not change any settings in the term reference field.

Aki Tendo’s picture

I think the trouble here is that those new to drupal take for granted that the importer is going to modify the blog content type to do the install correctly. I know I did. It's not, you've got to do some undocumented adjustment to the blog content type.

So, before starting the wordpress_migrate, first prepare your blog content type. If you want attachments, you'll need an image field. If you want tags, you'll need a term reference field for tags (drupal ships with one by default). You'll need to create such a field for categories.

The simplest fix to this "bug" is to set some reminder text in the interface to perform these actions.

The deficiency here is not in the code, but the documentation.

jnettik’s picture

@Aki Tendo

I did have this setup on my site. The problem was that the importer doesn't recognize those fields right away. So the mapping fields are empty despite the blog content type being set up properly. You need to first "submit" an empty import before it will recognize those fields. IMO documenting that you need to first submit the form empty so it can load the proper values doesn't solve the problem. Though it would help save some time in discovering that quirk on your own.

TGEink’s picture

Had the same problem. Did the submit thing and it resolved itself. Thanks for this thread.

chegor’s picture

Issue summary: View changes

#7 works for me too. Thanks!

  • mikeryan committed 871bb2d on xml-namespace-fix-wip
    Issue #1565042 by mikeryan: Remove variables on uninstall
othermachines’s picture

It is clear by the numerous posts here that this is not an inexperience/lack of documentation issue.

I'll also confirm that submitting the empty form (as in #7) populates the field (version 7.x-2.2).

* Edit: I'm pretty certain that "Field for attachments" in the Map content fieldset also appeared only after I submitted the form.

othermachines’s picture

Learned the hard way that it appears to be now necessary to use latest -dev (currently 7.x-2.3-beta2+4-dev) or wait for next stable release. I think this should be marked "fixed" even though it was resolved in -dev by a UI change.