vocabulary pop-up list not populated

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

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

Hi,
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

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".

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.

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?

Thanks.

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.

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.

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...

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..

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.

EDIT:

D7.16
Migrate last nights dev
WP_Migrate same
Extras latest dev

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.

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???

Thanks

--Steve

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...

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.

#7 works for me. Thanks!

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

Same here. #7.

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.

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

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.

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.

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.

@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.

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

#7 works for me too. Thanks!

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.

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.