Under which version of Drupal is this module designed to run?

This module was working with 4.6, using a patched version of book.module which took care of the export. The error you are

The patch for book.module is still in the queue; I have just returned to looking at it. I hope that it will be accepted for HEAD soon.

It might make sense to move the export functions into this module, and rename the whole thing, what do you think?

If you are interested in porting this to the new 4.7 Forms API, that would be awesome.

Actually, feel free to suggest any other approach to the user interaction that makes sense to you. I went with the first idea that came to me.

Please feel free to contact me if you have any questions or would like to discuss this.

Best regards, Djun

Thanks for the response!

And sure, I wouldn't mind helping convert this module to 4.7.

What patches are required to the 4.6.x book.module to get this to work? I found this thread http://drupal.org/node/1482. Is it http://drupal.org/files/issues/xml-export-01.patch and http://drupal.org/files/issues/xml-export-03.patch and http://drupal.org/files/issues/book.module_6.patch ?

Actually I meant http://drupal.org/files/issues/book_30.patch for the last one there.

"It might make sense to move the export functions into this module, and rename the whole thing, what do you think?"

I could actually see that being very useful. I found this module (haven't looked too closely): Import/Export, which seems to do some kind of export/import for generic nodes. Could a tool like this be adapted to work with book-type nodes as well, or are there specifics in the book nodes that justify it being its own tool?

Btw, my use case is taking parts of the Drupal.org handbook and importing them into a Drupal 4.6.x-based site and keeping the 2nd site synchronized periodically. Therefore it needs to:

1. Check if each book page already exists.
2. If so has it changed?
3. If so, update it to the new content from site #1.
4. If it doesn't already exist, create it.

I was hoping to use existing tools for this, and from looking at the UI, it looks like bookimport module is designed to do this. So I'd be happy to assist you in any way in getting relevant patches into Drupal HEAD so that this could work.

I've tried to funnel all of the issues related to XML generation from book module into issue 1482. Hence the latest patch which has been submitted is http://drupal.org/files/issues/book_30.patch.
I'm currently reworking this to address the issue regarding export of PHP code which was brought up in issue 1482. I expect I'll have that finished up today or tomorrow.

The sequence of events leading up to BookImport was: decide export to DocBook would be nice, have people request import from this format, decide that a different format for import/export was appropriate, discover import/export module :(

I like the way that export for books works in my approach - it actually extends to any old
node type, and any composite of nodes, including the various relational models such as node relativity. (I think that those approaches have a great deal of promise, and represent the future of structured collections of nodes in Drupal. ) The 'visitor' approach puts responsibility for structure with the structure-providing module (e.g., 'book') while hiding details of representation with the module that wants to transform representation.

On the other hand, Import/Export also captures 'associated' information such as taxonomies, and (IIRC) comments. I don't know how widely used import/export module is - my impression is that it's not very active. It would be good to combine these and extend to relation-based structures.

I think that this has some additional implications - probably the nicest way to keep two distributed documents in sync (even entire Drupal sites) would be to use a model where one site notifies another of changes, and the second site requests changes and applies updates. Lots of interesting problems to be solved in this approach - do we need to do this as a 'master-slave' situation, or more symmetrically; do we poll or use some kind of event based or periodic notification (RSS?); or perhaps a comparative approach like rsync would be useful.... Having decided what needs updating, how do we request updates (XMLRPC?); how do we deal with nodes that need changes merged? What kind of performance impacts (CPU, network) do we need to consider? However, all that aside, if we can package nodes as XML chunks, they will be easier to sling around and catch.

All of this also ties into my interest in integrating Drupal and DITA, the topic-oriented, extensible infomation-typed architecture for content sharing and re-use. ("Object orientation applied to content modelling", or something like that...)

For now, I'm happy to keep it real simple :)

I guess at a minimum, the forms in bookimport would need to be updated to the new API. If you are inspired to improve the workflow/user interaction, feel free :)

Hehe simple is good. :) So we can start with the easy stuff.

I have tried applying those patches to every single version of book.module I can possibly think of and can't get them to apply. Would you be able to upload a copy of your book.module that's working with bookimport so I could take a peek and then get started on the 4.7 translation of this module? I need to start with everything working so I know if something doesn't work it's because I broke it. ;) Else I can wait for your new patch to address the PHP export stuff (I assume this will be rolled against the current HEAD?).

OK, I've submitted a new patch which should apply against CVS head (which was @ v333).

This removed most of the export functionality. I will now submit contributed projects for
export_dxml and export_opml to enable exporting of Drupal books as XML and OPML
respectively.

Djun

I've created projects for export_dxml and export_opml; the former is what you want to export books (i.e., export_dxml and bookimport should work together).

Export_dxml depends on the patch I just submitted at http://drupal.org/node/1482.

This patch removes the export functionality from book.module while enabling external modules to be called from book_export.

If you require any of this for Drupal 4.6, let me know and I'll attempt to generate the
appropriate patches.

Djun

Awesome, thank you! I will take a look later today. :)

The patch to book.module has been committed, so export_dxml.module will now work with the CVS Head book.module, and generate XML which book_import.module can use. Whew!

Djun

I'm not sure why this issue is closed. In my experience, import-export and book-import are completely broken under 4.6.3 and 4.6.5.

Hi walterbyrd - please file issues regarding import-export with the import-export module.

Book import has been tracking CVS head: it was 4.6 for a while, then 4.7-ish. Of course 4.7 has been a moving target, so book-import probably needs to be updated again. Thanks for bringing this to my attention.

Regards, Djun

By the way, to address the actual question - this is closed, because the question asked in the original issue was answered - this was a support request, asking what version the module supported. The issue with the 4.7 forms API is being tracked at http://drupal.org/node/44088.