I attempted to test feature export (with drush).
drush fe finds the following features from taxonomy_xml:

 taxonomy_xml_source:file_upload                                                                 
 taxonomy_xml_source:url                                                                         
 taxonomy_xml_source:lsid                                                                        
 taxonomy_xml_source:lookup                                                                      
 taxonomy_xml_source:sonz                                                                        
 taxonomy_xml_source:local

I expected to find taxonomy machine-names instead, but I went for drush fe plop taxonomy_xml_source:local anyway.

But there's probably a problem with taxonomy_xml_source_features_export_render:

Missing argument 1 for node_type_get_name(), called in /drupal/sites/all/modules/taxonomy_xml/taxonomy_xml.features.inc on line 73 and defined node.module:450
Undefined variable: node node.module:451
array_map(): Argument #2 should be an array taxonomy_xml.features.inc:73

* $data is correctly passed:

array(1) {
  ["local"]=>
  string(5) "local"
}

* the proto of node_type_get_name() impose an argument but... which one ?

Comments

planctus’s picture

The same is happening to me...even though i'm not even getting how the features should work. Is there any documentation about this..?
Thanks,
Da.

dman’s picture

At the time of release, only features import was fully supported :-/
There is no comprehensive GUI/API way to actually make features EXPORT work as intended without some manual code editing on the features source code itself. That's why there is no docs, it's unreleased -dev placeholder code. Exactly how this is intended to work is not actually resolved yet. What you see exposed as exportables are just stubs for where actual data may turn up when that code gets actually built.

drzraf’s picture

I would like to see a simple drush commands which dumps/reads a given taxonomy in XML.
drush array + 1 parameter + a call to taxonomy_xml_export_vocabulary should do the trick for the export; it should be straightforward.
Import may be a bit more complex but quite doable (stdin|filename)

Is there interest in such a patch or should this issue be kept on hold waiting for new/proper feature/exportables API integration ?
In the former case I would happily provide such a patch to end up with a lovely :
$ drush @site1 export taxonomy <name> | drush @site2 import taxonomy -

dman’s picture

I don't have the brainspace to revisit the features side of things again in the near future, and I'd appreciate anyone else trying to help review/rationalize/improve the module in general - so please have a go!

drzraf’s picture

StatusFileSize
new2.49 KB

initial attempt.
most occasional breakage comes from xml_format.inc (expect additional patches for it)

# drush help taxonomy-export
Export a taxonomy
Arguments:
 taxonomy name                             Machine name of the taxonomy 
Aliases: tx-e
# drush help taxonomy-import
Import a taxonomy
Arguments:
 filename                                  Filename of the taxonomy XML file (or "-" for standard input)    
 taxonomy name                             Machine name given to the taxonomy (or matching an existing one) 
Aliases: tx-i
drzraf’s picture

StatusFileSize
new2.55 KB

I don't understand what the last chunk of this commit was aimed to :
http://drupalcode.org/project/taxonomy_xml.git/commitdiff/b2bb3afe04eaa2...
( what exactly should be $vocabulary ?)

attached is patch which does the bare minimum in term of variable checking/correctness.
I'm getting troubles with $depth, I guess it's not loaded from the XML (I've to test this).
Are you interested in using SimpleXML in place of the current manual parser ?

drzraf’s picture

StatusFileSize
new2.54 KB

there is an echo $data; left in the above patch ;)
I also know about the (empty) _taxonomy_xml_drush_xml_export() left in the drush include.

dman’s picture

Quick answer - as best I can glance at them and recall:

That patch you linked to was the result of passing it through he automated coder upgrade. There should be no functional changes introduced there.

Please feel free to rewrite the xml-format as much as you like - I'm not doing much about supporting it in favor of more portable RDF-XML syntaxes. The made-up drupal-only XML syntax adheres to no standard, and I'd rather work on interchangable formats.
I use DOM-XML rather than simpleXML as I know the structure and function names it gives me better, and I prefer to use namespaces etc - but for the custom XML format, I don't think it makes a difference, so whatever is simpler for you. If I were rewriting it, I'd totally re-do the string concatenation it uses and use real XML constructs. It's pretty much legacy to me.

IIRC, $depth was never really used. It was output "because it was there", but not read in, as it's a derived value that should be determined by the parentage.

drzraf’s picture

I would add that I'm getting import trouble because of taxonomy_xml_prepare_vocabulary().
I don't want it to be fired seems I expect to import taxonomy without the need for guid and synonyms.
Could we think about making optional (if needed) the call to this ?

Moreover I'm getting an empty 'taxonomy_xml_vocabulary_ids' while I've currently 4 (empty) taxonomies; is this case supposed to happen ?