Import not working

Drupal doesn't see the import. The import looks like it works by the messages. I look at the database with phpadmin and there are terms but when I "list terms" it is empty. Using D6.6. Importing from this module export taxonomy_xml-5.x-1.0.tar

I'm experiencing the same problem. When I export with this module and then try to import the same file the taxonomy gets created but there are no terms imported. Also, when I am exporting the taxonomy is a single hierarchy and when I import it, a multiple hierarchy is created. I am not using the dev version of the module.

Hope this helps,

Same here.
I try to import country list taxonomy (http://www.drupalsites.net/blog/robo/country-list-taxonomy) and it writes the same error message. It write the whole country list on the screen but doesn't add anything to the taxonomy list itself.

Same issue importing from xml generated in D5 (in D5 works fine).

Same here, trying to import from D5 to D6. No Luck

Same problem here. Exporting from one 6.8 install to another 6.8 install.

I received the following error when I tried importing via an XML file:

* warning: max() [function.max]: Array must contain at least one element in E:\server\htdocs\xampp\tindalist\sites\all\modules\taxonomy_xml\xml_format.inc on line 170.
* warning: max() [function.max]: Array must contain at least one element in E:\server\htdocs\xampp\tindalist\sites\all\modules\taxonomy_xml\xml_format.inc on line 170.
* Failed to import any new terms. This may be due to syntax or formattings errors in the import file.

Same problem, trying to import with the sample-north_american_countries_and_states.xml sample file provided with the module

I see it now.
(Sorry I didn't see the earlier messages)
It's pretty easy - at some point taxonomy_get_vocabulary() became taxonomy_vocabulary_load() - this meant that the terms were being created - but not being assigned a valid vid. Pretty messy.
The legacy 'xml' syntax didn't get a lot of love in the recent updates, so it skipped testing in some cases. Should possibly have still worked if defining the vocab from the file.

Anyway. I'll roll out that patch for that. About time I did another release anyway.

... That's a fix for the symptom listed in #1, #2, #3 etc . Not sure about #6 which sounds like something else

Post #4 Fixed. Thanks!!!

This is still not working as of today in dev if we are talking about the import of po files. Duplicate
http://drupal.org/node/384794

I'm using a newer version (6.x-1.3) and that fix I don't think will fix my issue with it automatically showing up as "mutliple hierarchies" when it is in fact single hierarchy. To me, what seems to be going on is hierarchy => '2' ($vocabulary->hierarchy) is set in _taxonomy_xml_get_vocabulary_placeholder, and i can't seem to find where that value is updated...

Well, a multi hierarchy doesn't prevent you from building a single hierarchy within it.
It just assumes multi during imports, and lets that data decide what happens if there are more than one parent.

After that ... isn't it a checkbox on the vocab edit screen? You can turn it off there.

Whoops these are the WRONG FILES! (mistake upload)

After that ... isn't it a checkbox on the vocab edit screen? You can turn it off there.

No, there isn't a checkbox in vocab edit. I'm using Drupal 6.13.

I don't like it 'assuming' multi hierarchy during import... so i changed the code to read the information written to the XML file (the 'hierarchy' tag, which changes from 0 (no hierarchy) to 1 (single hierarchy) to 2 (multi hierarchy) when the structure changes accordingly), but it won't force a multi-hierarchy into a single, if the vocabularies are being merged.

I didn't want my client to have to deal with not being able to edit the imported data so I made it import properly.

I also made a few other fixes, like to the links generated after import is successful.

I also changed the URL import to never cache. The ideal thing to do would be to have a checkbox next to the field labeled "don't cache URL" or something that would control this feature. Right now it is hard-coded and kinda makes caching ineffectual.

Note that the "Multiple hierarchy" default problem and broken links in import success text is ONLY fixed for the XML format, other formats will behave like they used to.

Also of note, when importing the taxonomy, I don't know what the "Nodes" field is for. Its an array. I don't know if it gets imported into an array. I don't have any example data to import. (and i don't know what 'nodes' does anyways).

You can replace these files in the 6.x-1.3 VERSION only.

Somebody ought to take these changes and make them official... its only a 'hack' right now. (I did these because i needed the site to work no matter what, and I think others will appreciate this)

Hope ppl find this useful.

To apply a patch, copy the patch files into the same folder as the files to be patched then run "patch -p0 < [patchfilename].patch"

FWIW, I've never used the 'nodes' array either.
It's from the old old code that defines which node types the vocab applies too. Not been tested in the last two years.

The feedback messages are in a constant state of update. In the -dev roll it's all logged at various debug levels, not just dumped direct to the screen.

The caching so far has only been running against static 'official' sources that don't change. And sometimes against actual thousands of small spidered requests, repeatedly in testing. So the cache behaviour is what made sense for that situation.
I've added a 'delete this file' and a 'delete all cache files' on my current dev-dev version (not committed yet, it's got other issues)

ANY feature change like those you mention would have to be in the form of an extra option on the admin screen UI, not just a direct change in the code. Just hacking out caching is not a fix, making it behave better (maybe through HTTP headers) is.

I wasn't aware of any way in which defaulting to a 'multiple' hierarchy could prevent you from managing a single hierarchy or even a flat one. But if you want the choice, it should be given as a choice to the user during import or when editing the vocab directly.

I agree with you, I was just putting in 'hacks'... especially on the cache thing.

For the multiple hierarchy thing, it just would not let you edit the taxonomy hierarchy at all, when it was in fact a single hierarchy. The information for whether it was a multi-hierarchy was written to the XML, why not use it?
I never tried, but its probably possible to add a single hierarchy to the vocab after that... is this what you were referring to?