XML Export Format

The alter hook "node_export_node_encode" will be completely unsuitable for you to reformat the structure of the output - it will only allow you to make small changes to the values, but you would have to maintain the existing output structure.

To enable you to do what you want I would need to add an additional hook at the top of the function node_export_node_encode() to allow you to completely bypass the default code of that function and return your own values.

Then another corresponding change would need to be done on the 'import' side to allow your module to hook in and interpret the code.

This will be useful for one of my projects.

I want to use node_export to write and read in nodes for an external process to use. So, I would like the hook that @danielb suggests.

The problem I see is that there maybe times when unaltered node export will be useful -- say to migrate content. I hope there is a way to add the hook for only some calls to the module.

Have you written the code to generate the XML?
It would solve a few issues to completely switch this module over to something nice like XML.

Hmm OK I will reconsider the design of node_export to make it easy for you to add the functionality when you're ready.

It would also be good to make a second default export option available, CSV export. I wouldn't even need to implement the import phase for CSV, just prompt the user to install Node Import for that.

The question is, do we force the user to pick the format for import, or should it be autodetected somehow?

So I'm doing what I originally said and adding this to the top of that function

<?php
  // Allow other modules to take over this entire process.
  if ($iteration == 0) {
    $return = FALSE;
    drupal_alter('node_export_node_encode', $return, $var);
    if ($return) {
      return $return;
    }
  }
?>

Now I just have to figure out something similar for the import side.

Now I have to decide if there is some way I can pass down another 'option' or parameter from somewhere, where you actually pick the export method :/

Nevermind on importing CSV, as it has already been implemented by another module.

I know, I said that. But the export would be a good idea. Even though you can export CSV with views bonus, it's still a bit of a mission to set it up. I could just provide a quick dirty way of doing it.

changed again slightly

<?php
  // Allow other modules to take over this entire process before the first 
  // iteration.  Typically the module would respond if $format was set to
  // something it recognises.
  if ($iteration == 0) {
    $return = FALSE;
    drupal_alter('node_export_node_encode', $return, $var, $format);
    if ($return !== FALSE) {
      return $return;
    }
  }
?>

and for imports:

<?php
  // Allow other modules to take over this entire process.
  $return = FALSE;
  drupal_alter('node_export_node_decode', $return, $string);
  if ($return !== FALSE) {
    return $return;
  }
?>

and bulk exports

<?php
  // Allow other modules to take over this entire process. Typically the module 
  // would respond if $format was set to something it recognises.
  $node_code = FALSE;
  drupal_alter('node_export_node_bulk_encode', $node_code, $nodes, $format);
?>

So the idea so far is this...

For exports of single nodes you would implement the hook like so

<?php
YOURMODULE_node_export_node_encode_alter(&$return, $var, $format) {
  // your code here
}
?>

Initially $return will be FALSE, if you change $return to something else, you will override node_export's default node code to whatever that value is.
$var contains the node object.
Now you could either decide to always override the $return value (which would be a problem if multiple modules decided to do that as only one of them would work), but it would be better to only intervene when $format is set to some string that your module recognises. The idea is that if we went to the URL node/40/node_export/xml it would try to export node 40 with 'xml' as the $format. I don't know if that work, but that's the idea.
(You do not need to actually return anything)

For imports, the hook is implemented like this:

<?php
YOURMODULE_node_export_node_decode_alter(&$return, $string) {
  // your code here
}
?>

No $format this time, I'm hoping we can automate that by detecting something in the node code or attempting to parse it and reject it if it's inappropriate.
For the import you would have to change $return to something that correponds to what the default handling of imports in node_exports would do, an array of node objects, or just a node object.
(don't return anything)

Now you also need to handle bulk exports for completeness

<?php
YOURMODULE_node_export_node_bulk_encode_alter(&$node_code, $nodes, $format) {
  // your code here
}
?>

again, $node_code starts off as FALSE, if you change it you override it
Your code would ideally loop through $nodes, pass them off to the function you created earlier to export single nodes, and then somehow concatenate all the returns from that function into $node_code.
(again, you don't actually return anything)

You should also implement your own hook_node_operations() following what node_export did, but changing the label slightly, and adding the 2nd callback argument that is your $format string. But keep the callback the same as node_export, don't replace that.

These changes will appear in the next dev release.
Now I haven't tested any of this, so let me know if it's unsuitable or just doesn't work, etc...

Yeah they should be in dev

Was any more progress made on this? I am considering going ahead with this myself because it seems fairly easy? There are quite a lot of resources on converting associative arrays to xml and vice-versa, which should be all that is needed I think?

Just a note to myself to remember to check/update the api file for changes I've made as a result of this thread.

edit: Done that now.

So when do you think Node export will offer XML or CSV export format? That would be such an improvement! Thanks.

Just focusing on XML at the moment. I've started looking into implementations. I think the best way would be to keep it generic but include as much knowledge as possible.

<node type="object" class="stdClass">
  <nid type="int">34</nid>
  <title type="string">My Node</title>
   etc...
</node>

Might be able to leverage this module http://drupal.org/project/xml_parser

turns out type via gettype() is very unreliable as most numeric value are treated as strings, so I'm ditching that as it would be misleading more than anything.

I have committed an XML implementation, use with caution for now I guess.

Great news - thanks for adding XML support. Will try it asap.

FYI have also added a CSV format, it should appear in the next snapshot

Thanks a lot. I have installed the latest 6.x-3.x-dev (2010-Dec-07) of the Node export package and enabled the Node export and Node export CSV modules. I have CSV exported one simple page containing a newline within the body's HTML code.

The resulting CSV file contains the newline as is in both the body and teaser fields:

"'<p>Paragraph 1</p>
<p>Paragraph 2</p>'"

In addition, the last field - export_display - also contains several newlines:

'$display = new ;
$display->layout = \'\';
$display->layout_settings = \'\';
$display->panel_settings = \'\';
$display->cache = \'\';
$display->title = \'\';
$display->content = array();
$display->panels = array();
$display->hide_title = PANELS_TITLE_FIXED;
$display->title_pane = \'0\';
'

Of course a CSV file should only contain one single line per record (without any newlines).

Of course a CSV file should only contain one single line per record (without any newlines).

New lines (\n) are perfectly fine in CSV data.

Additionally the CSV export rows are delimited by CRLF (\r\n) and any data fields containing CRLF are enclosed in double quotes as per RFC 4180.

http://tools.ietf.org/html/rfc4180

It will work in Excel and it should import back correctly as well.

OK but look at the value of the 'export_display' field. It contains several newlines but the whole value is *not* enclosed within double quotes. but I think we should better open a new issue for this.

You example doesn't contain CRLF line breaks, so it doesn't need double quotes.

Note that \r\n line delimiters may not be recognized by all OSes (for example, MacOS < 10), so I would not count on \r\n being distinguished from a single \n on all platforms.

In fact mac OS used to use \r. So \r\n will at least create a break on windows, old macs, and unix, I think that is why \r\n was recommended by the RFC. It doesn't matter anyway, when interpreted by a CSV parser it should be treated as a record delimiter, not strictly a 'line break'.