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
Comment #1
planctus commentedThe 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.
Comment #2
dman commentedAt 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.
Comment #3
drzraf commentedI 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_vocabularyshould 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 -Comment #4
dman commentedI 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!
Comment #5
drzraf commentedinitial attempt.
most occasional breakage comes from xml_format.inc (expect additional patches for it)
Comment #6
drzraf commentedI 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 ?
Comment #7
drzraf commentedthere 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.
Comment #8
dman commentedQuick 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.
Comment #9
drzraf commentedI 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 ?