Handle book structure

Books are not preserved. This module is designed to export nodes, not books.

I'm not sure why it's reversing the book structure - could be a fluke that the nids are swapped around. Either way there is nothing handling the book information during import. The more I think of it, I guess it wouldn't be that hard to write a bit of logic to check for this first, and since book.module is in core this is a legit feature request.

PS. In the latest versions of this module you can there is a config option to remove some of the book structure info from the export codes.

The only way to solve this is to handle book structures completely. Reversing the nids just happens to fix your test case import - but it will not work in all cases.

Hi danielb, this might help the situation. I recently had to deal with many exported book and wrote this helper function to manage them. It needs cleaning up, and still needs the rest of the integration with node_export.

Here's a rough, rather brute force, plan that may work:

1. Prerequisite: Only entire books exported in a single file will be supported (to ensure internal mlid links are consistent)
2. Import all nodes in the "book" export, resetting the book structure
3. When finished, loop over each book node that was imported and make a map of each node's mlid -> parent_mlid. Probably a tree structure of some sort.
4. Use this map to reset the outline of each book matching each child to their parent as required. To be efficient, probably traverse the tree such that parents are created before children.

The helper function to create book outlines is:

/**
 * Sets outline information for a book page.
 *
 * Examples:
 *   // Create this page a new book
 *   $a_book = node_load(123); // assuming $a_book->type == 'book'
 *   $a_book->book = array();  // Reset the book information
 *   install_book_set_outline($a_book, NULL, TRUE);
 *
 *   // Add a child page
 *   $child = node_load(124);  // assuming $child->type == 'book'
 *   $child->book = array();   // Reset the book information
 *   install_book_set_outline($child, $a_book->book['mlid']);
 *
 * @params $node
 *  The book page node.
 * @params $plid
 *  Menu MLID of the item to be this page's parent.
 * @params $weight
 *  Sets the menu weight of this book.
 * @params $reset
 *  Make this node into a new book / page.  Clearing any old book outline
 *  information.
 */
function install_book_set_outline(&$node, $plid = NULL, $weight = 0, $reset = FALSE) {
  // The object needs to at least be something that looks like a book page
  if (!$reset && !is_array($node->book)) {
    return FALSE;
  }

  // Resets the book
  if ($reset) {
    // Delete any existing information for this book
    if ($node->book['mlid']) {
      db_query("DELETE FROM {book} WHERE mlid = %d", $node->book['mlid']);
      menu_link_delete($node->book['mlid']);
    }
    $node->book = array();
    $node->book['bid']  = 'new';
    $node->book['mlid'] = NULL;
  }
  // Makes this a child book page of a parent MLID
  if (is_numeric($plid)) {
    $parent = book_link_load($plid);
    if ($parent && $parent['access']) {
      $node->book['bid']       = $parent['bid'];
      $node->book['plid']      = $parent['mlid'];
      $node->book['menu_name'] = $parent['menu_name'];
    }

    // Set defaults.
    $node->book += _book_link_defaults(!empty($node->nid) ? $node->nid : 'new');
  }

  // Set the weight
  $node->book['weight'] = (int) $weight;

  // Allow other modules to deal with the bid changing
  if (isset($node->book['bid']) && !isset($node->book['original_bid'])) {
    $node->book['original_bid'] = $node->book['bid'];
  }

  // Find the depth limit for the parent select
  if (isset($node->book['bid']) && !isset($node->book['parent_depth_limit'])) {
    $node->book['parent_depth_limit'] = _book_parent_depth_limit($node->book);
  }

  if (!empty($node->book['bid'])) {
    if ($node->book['bid'] == 'new') {
      // New nodes that are their own book.
      $node->book['bid'] = $node->nid;
    }
    $node->book['nid'] = $node->nid;
    $node->book['menu_name'] = book_menu_name($node->book['bid']);
    return _book_update_outline($node);

    // The following should now exist
    //  * $node->book['bid']
    //  * $node->book['mlid']
    //  * $node->book['plid']
  }

  return NULL;
}

I also need to be able to export content in books, so I created a module, node_export_book, to do that. Attached is the result of my work.

I chose to patch the node_export module rather than just create a new module because I don't have CVS access yet, I don't have time to maintain a module right now and I figure that, since book is part of core, the ability to export books might as well go with node_export itself.

I was developing on the HEAD of node_export-6.x-2.x; but AFAIK it should work on any 6.x-2.x version of node_export. I did not develop for 6.x-3.x because the HEAD of that branch did not actually work at the time.

@James Andres, your install_book_set_outline() function was super-useful and saved me a lot of work! Thanks!

Disclaimer: CVS apparently doesn't like it when you add files (refuses to generate patches), and I couldn't find any best-practices to get around this (or at least, ones that worked for me), so I ended up using Git to generate the patch instead. Git signifies creating a file by patching nothing (/dev/null) into a file... patching worked fine on my systems (OS/X and Linux), but I can imagine the patch not applying as nicely on non-UNIX systems, which may or may not have a /dev/null.

I won't use that patch, because it's against the 2.x, and I don't know if I'll be able to get a git patch to apply. But thanks for your efforts, I will use your patch and James' post as reference when I get around to this.

I just tried running my patch against 6.x-3.x HEAD. It applies cleanly, but I don't think that one of the hooks is being called: some of the fields that I expect to be in the node code are set to FALSE instead of having a UUID (like I expect). I suspect this is because the hook has changed names slightly, but I haven't done enough investigation to be able to say that for certain.

I will investigate further and try to generate a patch for 6.x-3.x HEAD.

Don't worry about making a new patch, I have another idea on what might work here, and I can always reference your previous patch for clues.

@danielb: Okay.

Returning issue to previous state.

I just used my patched module again and discovered that I forgot to mention something important earlier: it only parents the book pages properly if the exported book pages do not contain the `Menu link` information (i.e.: it only works if the node array is missing the 'menu' => ... sub-array).

This is because the Book module uses menu items to build the book structures.

is this planned to be in the 3.x version? I'd love to account for this module in the outline designer and allow for a context menu option for 'export node structure'

@danielb, have you made any progress implementing this in version 3.x?

@btopro approached me through e-mail for some support, and we ended up discussing whether or not it would be good to make a separate node_export_book module so that people can take advantage of it right away. It would also save the maintainers of node_export from the trouble of maintaining node_export_book. I'm interested in feedback from anyone in the thread — does anyone have any comments about this? Is this a good idea? Would anyone use the module?

If not, we can post the poc here for reference. This is a screenshot of the GUI modification provided by the node_export_book module that's been thrown together

Development of features on this module will now be focused on 7.x-3.x-dev, with backports possible after fixing.

I've re-written node_export_book for node_export-7.x-3.x. It incorporates the changes to the book administration page GUI that @btopro wrote. Please review the attached patch.

I've changed the patch to be explicit about which versions of node_export and UUID it depends on.

I'm wondering when the D6 backport will be available.

I have to export a book with almost 300 nodes in it. It would be very helpful if I didn't have to manually redo the Book structure after doing the Node export/import.

@mparker17 I would definitely be interested in a separate module that I could use right away. Maybe at least until the D7 version has been backported.

Don't change the issue settings.

@tarzadon: my employer works mostly with not-for-profits and charities, so we don't currently have the budget for me to work on a backport to 6.x-3.x (unless you're willing to hire me through PeaceWorks). I could do the backport in my spare time, but considering that I work 3 jobs, there's no guarantee that I'll be able to get it done in a timely manner.

We currently get around the lack of node_export-6.x-3.x support by:

1. git-clone node_export's 6.x-2.x branch
2. patch that with my patch from #11
3. perform the export/import
4. either uninstall node_export or upgrade it to a 6.x-3.x release

to the person looking for a D6 way of migrating book items... download http://drupal.org/project/elms_features and look for the elms_content_import and elms_content_export features. The exporter can be activated on any drupal site to add a link next to a book outline that says "export". This dumps to an XML file with UUIDs.

elms_content_import sits on the site you want to import into and uses Feeds + Feeds XPath Parser + Feeds Node Helper + UUID modules to import the data correctly on the other side. Probably won't be a direct turn it on and be done (tho both have been run in production to migrate content outlines and import them into OG structures).

I know this isn't a node export type of thing but it is 6.x and could keep this conversation from drifting down the "WE NEED A BACKPORT NOW" road too far.

@mparker17 Thanks for your instructions. It worked pretty well! Except now when I edit it a node, there is no parent listed. It's strange. The Book is listed correctly, but the Parent Item is blank.

I think I figured it out. When I imported the book, the book structure was created in menu_links with the menu_name= "primary_links" and module="menu".
I changed all the relevant menu_names to book-toc-[bid] and module = "book"
Now the book doesn't show up in Primary Links and when I edit the nodes, Parent Item is correct.

I've been looking into solving this over the last couple days with another technique, which has failed, because the book module friggen sucks. Node are related through menu links... not through node ids... at all.. argh
I'm still thinking about it, I really don't want to maintain a whole another module just for books :(

Maybe this would help -- http://drupal.org/project/menu_node optional requirement of this would allow for something with much easier queries for relationability.

For D6 I use http://drupal.org/project/feeds_node_helper + UUIDs in order to make a feed that can read in XML structures and convert the UUIDs to the new node IDs on creation. D7 is untested but would be happy to accept patches to get it working if there are issues (its a machine port).

I have a plan that would automatically include all pages of a book anytime any page of a book was exported. All pages at least for now, we could get into the finer logic of it in the future. It would still require custom code specifically for the book module to fix the mlid, but it is a lot less code than node_export_book. The bid fixing would be somewhat automatic (would use the same processes that node reference, etc.. use, hence no new custom code)

I've created a module called node_export_dependency which is intended to replace node_export_relation.
It can automatically exports book pages related to any book page being exported, and tracks the information about book dependencies. However it might not completely fix things up upon import, not sure - there is another problem discouraging me from testing this from another issue. I've created a function node_export_dependency_node_export_dependency_alter() where code would go to make any additional fixes required.
When #744758: Handle overwriting, skipping, and nid preservation is fixed it will be a lot clearer how to proceed with this.

Yeah definitely needs work, in some configurations it breaks completely, in some it associates to the wrong nodes.

Specifically if resetting the book mlid on the content type vs not, and creating a new node vs creating a new revision.

I also saw that the wrong parent associates books showed up on an import. Let me know if I can test things for you danielb. Would be amazing to get this functionality, it would save all the node_save etc I am doing manually for books.

I've implemented a change to fix the mlid issue, and made it clearer in the settings that when creating duplicate nodes on import the relationships will be maintained to the old nodes. That's still a problem of course, but I haven't worked out how to deal with it.
Anyway more testing still needed.

Here's my use case that destroys the books hierarchy:

1. Create x amount of nodes in a book hierarchy.
2. Export all the above nodes to a feature (but you could manually export all of these; same result).
3. Delete all the above nodes.
4. Import nodes (trough features or manually)

At this point my top level book node isn't a proper top-level book item anymore, and all it's children have been left with no parent.
The

It seems the book export isn't making use of UUID enough.

More observations:

• Book module keeps track of book nodes through menu links (mlid). However, when Node Export imports an existing node it gives it a new mlid, resulting in multiple menu items. It should delete the old menu if it's going to create a new one (the same goes for regular menu items, btw, but that might have to be addressed in a separate issue). Perhaps an easy way to do it would be calling book_node_delete($node)?

• book_node_export_dependency() outputs the property of a dependency as 'property' => array(array('book', 'bid')), while the rest of the module expects 'property' => array('book', 'bid'),. Either the rest of the module needs to be fixed, or this function.

• node_export_dependency_handle_dependency() uses if (isset($disabled_modules[$dependency['module']])) { to check for disabled modules when it should really use if (!empty($disabled_modules[$dependency['module']])) {. The disabled_modules array always contains the keys with a value of 0 for not disabled, or the key as the value if disabled.

I was trying to come up with a fix, but I don't have the time to delve into this issue much farther, so at least I'll share what I've found so far.

We 've changed the patch so that the weight of a book page is exported correctly.

• book_node_export_dependency() outputs the property of a dependency as 'property' => array(array('book', 'bid')), while the rest of the module expects 'property' => array('book', 'bid'),. Either the rest of the module needs to be fixed, or this function.

Is this actually causing any problems? The module does in fact expect array(array()), but will accept array() for simplification/backward compatibility.

• node_export_dependency_handle_dependency() uses if (isset($disabled_modules[$dependency['module']])) { to check for disabled modules when it should really use if (!empty($disabled_modules[$dependency['module']])) {. The disabled_modules array always contains the keys with a value of 0 for not disabled, or the key as the value if disabled.

I've made that change now.

Book module keeps track of book nodes through menu links (mlid). However, when Node Export imports an existing node it gives it a new mlid, resulting in multiple menu items. It should delete the old menu if it's going to create a new one (the same goes for regular menu items, btw, but that might have to be addressed in a separate issue). Perhaps an easy way to do it would be calling book_node_delete($node)?

This is only the case if your imports create a duplicate node. Supporting dependencies to a duplicated node is not yet supported, as shown in the settings, so I consider that covered for now. Unless I've misunderstood what you mean?

Patch from #39 is malformed. Fixed that up and a couple of variable reference errors.

If you guys want to maintain node_export_book, may I suggest starting a sandbox or project for this purpose? You will be able to properly deal with it that way.

This saved my life!

Unfortunately I had to bring back an old backup in order to repeat the export using this module because the book I exported previously with "book_export" alone missed the structure: this is a big missing thing! Anyone using a book use it for the hierarchy things... the node_export reference book a lot of time and people would expect it to be able to export/import the whole book correctly.

So this module should be included in node_export or at least the module should make it clear that it will loose the hierarchy.

I open it because I don't see yet a separate module and anyway I think something should be at least documented on the main module, so let's use this issue to keep track of this.

There definitely should be amessage to say this doesn't work with books.

It even actually says this on the project page:

Supports: authors, translated content, books, organic groups, taxonomy term reference, file, image, node reference, user reference, entity reference, and field collection.

This says that books are supported, when they are not properly supported.

To the people who have worked on this patch, do any of you want to post and support this as a separate project?
If not I will make a project out of it if it cannot go in this module.

OK I added node export book