Add drush support

Heh. Turns out the file you give to drush can't be a single node, it must be an array of nodes.
Code as posted here works, except for the node uid which gets set to Anonymous, since this is what drush runs as. This could probably be fixed with a user_load() of uid 1, or a change in the module.

Updated version.
The drush command switches the current user to uid 1 so nodes aren't anonymous. Added help too.

I don't understand what you've done, and what this is for. You really need to explain what you're talking about.

I think perhaps more discussion is required on this before you commit yourself to more coding. We need to make a plan for what is possible with this module and what options should be available. What might someone intend to do with this? How will they use it? Will they still configure via the gui? Can they export as well as import? What sort of namespaces should this module be using? Can we create drush support in a separate module?

My use case is a client who wants a new site every few months with the same set of about a dozen pages to start with -- about, history, contact us, a webform and so on.
I've been using bones modules for this, which takes care of menu structure and paths, but the content still has to be copied over.
However, with this module I can create the content quickly.
And with drush support, I can make this another step in my drush install script:

To answer your other questions:
- it probably makes sense to take the gui options. Drush can take commandline switches, but your module's code would need changing to accept them, probably.
- export would be useful too I think; however I just needed import for now. I'm sure if you committed this someone would provide the export ;)
- I don't think it makes sense to put drush support in a separate module. Most modules that support drush do so by adding the drush inc file to provide drush support in parallel to the gui.

It would be good if the command was "node_export" since that is the name of this module. There is actually a module called "node_import" and we wouldn't want a clash if they decide to use drush too.
Here is what you might need to do

- Export a single node onto the screen
- Export a single node into a file
- Export bulk nodes onto the screen
- Export bulk nodes into a file
- Import from a file
- Import from input
- Set temporary settings for a particular operation above (??)
- Set the settings of the module permanently (??)

I have never used drush so forgive me if I don't know what I'm talking about.

I am willing to restructure the functions to make this possible. But I haven't found anything more than a basic guide on creating drush command - nothing that includes adding parameters and stuff.
Given what I've said - how could the command or commands be structured to make it obvious and usable for the majority of drush users?

something like this?

node_export export 45 46 47

node_export import < nodes.txt

I have no idea what's possible, and how to add flags for the settings, etc..

Good point about the namespace.
So:

I don't think we need to distinguish between printout to terminal and to file -- that's what command line redirection is for:

As for settings, I don't think it's customary for drush module commands to let you change settings permanently. So I'd say skip that.
For setting import options at command time, drush takes options like --path, say.

The approach I took for module_builder was to restructure the module code so that instead of the function that does all the work doing variable_get() to find out settings, it has them passed to it as parameters. This means drush can check the command line options and pass them, and the GUI-based system can pass them in when it calls the workhorse.
This may not be the most elegant method!
The other option I can think of would be drush reading the existing variables, storing them, setting them to the values given by the command line, then restoring the originals after the command has run.
This is doable, again not hugely elegant, and if we were to implement this it might as well be in core drush for all modules to take advantage of -- say as a function drush_temp_variable_set() and drush_variable_restore_all(). Which might already be in drush, must go check ;)

I'll have a look at restructuring the drush inc to change the command names and give you a stub of a node export command.

On second thoughts,

means you don't see error messages, so we should add a file option too.

Updated version of the file with changes as outlined above.
I've left the calling of the exporting code for you to do, everything is in place, just turn the $nids into $data :)
Not looked at overriding settings yet: see #610372: system for setting temporary drupal variables.

Just found there's a stray closing bracket in the 'examples' key in the first hook.

This should appear in the dev version later today, let me know if I've got anything horribly wrong because I don't use drush!