2001-03-24 16:36:13 +00:00
<?php
2001-10-20 18:57:09 +00:00
// $Id$
2001-03-24 16:36:13 +00:00
2004-08-21 06:42:38 +00:00
/**
* @file
* Allows users to collaboratively author a book.
*/
2004-05-09 19:28:43 +00:00
/**
2005-08-29 19:58:49 +00:00
* Implementation of hook_node_info().
2004-05-09 19:28:43 +00:00
*/
2005-08-29 19:58:49 +00:00
function book_node_info() {
- Patch #29785 by Chx: multiple node types were broken so we refactored
part of the node system! If you have a module that implements node
types, you'll have to udpate its CVS HEAD version.
We replaced _node_name() and _node_types() by _node(). The new _node()
hook let's you define one or more node types, including their names.
The implementation of the _node() hook needs to:
return array($type1 => array('name' => $name1, 'base' => $base1),
$type2 => array('name' => $name2, 'base' => $base2));
where $type is the node type, $name is the human readable name of the type
and $base is used instead of <hook> for <hook>_load, <hook>_view, etc.
For example, the story module's node hook looks like this:
function story_node() {
return array('story' => array('name' => t('story'), 'base' => 'story'));
}
The page module's node hook module like:
function page_node() {
return array('page' => array('name' => t('page'), 'base' => 'page'));
}
However, more complex node modules like the project module and the
flexinode module can use the 'base' parameter to specify a different base.
The project module implements two node types, proejcts and issues, so it
can do:
function project_node() {
return array(
array('project_project' => array('name' => t('project'), 'base' => 'project'),
array('project_issue' => array('name' => t('issue'), 'base' => 'project_issue'));
}
In the flexinode module's case there can only one base ...
This hook will simplify the CCK, and will make it easy (or easier) to merge
the story and page module.
In addition, node_list() became node_get_types(). In addition, we created
the following functions: node_get_name($type) and node_get_base($type).
2005-08-28 15:29:34 +00:00
return array('book' => array('name' => t('book page'), 'base' => 'book'));
2001-11-01 17:04:20 +00:00
}
2004-05-09 19:28:43 +00:00
/**
* Implementation of hook_perm().
*/
2002-12-10 20:35:20 +00:00
function book_perm() {
2006-02-14 19:25:02 +00:00
return array('outline posts in books', 'create book pages', 'create new books', 'edit book pages', 'edit own book pages', 'see printer-friendly version');
2002-12-10 20:35:20 +00:00
}
2004-05-09 19:28:43 +00:00
/**
* Implementation of hook_access().
*/
2001-11-01 17:04:20 +00:00
function book_access($op, $node) {
2001-11-04 23:30:39 +00:00
global $user;
2001-11-01 17:04:20 +00:00
2004-05-09 19:28:43 +00:00
if ($op == 'create') {
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
// Only registered users can create book pages. Given the nature
// of the book module this is considered to be a good/safe idea.
2004-11-04 22:31:46 +00:00
return user_access('create book pages');
2001-11-01 17:04:20 +00:00
}
2004-05-09 19:28:43 +00:00
if ($op == 'update') {
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
// Only registered users can update book pages. Given the nature
// of the book module this is considered to be a good/safe idea.
// One can only update a book page if there are no suggested updates
2004-12-22 20:47:47 +00:00
// of that page waiting for approval. That is, only updates that
// don't overwrite the current or pending information are allowed.
The Input formats - filter patch has landed. I still need to make update instructions for modules and update the hook docs.
Here's an overview of the changes:
1) Multiple Input formats: they are complete filter configurations (what filters to use, in what order and with which settings). Input formats are admin-definable, and usage of them is role-dependant. For example, you can set it up so that regular users can only use limited HTML, while admins can free HTML without any tag limitations.
The input format can be chosen per content item (nodes, comments, blocks, ...) when you add/edit them. If only a single format is available, there is no choice, and nothing changes with before.
The default install (and the upgrade) contains a basic set of formats which should satisfy the average user's needs.
2) Filters have toggles
Because now you might want to enable a filter only on some input formats, an explicit toggle is provided by the filter system. Modules do not need to worry about it and filters that still have their own on/off switch should get rid of it.
3) Multiple filters per module
This was necessary to accomodate the next change, and it's also a logical extension of the filter system.
4) Embedded PHP is now a filter
Thanks to the multiple input formats, I was able to move the 'embedded PHP' feature from block.module, page.module and book.module into a simple filter which executes PHP code. This filter is part of filter.module, and by default there is an input format 'PHP', restricted to the administrator only, which contains this filter.
This change means that block.module now passes custom block contents through the filter system.
As well as from reducing code duplication and avoiding two type selectors for page/book nodes, you can now combine PHP code with other filters.
5) User-supplied PHP code now requires <?php ?> tags.
This is required for teasers to work with PHP code. Because PHP evaluation is now just another step in the filter process, we can't do this. Also, because teasers are generated before filtering, this would result in errors when the teaser generation would cut off a piece of PHP code.
Also, regular PHP syntax explicitly includes the <?php ?> tags for PHP files, so it makes sense to use the same convention for embedded PHP in Drupal.
6) Filter caching was added.
Benchmarking shows that even for a simple setup (basic html filtering + legacy URL rewriting), filtercache can offer speedups. Unlike the old filtercache, this uses the normal cache table.
7) Filtertips were moved from help into a hook_filter_tips(). This was required to accomodate the fact that there are multiple filters per module, and that filter settings are format dependant. Shoehorning filter tips into _help was ugly and silly. The display of the filter tips is done through the input format selector, so filter_tips_short() no longer exists.
8) A more intelligent linebreak convertor was added, which doesn't stop working if you use block-level tags and which adds <p> tags.
2004-08-10 18:34:29 +00:00
2006-02-14 19:25:02 +00:00
if ((user_access('edit book pages') && !$node->moderate) || ($node->uid == $user->uid && user_access('edit own book pages'))) {
2005-02-06 09:37:10 +00:00
return TRUE;
}
else {
// do nothing. node-access() will determine further access
}
2001-11-04 15:57:43 +00:00
}
2001-11-01 17:04:20 +00:00
}
2004-04-21 13:56:38 +00:00
/**
* Implementation of hook_link().
*/
2001-12-02 21:11:18 +00:00
function book_link($type, $node = 0, $main = 0) {
2003-04-21 14:55:03 +00:00
$links = array();
2005-04-13 18:50:57 +00:00
if ($type == 'node' && isset($node->parent)) {
2003-05-13 19:05:02 +00:00
if (!$main) {
2004-11-15 12:49:59 +00:00
if (book_access('create', $node)) {
$links[] = l(t('add child page'), "node/add/book/parent/$node->nid");
}
2005-10-08 14:48:33 +00:00
if (user_access('see printer-friendly version')) {
2005-11-30 13:16:53 +00:00
$links[] = l(t('printer-friendly version'),
'book/export/html/'. $node->nid,
array('title' => t('Show a printer-friendly version of this book page and its sub-pages.')));
2005-10-08 14:48:33 +00:00
}
2003-05-13 19:05:02 +00:00
}
2001-12-02 21:05:31 +00:00
}
2003-04-21 14:55:03 +00:00
return $links;
2001-03-25 10:57:01 +00:00
}
2004-06-18 15:04:37 +00:00
/**
* Implementation of hook_menu().
*/
2004-09-16 07:17:56 +00:00
function book_menu($may_cache) {
2004-06-18 15:04:37 +00:00
$items = array();
2004-09-16 07:17:56 +00:00
if ($may_cache) {
2005-06-07 19:20:20 +00:00
$items[] = array(
'path' => 'book',
'title' => t('books'),
'access' => user_access('access content'),
'type' => MENU_NORMAL_ITEM,
'weight' => 5);
$items[] = array(
'path' => 'node/add/book',
'title' => t('book page'),
2004-11-04 22:31:46 +00:00
'access' => user_access('create book pages'));
2005-06-07 19:20:20 +00:00
$items[] = array(
'path' => 'admin/node/book',
'title' => t('books'),
2004-09-16 07:17:56 +00:00
'callback' => 'book_admin',
'access' => user_access('administer nodes'),
2005-07-29 03:49:16 +00:00
'type' => MENU_LOCAL_TASK,
'weight' => -1);
$items[] = array(
'path' => 'admin/node/book/list',
'title' => t('list'),
'type' => MENU_DEFAULT_LOCAL_TASK);
2005-06-07 19:20:20 +00:00
$items[] = array(
'path' => 'admin/node/book/orphan',
'title' => t('orphan pages'),
2004-09-16 07:17:56 +00:00
'callback' => 'book_admin_orphan',
2005-07-29 03:49:16 +00:00
'type' => MENU_LOCAL_TASK,
2004-09-16 07:17:56 +00:00
'weight' => 8);
2005-11-30 13:16:53 +00:00
$items[] = array(
'path' => 'book',
'title' => t('books'),
2004-09-16 07:17:56 +00:00
'callback' => 'book_render',
'access' => user_access('access content'),
'type' => MENU_SUGGESTED_ITEM);
2005-06-05 10:52:04 +00:00
$items[] = array(
2005-06-07 19:20:20 +00:00
'path' => 'book/export',
'callback' => 'book_export',
2005-11-30 13:16:53 +00:00
'access' => user_access('access content'),
2004-09-16 07:17:56 +00:00
'type' => MENU_CALLBACK);
2004-06-18 15:04:37 +00:00
}
2004-10-08 11:17:59 +00:00
else {
// To avoid SQL overhead, check whether we are on a node page and whether the
2006-02-14 19:25:02 +00:00
// user is allowed to outline posts in books.
if (arg(0) == 'node' && is_numeric(arg(1)) && user_access('outline posts in books')) {
2004-10-08 11:17:59 +00:00
// Only add the outline-tab for non-book pages:
2005-01-29 22:02:37 +00:00
$result = db_query(db_rewrite_sql("SELECT n.nid FROM {node} n WHERE n.nid = %d AND n.type != 'book'"), arg(1));
2004-10-08 11:17:59 +00:00
if (db_num_rows($result) > 0) {
2005-11-30 13:16:53 +00:00
$items[] = array(
'path' => 'node/'. arg(1) .'/outline',
'title' => t('outline'),
'callback' => 'book_outline',
2006-02-14 19:25:02 +00:00
'access' => user_access('outline posts in books'),
2005-11-30 13:16:53 +00:00
'type' => MENU_LOCAL_TASK,
'weight' => 2);
2004-10-08 11:17:59 +00:00
}
}
}
2004-06-18 15:04:37 +00:00
return $items;
}
2004-05-09 19:28:43 +00:00
/**
* Implementation of hook_block().
*
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
* Displays the book table of contents in a block when the current page is a
* single-node view of a book node.
2004-05-09 19:28:43 +00:00
*/
2004-01-14 19:26:41 +00:00
function book_block($op = 'list', $delta = 0) {
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
$block = array();
2004-01-14 19:26:41 +00:00
if ($op == 'list') {
$block[0]['info'] = t('Book navigation');
2004-10-31 07:34:47 +00:00
return $block;
2004-01-14 19:26:41 +00:00
}
2004-10-31 07:34:47 +00:00
else if ($op == 'view') {
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
// Only display this block when the user is browsing a book:
if (arg(0) == 'node' && is_numeric(arg(1))) {
2005-08-30 15:22:29 +00:00
$result = db_query(db_rewrite_sql('SELECT n.nid, n.title, b.parent FROM {node} n INNER JOIN {book} b ON n.vid = b.vid WHERE n.nid = %d'), arg(1));
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
if (db_num_rows($result) > 0) {
$node = db_fetch_object($result);
$path = book_location($node);
$path[] = $node;
$expand = array();
foreach ($path as $key => $node) {
$expand[] = $node->nid;
}
2005-03-31 09:25:33 +00:00
$block['subject'] = check_plain($path[0]->title);
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
$block['content'] = book_tree($expand[0], 5, $expand);
}
}
2004-01-14 19:26:41 +00:00
2004-10-31 07:34:47 +00:00
return $block;
}
2004-01-14 19:26:41 +00:00
}
2004-05-09 19:28:43 +00:00
/**
* Implementation of hook_load().
*/
2001-11-01 11:00:51 +00:00
function book_load($node) {
2002-04-20 11:52:50 +00:00
global $user;
2001-11-24 15:10:36 +00:00
2005-08-30 15:22:29 +00:00
$book = db_fetch_object(db_query('SELECT parent, weight FROM {book} WHERE vid = %d', $node->vid));
2001-11-24 15:10:36 +00:00
2004-08-18 20:46:28 +00:00
if (arg(2) == 'edit' && !user_access('administer nodes')) {
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
// If a user is about to update a book page, we overload some
// fields to reflect the changes.
2001-11-25 15:58:08 +00:00
if ($user->uid) {
$book->uid = $user->uid;
$book->name = $user->name;
}
else {
$book->uid = 0;
2004-05-09 19:28:43 +00:00
$book->name = '';
2001-11-25 15:58:08 +00:00
}
2001-12-06 17:33:05 +00:00
}
2001-11-24 15:10:36 +00:00
2001-11-01 11:00:51 +00:00
return $book;
2001-06-29 22:08:57 +00:00
}
2004-05-09 19:28:43 +00:00
/**
* Implementation of hook_insert().
*/
2001-11-01 11:00:51 +00:00
function book_insert($node) {
2005-08-30 15:22:29 +00:00
db_query("INSERT INTO {book} (nid, vid, parent, weight) VALUES (%d, %d, %d, %d)", $node->nid, $node->vid, $node->parent, $node->weight);
2001-11-01 11:00:51 +00:00
}
2001-06-29 22:08:57 +00:00
2004-05-09 19:28:43 +00:00
/**
* Implementation of hook_update().
*/
2001-11-01 11:00:51 +00:00
function book_update($node) {
2005-08-30 15:22:29 +00:00
if ($node->revision) {
2005-09-06 18:55:41 +00:00
db_query("INSERT INTO {book} (nid, vid, parent, weight) VALUES (%d, %d, %d, %d)", $node->nid, $node->vid, $node->parent, $node->weight);
2005-08-30 15:22:29 +00:00
}
else {
db_query("UPDATE {book} SET parent = %d, weight = %d WHERE vid = %d", $node->parent, $node->weight, $node->vid);
}
2001-11-01 11:00:51 +00:00
}
2001-06-29 22:08:57 +00:00
2004-05-09 19:28:43 +00:00
/**
* Implementation of hook_delete().
*/
2001-11-26 18:27:34 +00:00
function book_delete(&$node) {
2004-05-09 19:28:43 +00:00
db_query('DELETE FROM {book} WHERE nid = %d', $node->nid);
2001-06-20 20:00:40 +00:00
}
2004-05-09 19:28:43 +00:00
/**
2005-12-02 15:21:01 +00:00
* Implementation of hook_submit().
2004-05-09 19:28:43 +00:00
*/
2005-12-02 15:21:01 +00:00
function book_submit(&$node) {
2004-05-09 19:28:43 +00:00
// Set default values for non-administrators.
if (!user_access('administer nodes')) {
2003-03-07 22:11:44 +00:00
$node->weight = 0;
$node->revision = 1;
}
2005-11-12 02:54:13 +00:00
}
2005-09-23 08:47:13 +00:00
2005-11-12 02:54:13 +00:00
/**
* Implementation of hook_validate().
*/
function book_validate($node) {
2005-09-23 08:47:13 +00:00
node_validate_title($node);
2002-11-18 22:19:17 +00:00
}
2004-05-09 19:28:43 +00:00
/**
* Implementation of hook_form().
*/
2004-07-04 16:50:02 +00:00
function book_form(&$node) {
2006-02-14 19:25:02 +00:00
$form['parent'] =
array(
'#type' => 'select',
'#title' => t('Parent'),
'#default_value' => ($node->parent ? $node->parent : arg(4)),
'#options' => book_toc($node->nid),
'#weight' => -4,
'#description' =>
user_access('create new books') ?
t('The parent section in which to place this page. Note that each page whose parent is <top-level> is an independent, top-level book.') :
t('The parent that this page belongs in.')
);
2001-12-06 17:33:05 +00:00
2006-01-18 19:29:17 +00:00
$form['title'] = array('#type' => 'textfield', '#title' => t('Title'), '#required' => TRUE, '#default_value' => $node->title, '#weight' => -5);
2006-01-19 08:54:41 +00:00
$form['body_filter']['body'] = array('#type' => 'textarea', '#title' => t('Body'), '#default_value' => $node->body, '#rows' => 20, '#required' => TRUE);
- Patch #45530 by Morbus: filter_form shouldn't default to #weight 0
When a form element doesn't specify a #weight, it is assumed internally as #weight 0. However, to ensure that our form elements display visually *as they were defined in the array* we, in form_builder, count the number of elements, divide by 1000, and set that as the weight:
# Assign a decimal placeholder weight to preserve original array order
if (!isset($form[$key]['#weight'])) {
$form[$key]['#weight'] = $count/1000;
}
The above code will set the #weights of elements that have not defined a weight to something like 0 (first element in array definition), 0.001, 0.002, and so on. However, anytime a form element *explicitly* defines a #weight of 0, that #weight is kept at exactly 0, which would cause that form element to appear BEFORE the elements that didn't have a #weight defined (and thus received a #weight such as 0.002).
Consider the following pseudo example:
$form['game_title'] = array(
'#type' => 'textfield',
...
);
$form['game_description'] = array(
'#type' => 'textarea',
...
);
$form['game_format'] = filter_form(variable_get('game_format', NULL));
return $form;
Here, we're not definiing weights on our two textfields. We then add an filter_form. The second parameter of the filter_form is $weight, which defaults to 0. After this $form hits form_builder, we have weights 0 (game_title), 0.001 (game_description), and 0 (filter_form) respectively. This is then sorted by weight, which causes filter_form (the third element in the array) to appear BEFORE game_description (0 is lighter than 0.001).
The short lesson is: explicitly defining #weight 0 for a form element is probably a bad idea. This patch changes the default #weight of filter_form to NULL, instead of 0, and also removes any other explicit setting of #weight to 0 in core.
2006-01-20 09:04:34 +00:00
$form['body_filter']['format'] = filter_form($node->format);
2005-08-30 15:22:29 +00:00
2005-10-07 06:11:12 +00:00
$form['log'] = array(
2005-12-15 16:24:40 +00:00
'#type' => 'textarea', '#title' => t('Log message'), '#default_value' => $node->log, '#weight' => 5,
2005-10-11 19:44:35 +00:00
'#description' => t('An explanation of the additions or updates being made to help other authors understand your motivations.')
2005-10-07 06:11:12 +00:00
);
2001-11-04 15:57:43 +00:00
2004-05-09 19:28:43 +00:00
if (user_access('administer nodes')) {
2005-10-07 06:11:12 +00:00
$form['weight'] = array(
2005-12-15 16:24:40 +00:00
'#type' => 'weight', '#title' => t('Weight'), '#default_value' => $node->weight, '#delta' => 15, '#weight' => 5,
2005-10-11 19:44:35 +00:00
'#description' => t('Pages at a given level are ordered first by weight and then by title.')
2005-10-07 06:11:12 +00:00
);
2001-11-04 15:57:43 +00:00
}
else {
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
// If a regular user updates a book page, we create a new revision
// authored by that user:
2005-10-11 19:44:35 +00:00
$form['revision'] = array('#type' => 'hidden', '#value' => 1);
2001-11-04 15:57:43 +00:00
}
2005-10-07 06:11:12 +00:00
return $form;
2001-11-04 15:57:43 +00:00
}
2004-05-09 19:28:43 +00:00
/**
2004-10-08 11:17:59 +00:00
* Implementation of function book_outline()
* Handles all book outline operations.
2004-05-09 19:28:43 +00:00
*/
2004-10-08 11:17:59 +00:00
function book_outline() {
2003-05-13 18:36:38 +00:00
2004-05-09 19:28:43 +00:00
$op = $_POST['op'];
$edit = $_POST['edit'];
2005-07-17 18:29:32 +00:00
$node = node_load(arg(1));
2001-12-06 17:33:05 +00:00
2004-10-08 11:17:59 +00:00
if ($node->nid) {
switch ($op) {
case t('Add to book outline'):
2005-08-30 15:22:29 +00:00
db_query('INSERT INTO {book} (nid, vid, parent, weight) VALUES (%d, %d, %d, %d)', $node->nid, $node->vid, $edit['parent'], $edit['weight']);
db_query("UPDATE {node_revisions} SET log = '%s' WHERE vid = %d", $edit['log'], $node->vid);
2005-05-05 22:22:46 +00:00
drupal_set_message(t('The post has been added to the book.'));
2004-10-08 11:17:59 +00:00
drupal_goto("node/$node->nid");
break;
case t('Update book outline'):
2005-08-30 15:22:29 +00:00
db_query('UPDATE {book} SET parent = %d, weight = %d WHERE vid = %d', $edit['parent'], $edit['weight'], $node->vid);
db_query("UPDATE {node_revisions} SET log = '%s' WHERE vid = %d", $edit['log'], $node->vid);
2005-05-05 22:22:46 +00:00
drupal_set_message(t('The book outline has been updated.'));
2004-10-08 11:17:59 +00:00
drupal_goto("node/$node->nid");
break;
case t('Remove from book outline'):
db_query('DELETE FROM {book} WHERE nid = %d', $node->nid);
2005-05-05 22:22:46 +00:00
drupal_set_message(t('The post has been removed from the book.'));
2004-10-08 11:17:59 +00:00
drupal_goto("node/$node->nid");
break;
default:
2005-08-30 15:22:29 +00:00
$page = db_fetch_object(db_query('SELECT * FROM {book} WHERE vid = %d', $node->vid));
2005-10-07 06:51:43 +00:00
2005-10-07 06:11:12 +00:00
$form['parent'] = array(
2005-10-11 19:44:35 +00:00
'#type' => 'select', '#title' => t('Parent'), '#default_value' => $page->parent,
'#options' => book_toc($node->nid), '#description' => t('The parent page in the book.')
2005-10-07 06:11:12 +00:00
);
2005-10-07 06:51:43 +00:00
2005-10-07 06:11:12 +00:00
$form['weight'] = array(
2005-10-11 19:44:35 +00:00
'#type' => 'weight', '#title' => t('Weight'), '#default_value' => $page->weight, '#delta' => 15,
'#description' => t('Pages at a given level are ordered first by weight and then by title.')
2005-10-07 06:11:12 +00:00
);
2005-10-07 06:51:43 +00:00
2005-10-07 06:11:12 +00:00
$form['log'] = array(
2005-11-12 11:26:16 +00:00
'#type' => 'textarea', '#title' => t('Log message'),
2005-10-11 19:44:35 +00:00
'#default_value' => $node->log, '#description' => t('An explanation to help other authors understand your motivations to put this post into the book.')
2005-10-07 06:11:12 +00:00
);
2004-10-08 11:17:59 +00:00
if ($page->nid) {
2005-10-11 19:44:35 +00:00
$form['update'] = array('#type' => 'submit', '#value' => t('Update book outline'));
$form['remove'] = array('#type' => 'submit', '#value' => t('Remove from book outline'));
2004-10-08 11:17:59 +00:00
}
else {
2005-10-11 19:44:35 +00:00
$form['add'] = array('#type' => 'submit', '#value' => t('Add to book outline'));
2004-10-08 11:17:59 +00:00
}
2001-12-06 17:33:05 +00:00
2005-03-31 09:25:33 +00:00
drupal_set_title(check_plain($node->title));
2005-10-07 06:11:12 +00:00
return drupal_get_form('book_outline', $form);
2001-12-06 17:33:05 +00:00
}
}
}
2004-05-09 19:28:43 +00:00
/**
* Return the path (call stack) to a certain book page.
*/
2001-04-04 12:54:10 +00:00
function book_location($node, $nodes = array()) {
2005-08-30 15:22:29 +00:00
$parent = db_fetch_object(db_query(db_rewrite_sql('SELECT n.nid, n.title, b.parent, b.weight FROM {node} n INNER JOIN {book} b ON n.vid = b.vid WHERE n.nid = %d'), $node->parent));
2001-04-04 12:54:10 +00:00
if ($parent->title) {
$nodes = book_location($parent, $nodes);
array_push($nodes, $parent);
}
return $nodes;
}
2005-06-05 10:52:04 +00:00
/**
* Accumulates the nodes up to the root of the book from the given node in the $nodes array.
*/
2003-03-10 20:18:38 +00:00
function book_location_down($node, $nodes = array()) {
2005-07-29 07:13:25 +00:00
$last_direct_child = db_fetch_object(db_query(db_rewrite_sql('SELECT n.nid, n.title, b.parent, b.weight FROM {node} n INNER JOIN {book} b ON n.nid = b.nid WHERE n.status = 1 AND b.parent = %d ORDER BY b.weight DESC, n.title DESC'), $node->nid));
2003-03-10 20:18:38 +00:00
if ($last_direct_child) {
array_push($nodes, $last_direct_child);
$nodes = book_location_down($last_direct_child, $nodes);
}
return $nodes;
}
2004-05-09 19:28:43 +00:00
/**
2005-06-05 10:52:04 +00:00
* Fetches the node object of the previous page of the book.
2004-05-09 19:28:43 +00:00
*/
2003-03-10 20:18:38 +00:00
function book_prev($node) {
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
// If the parent is zero, we are at the start of a book so there is no previous.
2003-05-18 16:43:56 +00:00
if ($node->parent == 0) {
return NULL;
}
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
// Previous on the same level:
2005-08-30 15:22:29 +00:00
$direct_above = db_fetch_object(db_query(db_rewrite_sql("SELECT n.nid, n.title, b.weight FROM {node} n INNER JOIN {book} b ON n.vid = b.vid WHERE b.parent = %d AND n.status = 1 AND n.moderate = 0 AND (b.weight < %d OR (b.weight = %d AND n.title < '%s')) ORDER BY b.weight DESC, n.title DESC"), $node->parent, $node->weight, $node->weight, $node->title));
2003-03-10 20:18:38 +00:00
if ($direct_above) {
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
// Get last leaf of $above.
2003-03-10 20:18:38 +00:00
$path = book_location_down($direct_above);
2003-05-18 16:43:56 +00:00
return $path ? (count($path) > 0 ? array_pop($path) : NULL) : $direct_above;
2003-03-10 20:18:38 +00:00
}
else {
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
// Direct parent:
2005-08-30 15:22:29 +00:00
$prev = db_fetch_object(db_query(db_rewrite_sql('SELECT n.nid, n.title FROM {node} n INNER JOIN {book} b ON n.vid = b.vid WHERE n.nid = %d AND n.status = 1 AND n.moderate = 0'), $node->parent));
2003-03-10 20:18:38 +00:00
return $prev;
}
}
2004-05-09 19:28:43 +00:00
/**
2005-06-05 10:52:04 +00:00
* Fetches the node object of the next page of the book.
2004-05-09 19:28:43 +00:00
*/
2003-03-10 20:18:38 +00:00
function book_next($node) {
// get first direct child
2005-08-30 15:22:29 +00:00
$child = db_fetch_object(db_query(db_rewrite_sql('SELECT n.nid, n.title, b.weight FROM {node} n INNER JOIN {book} b ON n.vid = b.vid WHERE b.parent = %d AND n.status = 1 AND n.moderate = 0 ORDER BY b.weight ASC, n.title ASC'), $node->nid));
2003-03-10 20:18:38 +00:00
if ($child) {
return $child;
}
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
// No direct child: get next for this level or any parent in this book.
array_push($path = book_location($node), $node); // Path to top-level node including this one.
2004-04-24 16:31:54 +00:00
Patch by Ax:
- the index link ("View this book's table of contents.") which pointed
to http://drupal/book instead of to ... this book's table of contents.
- it doesn't print "previous", "next", "up", "index" if there are no
"previous", "next", "up", "index"
- it doesn't print "index" if "up" /is/ the "index"
- it swaps the order of "up" and "index", ie. "up" is in the row above
"index", between "previous" and "next" now. this is more logical and the
way all tree-browsing apps (python doc, info, ...) do it.
2003-03-13 20:09:47 +00:00
while (($leaf = array_pop($path)) && count($path)) {
2005-08-30 15:22:29 +00:00
$next = db_fetch_object(db_query(db_rewrite_sql("SELECT n.nid, n.title, b.weight FROM {node} n INNER JOIN {book} b ON n.vid = b.vid WHERE b.parent = %d AND n.status = 1 AND n.moderate = 0 AND (b.weight > %d OR (b.weight = %d AND n.title > '%s')) ORDER BY b.weight ASC, n.title ASC"), $leaf->parent, $leaf->weight, $leaf->weight, $leaf->title));
2003-03-10 20:18:38 +00:00
if ($next) {
return $next;
}
}
}
2005-06-05 10:52:04 +00:00
/**
* Returns the content of a given node. If $teaser if true, returns
* the teaser rather than full content. Displays the most recently
* approved revision of a node (if any) unless we have to display this
* page in the context of the moderation queue.
*/
2004-06-18 15:04:37 +00:00
function book_content($node, $teaser = FALSE) {
2006-02-01 14:40:20 +00:00
// Return the page body.
return node_prepare($node, $teaser);
2003-09-20 15:11:41 +00:00
}
2004-05-09 19:28:43 +00:00
/**
* Implementation of hook_view().
*
* If not displayed on the main page, we render the node as a page in the
* book with extra links to the previous and next pages.
*/
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
function book_view(&$node, $teaser = FALSE, $page = FALSE) {
2006-02-01 14:40:20 +00:00
$node = node_prepare($node, $teaser);
2003-09-15 15:58:20 +00:00
}
2004-05-09 19:28:43 +00:00
/**
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
* Implementation of hook_nodeapi().
*
* Appends book navigation to all nodes in the book.
2004-05-09 19:28:43 +00:00
*/
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
function book_nodeapi(&$node, $op, $teaser, $page) {
switch ($op) {
case 'view':
if (!$teaser) {
2005-08-30 15:22:29 +00:00
$book = db_fetch_array(db_query('SELECT * FROM {book} WHERE vid = %d', $node->vid));
2003-09-20 15:11:41 +00:00
if ($book) {
2005-02-06 09:37:10 +00:00
if ($node->moderate && user_access('administer nodes')) {
2005-05-05 22:22:46 +00:00
drupal_set_message(t("The post has been submitted for moderation and won't be accessible until it has been approved."));
2005-02-06 09:37:10 +00:00
}
2003-09-20 15:11:41 +00:00
foreach ($book as $key => $value) {
$node->$key = $value;
}
2005-10-23 18:08:06 +00:00
$path = book_location($node);
// Construct the breadcrumb:
$node->breadcrumb = array(); // Overwrite the trail with a book trail.
foreach ($path as $level) {
$node->breadcrumb[] = array('path' => 'node/'. $level->nid, 'title' => $level->title);
}
$node->breadcrumb[] = array('path' => 'node/'. $node->nid);
$node->body .= theme('book_navigation', $node);
2004-07-31 16:23:01 +00:00
if ($page) {
menu_set_location($node->breadcrumb);
}
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
}
2003-09-20 15:11:41 +00:00
}
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
break;
2005-12-31 13:04:40 +00:00
case 'delete revision':
2005-12-05 16:07:18 +00:00
db_query('DELETE FROM {book} WHERE vid = %d', $node->vid);
break;
2003-11-25 19:26:21 +00:00
}
2003-09-15 15:58:20 +00:00
}
2001-12-06 17:33:05 +00:00
2004-05-09 19:28:43 +00:00
/**
* Prepares both the custom breadcrumb trail and the forward/backward
* navigation for a node presented as a book page.
2005-03-22 18:34:20 +00:00
*
* @ingroup themeable
2004-05-09 19:28:43 +00:00
*/
2005-03-22 18:34:20 +00:00
function theme_book_navigation($node) {
2006-01-27 18:57:13 +00:00
$output = '';
2004-01-17 23:34:11 +00:00
if ($node->nid) {
2006-02-09 07:27:11 +00:00
$tree = book_tree($node->nid);
2003-09-20 15:11:41 +00:00
2004-01-17 23:34:11 +00:00
if ($prev = book_prev($node)) {
2005-11-24 19:24:38 +00:00
drupal_add_link(array('rel' => 'prev', 'href' => url('node/'. $prev->nid)));
2006-02-09 07:27:11 +00:00
$links .= l(t('‹ ') . $prev->title, 'node/'. $prev->nid, array('class' => 'page-previous', 'title' => t('Go to previous page')));
2004-01-17 23:34:11 +00:00
}
2006-01-27 18:57:13 +00:00
if ($node->parent) {
drupal_add_link(array('rel' => 'index', 'href' => url('node/'. $node->parent)));
$links .= l(t('up'), 'node/'. $node->parent, array('class' => 'page-up', 'title' => t('Go to parent page')));
2004-01-17 23:34:11 +00:00
}
if ($next = book_next($node)) {
2005-11-24 19:24:38 +00:00
drupal_add_link(array('rel' => 'next', 'href' => url('node/'. $next->nid)));
2006-02-09 07:27:11 +00:00
$links .= l($next->title . t(' › '), 'node/'. $next->nid, array('class' => 'page-next', 'title' => t('Go to next page')));
2004-01-17 23:34:11 +00:00
}
2004-01-14 19:26:41 +00:00
2006-02-09 07:27:11 +00:00
if (isset($tree) || isset($links)) {
$output = '<div class="book-navigation">';
if (isset($tree)) {
$output .= $tree;
}
if (isset($links)) {
$output .= '<div class="page-links">'. $links .'</div>';
}
$output .= '</div>';
}
2004-01-17 23:34:11 +00:00
}
2004-01-14 19:26:41 +00:00
2005-10-23 18:08:06 +00:00
return $output;
2003-09-20 15:11:41 +00:00
}
2001-03-24 16:36:13 +00:00
2005-06-05 10:52:04 +00:00
/**
* This is a helper function for book_toc().
*/
2004-08-10 14:16:01 +00:00
function book_toc_recurse($nid, $indent, $toc, $children, $exclude) {
2001-12-17 19:45:47 +00:00
if ($children[$nid]) {
foreach ($children[$nid] as $foo => $node) {
2004-08-10 14:16:01 +00:00
if (!$exclude || $exclude != $node->nid) {
$toc[$node->nid] = $indent .' '. $node->title;
$toc = book_toc_recurse($node->nid, $indent .'--', $toc, $children, $exclude);
}
2001-12-17 19:45:47 +00:00
}
}
return $toc;
}
2005-06-05 10:52:04 +00:00
/**
* Returns an array of titles and nid entries of book pages in table of contents order.
*/
2004-08-10 14:32:09 +00:00
function book_toc($exclude = 0) {
2005-08-30 15:22:29 +00:00
$result = db_query(db_rewrite_sql('SELECT n.nid, n.title, b.parent, b.weight FROM {node} n INNER JOIN {book} b ON n.vid = b.vid WHERE n.status = 1 ORDER BY b.weight, n.title'));
2001-11-04 15:57:43 +00:00
2001-12-17 19:45:47 +00:00
while ($node = db_fetch_object($result)) {
2003-11-23 12:13:08 +00:00
if (!$children[$node->parent]) {
$children[$node->parent] = array();
}
array_push($children[$node->parent], $node);
2001-12-17 19:45:47 +00:00
}
2001-11-04 15:57:43 +00:00
2004-08-24 03:22:26 +00:00
$toc = array();
2006-02-14 19:25:02 +00:00
// If the user has permission to create new books, add the top-level book page to the menu;
if (user_access('create new books')) {
2004-05-09 19:28:43 +00:00
$toc[0] = '<'. t('top-level') .'>';
2001-05-07 18:44:40 +00:00
}
2004-08-24 03:22:26 +00:00
$toc = book_toc_recurse(0, '', $toc, $children, $exclude);
2001-05-06 19:51:14 +00:00
2001-03-25 16:42:52 +00:00
return $toc;
}
2005-06-05 10:52:04 +00:00
/**
* This is a helper function for book_tree()
*/
2004-01-14 19:26:41 +00:00
function book_tree_recurse($nid, $depth, $children, $unfold = array()) {
2002-01-01 11:26:29 +00:00
if ($depth > 0) {
2001-12-30 16:16:38 +00:00
if ($children[$nid]) {
foreach ($children[$nid] as $foo => $node) {
2004-01-14 19:26:41 +00:00
if (in_array($node->nid, $unfold)) {
if ($tree = book_tree_recurse($node->nid, $depth - 1, $children, $unfold)) {
$output .= '<li class="expanded">';
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
$output .= l($node->title, 'node/'. $node->nid);
2006-01-24 08:22:12 +00:00
$output .= '<ul class="menu">'. $tree .'</ul>';
2004-01-14 19:26:41 +00:00
$output .= '</li>';
}
else {
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
$output .= '<li class="leaf">'. l($node->title, 'node/'. $node->nid) .'</li>';
2004-01-14 19:26:41 +00:00
}
}
else {
if ($tree = book_tree_recurse($node->nid, 1, $children)) {
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
$output .= '<li class="collapsed">'. l($node->title, 'node/'. $node->nid) .'</li>';
2004-01-14 19:26:41 +00:00
}
else {
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
$output .= '<li class="leaf">'. l($node->title, 'node/'. $node->nid) .'</li>';
2004-01-14 19:26:41 +00:00
}
2002-01-01 11:26:29 +00:00
}
2001-12-27 15:20:20 +00:00
}
}
2001-12-30 16:16:38 +00:00
}
return $output;
}
2005-06-05 10:52:04 +00:00
/**
* Returns an HTML nested list (wrapped in a menu-class div) representing the book nodes
* as a tree.
*/
2004-01-14 19:26:41 +00:00
function book_tree($parent = 0, $depth = 3, $unfold = array()) {
2005-08-30 15:22:29 +00:00
$result = db_query(db_rewrite_sql('SELECT n.nid, n.title, b.parent, b.weight FROM {node} n INNER JOIN {book} b ON n.vid = b.vid WHERE n.status = 1 AND n.moderate = 0 ORDER BY b.weight, n.title'));
2001-11-04 23:30:39 +00:00
2001-12-30 16:16:38 +00:00
while ($node = db_fetch_object($result)) {
$list = $children[$node->parent] ? $children[$node->parent] : array();
array_push($list, $node);
$children[$node->parent] = $list;
2001-05-06 19:51:14 +00:00
}
2002-01-01 11:26:29 +00:00
2004-01-14 19:26:41 +00:00
if ($tree = book_tree_recurse($parent, $depth, $children, $unfold)) {
2006-01-22 07:32:55 +00:00
return '<ul class="menu">'. $tree .'</ul>';
2004-01-14 19:26:41 +00:00
}
2001-05-06 19:51:14 +00:00
}
2004-05-09 19:28:43 +00:00
/**
2004-05-17 22:00:06 +00:00
* Menu callback; prints a listing of all books.
2004-05-09 19:28:43 +00:00
*/
2001-07-15 17:32:33 +00:00
function book_render() {
2005-08-30 15:22:29 +00:00
$result = db_query(db_rewrite_sql('SELECT n.nid, n.title, b.weight FROM {node} n INNER JOIN {book} b ON n.vid = b.vid WHERE b.parent = 0 AND n.status = 1 AND n.moderate = 0 ORDER BY b.weight, n.title'));
2001-11-04 23:30:39 +00:00
2005-06-07 08:30:16 +00:00
$books = array();
while ($node = db_fetch_object($result)) {
$books[] = l($node->title, 'node/'. $node->nid);
}
return theme('item_list', $books);
2001-07-15 17:32:33 +00:00
}
2004-05-09 19:28:43 +00:00
/**
2005-06-07 19:20:20 +00:00
* Menu callback; Generates various representation of a book page with
* all descendants and prints the requested representation to output.
*
2005-11-30 13:16:53 +00:00
* The function delegates the generation of output to helper functions.
* The function name is derived by prepending 'book_export_' to the
* given output type. So, e.g., a type of 'html' results in a call to
* the function book_export_html().
2005-06-07 19:20:20 +00:00
*
* @param type
* - a string encoding the type of output requested.
2005-11-30 13:16:53 +00:00
* The following types are currently supported in book module
* html: HTML (printer friendly output)
* Other types are supported in contributed modules.
2005-06-07 19:20:20 +00:00
* @param nid
* - an integer representing the node id (nid) of the node to export
*
2004-05-09 19:28:43 +00:00
*/
2005-11-30 13:16:53 +00:00
function book_export($type = 'html', $nid = 0) {
2005-07-25 20:40:35 +00:00
$type = drupal_strtolower($type);
2005-11-30 13:16:53 +00:00
$depth = _book_get_depth($nid);
$export_function = 'book_export_' . $type;
if (function_exists($export_function)) {
print call_user_func($export_function, $nid, $depth);
2005-09-29 21:56:12 +00:00
}
else {
2005-11-30 13:16:53 +00:00
drupal_set_message('Unknown export format');
2005-09-29 21:56:12 +00:00
drupal_not_found();
2005-06-07 19:20:20 +00:00
}
2005-06-05 10:52:04 +00:00
}
2001-08-11 14:54:39 +00:00
2005-11-30 13:16:53 +00:00
/**
* This function is called by book_export() to generate HTML for export.
*
* The given node is /embedded to its absolute depth in a top level
* section/. For example, a child node with depth 2 in the hierarchy
* is contained in (otherwise empty) <div> elements
* corresponding to depth 0 and depth 1. This is intended to support
* WYSIWYG output - e.g., level 3 sections always look like level 3
* sections, no matter their depth relative to the node selected to be
* exported as printer-friendly HTML.
*
* @param nid
* - an integer representing the node id (nid) of the node to export
* @param depth
* - an integer giving the depth in the book hierarchy of the node
which is to be exported
* @return
* - string containing HTML representing the node and its children in
the book hierarchy
*/
function book_export_html($nid, $depth) {
if (user_access('see printer-friendly version')) {
global $base_url;
for ($i = 1; $i < $depth; $i++) {
$output .= "<div class=\"section-$i\">\n";
}
$output .= book_recurse($nid, $depth, 'book_node_visitor_html_pre', 'book_node_visitor_html_post');
for ($i = 1; $i < $depth; $i++) {
$output .= "</div>\n";
}
$html = "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n";
$html .= '<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">';
$html .= "<head>\n<title>". check_plain($node->title) ."</title>\n";
$html .= '<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />';
$html .= '<base href="'. $base_url .'/" />' . "\n";
$html .= "<style type=\"text/css\">\n@import url(misc/print.css);\n</style>\n";
$html .= "</head>\n<body>\n". $output . "\n</body>\n</html>\n";
return $html;
}
else {
drupal_access_denied();
}
}
2005-10-23 18:08:06 +00:00
/**
* How the book's HTML export should be themed
*
* @ingroup themeable
*/
function theme_book_export_html($title, $content) {
global $base_url;
$html = "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n";
$html .= '<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">';
$html .= "<head>\n<title>". $title ."</title>\n";
$html .= '<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />';
$html .= '<base href="'. $base_url .'/" />' . "\n";
$html .= "<style type=\"text/css\">\n@import url(misc/print.css);\n</style>\n";
$html .= "</head>\n<body>\n". $content . "\n</body>\n</html>\n";
return $html;
}
2005-06-05 10:52:04 +00:00
/**
2005-06-07 19:20:20 +00:00
* Given a node, this function returns the depth of the node in its hierarchy.
* A root node has depth 1, and children of a node of depth n have depth (n+1).
*
2005-11-30 13:16:53 +00:00
* @param nid
* - the nid of the node whose depth to compute.
2005-06-07 19:20:20 +00:00
* @return
* - the depth of the given node in its hierarchy. Returns 0 if the node
* does not exist or is not part of a book hierarchy.
2005-06-05 10:52:04 +00:00
*/
2005-06-07 19:20:20 +00:00
function _book_get_depth($nid) {
$depth = 0;
if ($nid) {
while ($nid) {
$result = db_query(db_rewrite_sql('SELECT b.parent FROM {book} b WHERE b.nid = %d'), $nid);
$obj = db_fetch_object($result);
$parent = $obj->parent;
if ($nid == $parent->parent) {
$nid = 0;
}
else {
$nid = $parent;
}
$depth++;
}
return $depth;
}
else {
return 0;
}
2001-08-11 14:54:39 +00:00
}
2005-06-05 10:52:04 +00:00
/**
* Traverses the book tree. Applies the $visit_pre() callback to each
* node, is called recursively for each child of the node (in weight,
* title order). Finally appends the output of the $visit_post()
* callback to the output before returning the generated output.
*
* @param nid
* - the node id (nid) of the root node of the book hierarchy.
* @param depth
* - the depth of the given node in the book hierarchy.
* @param visit_pre
* - a function callback to be called upon visiting a node in the tree
* @param visit_post
* - a function callback to be called after visiting a node in the tree,
* but before recursively visiting children.
* @return
* - the output generated in visiting each node
*/
function book_recurse($nid = 0, $depth = 1, $visit_pre, $visit_post) {
2005-08-30 15:22:29 +00:00
$result = db_query(db_rewrite_sql('SELECT n.nid, n.title, b.weight FROM {node} n INNER JOIN {book} b ON n.vid = b.vid WHERE n.status = 1 AND n.nid = %d AND n.moderate = 0 ORDER BY b.weight, n.title'), $nid);
2001-11-04 23:30:39 +00:00
while ($page = db_fetch_object($result)) {
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
// Load the node:
2005-07-17 18:29:32 +00:00
$node = node_load($page->nid);
2001-11-04 23:30:39 +00:00
2001-11-25 09:55:00 +00:00
if ($node) {
2005-06-05 10:52:04 +00:00
if (function_exists($visit_pre)) {
$output .= call_user_func($visit_pre, $node, $depth, $nid);
2003-09-20 15:11:41 +00:00
}
2005-06-07 19:20:20 +00:00
else {
$output .= book_node_visitor_html_pre($node, $depth, $nid);
2001-11-25 09:55:00 +00:00
}
2001-11-04 23:30:39 +00:00
2005-08-30 15:22:29 +00:00
$children = db_query(db_rewrite_sql('SELECT n.nid, n.title, b.weight FROM {node} n INNER JOIN {book} b ON n.vid = b.vid WHERE n.status = 1 AND b.parent = %d AND n.moderate = 0 ORDER BY b.weight, n.title'), $node->nid);
2005-06-05 10:52:04 +00:00
while ($childpage = db_fetch_object($children)) {
2005-07-17 18:29:32 +00:00
$childnode = node_load($childpage->nid);
2005-06-05 10:52:04 +00:00
if ($childnode->nid != $node->nid) {
2005-11-30 13:16:53 +00:00
$output .= book_recurse($childnode->nid, $depth + 1, $visit_pre, $visit_post);
2005-06-05 10:52:04 +00:00
}
}
if (function_exists($visit_post)) {
2005-06-07 19:20:20 +00:00
$output .= call_user_func($visit_post, $node, $depth);
2005-06-05 10:52:04 +00:00
}
2005-11-30 13:16:53 +00:00
else {
# default
2005-06-07 19:20:20 +00:00
$output .= book_node_visitor_html_post($node, $depth);
2005-06-05 10:52:04 +00:00
}
2001-11-25 09:55:00 +00:00
}
2001-04-11 19:44:24 +00:00
}
2001-06-24 19:12:30 +00:00
2001-04-11 19:44:24 +00:00
return $output;
}
2001-11-01 11:00:51 +00:00
2005-06-05 10:52:04 +00:00
/**
* Generates printer-friendly HTML for a node. This function
* is a 'pre-node' visitor function for book_recurse().
*
* @param $node
* - the node to generate output for.
* @param $depth
* - the depth of the given node in the hierarchy. This
* is used only for generating output.
* @param $nid
* - the node id (nid) of the given node. This
* is used only for generating output.
* @return
* - the HTML generated for the given node.
*/
2005-06-07 19:20:20 +00:00
function book_node_visitor_html_pre($node, $depth, $nid) {
2005-06-05 10:52:04 +00:00
// Output the content:
if (node_hook($node, 'content')) {
$node = node_invoke($node, 'content');
}
// Allow modules to change $node->body before viewing.
2005-06-07 19:20:20 +00:00
node_invoke_nodeapi($node, 'print', $node->body, false);
2005-06-05 10:52:04 +00:00
2005-06-07 19:20:20 +00:00
$output .= "<div id=\"node-". $node->nid ."\" class=\"section-$depth\">\n";
$output .= "<h1 class=\"book-heading\">". check_plain($node->title) ."</h1>\n";
2005-06-05 10:52:04 +00:00
if ($node->body) {
$output .= $node->body;
}
return $output;
}
/**
* Finishes up generation of printer-friendly HTML after visiting a
* node. This function is a 'post-node' visitor function for
* book_recurse().
*/
2005-06-07 19:20:20 +00:00
function book_node_visitor_html_post($node, $depth) {
2005-06-05 10:52:04 +00:00
return "</div>\n";
}
2005-11-23 10:22:41 +00:00
function _book_admin_table($nodes = array()) {
$form = array(
'#theme' => 'book_admin_table',
'#tree' => TRUE,
);
foreach ($nodes as $node) {
$form = array_merge($form, _book_admin_table_tree($node, 0));
}
return $form;
2005-10-07 06:11:12 +00:00
}
2005-11-23 10:22:41 +00:00
function _book_admin_table_tree($node, $depth) {
$form = array();
$form[] = array(
'nid' => array('#type' => 'value', '#value' => $node->nid),
'depth' => array('#type' => 'value', '#value' => $depth),
'title' => array(
'#type' => 'textfield',
'#default_value' => $node->title,
'#maxlength' => 255,
),
'weight' => array(
'#type' => 'weight',
'#default_value' => $node->weight,
'#delta' => 15,
),
2005-10-07 06:11:12 +00:00
);
2005-11-23 10:22:41 +00:00
$children = db_query(db_rewrite_sql('SELECT n.nid, b.weight FROM {node} n INNER JOIN {book} b ON n.vid = b.vid WHERE b.parent = %d ORDER BY b.weight, n.title'), $node->nid);
while ($child = db_fetch_object($children)) {
$form = array_merge($form, _book_admin_table_tree(node_load($child->nid), $depth + 1));
}
return $form;
2001-12-01 15:20:48 +00:00
}
2005-11-23 10:22:41 +00:00
function theme_book_admin_table($form) {
$header = array(t('Title'), t('Weight'), array('data' => t('Operations'), 'colspan' => '3'));
2001-11-18 12:30:08 +00:00
2005-06-05 10:52:04 +00:00
$rows = array();
2005-11-23 10:22:41 +00:00
foreach (element_children($form) as $key) {
$nid = $form[$key]['nid']['#value'];
$rows[] = array(
'<div style="padding-left: '. (25 * $form[$key]['depth']['#value']) .'px;">'. form_render($form[$key]['title']) .'</div>',
form_render($form[$key]['weight']),
l(t('view'), 'node/'. $nid),
l(t('edit'), 'node/'. $nid .'/edit'),
l(t('delete'), 'node/'. $nid .'/delete')
);
2001-11-18 12:30:08 +00:00
}
2005-11-23 10:22:41 +00:00
return theme('table', $header, $rows);
2001-11-18 12:30:08 +00:00
}
2004-05-09 19:28:43 +00:00
/**
* Display an administrative view of the hierarchy of a book.
*/
2005-11-23 10:22:41 +00:00
function book_admin_edit($nid) {
2005-07-17 18:29:32 +00:00
$node = node_load($nid);
2005-05-05 09:36:51 +00:00
if ($node->nid) {
2005-10-07 06:11:12 +00:00
drupal_set_title(check_plain($node->title));
2005-11-23 10:22:41 +00:00
$form = array();
2005-10-07 06:11:12 +00:00
2005-11-23 10:22:41 +00:00
$form['table'] = _book_admin_table(array($node));
$form['save'] = array(
'#type' => 'submit',
'#value' => t('Save book pages'),
);
2002-11-10 10:36:22 +00:00
2005-11-23 10:22:41 +00:00
return drupal_get_form('book_admin_edit', $form);
2003-05-13 21:34:39 +00:00
}
2005-05-05 09:36:51 +00:00
else {
drupal_not_found();
}
2002-11-10 10:36:22 +00:00
}
2005-06-05 10:52:04 +00:00
/**
2005-11-23 10:22:41 +00:00
* Menu callback; displays a listing of all orphaned book pages.
2005-06-05 10:52:04 +00:00
*/
2005-11-23 10:22:41 +00:00
function book_admin_orphan() {
$result = db_query(db_rewrite_sql('SELECT n.nid, n.title, n.status, b.parent FROM {node} n INNER JOIN {book} b ON n.vid = b.vid'));
2002-11-10 10:36:22 +00:00
2005-11-23 10:22:41 +00:00
$pages = array();
while ($page = db_fetch_object($result)) {
$pages[$page->nid] = $page;
}
$orphans = array();
if (count($pages)) {
foreach ($pages as $page) {
if ($page->parent && empty($pages[$page->parent])) {
$orphans[] = node_load($page->nid);
2003-05-13 21:34:39 +00:00
}
2002-11-10 10:36:22 +00:00
}
2005-11-23 10:22:41 +00:00
}
2002-11-10 10:36:22 +00:00
2005-11-23 10:22:41 +00:00
if (count($orphans)) {
$form = array();
2002-11-10 10:36:22 +00:00
2005-11-23 10:22:41 +00:00
$form['table'] = _book_admin_table($orphans);
$form['save'] = array(
'#type' => 'submit',
'#value' => t('Save book pages'),
);
return drupal_get_form('book_admin_edit', $form);
}
else {
return '<p>'. t('There are no orphan pages.') .'</p>';
2003-05-13 21:34:39 +00:00
}
2001-11-18 12:30:08 +00:00
}
2005-12-02 15:21:01 +00:00
function book_admin_edit_submit($form_id, $form_values) {
2005-11-23 10:22:41 +00:00
foreach ($form_values['table'] as $row) {
$node = node_load($row['nid']);
2001-11-18 12:30:08 +00:00
2005-11-23 10:22:41 +00:00
if ($row['title'] != $node->title || $row['weight'] != $node->weight) {
$node->title = $row['title'];
$node->weight = $row['weight'];
2001-11-18 12:30:08 +00:00
2005-11-23 10:22:41 +00:00
node_save($node);
watchdog('content', t('%type: updated %title.', array('%type' => theme('placeholder', t('book')), '%title' => theme('placeholder', $node->title))), WATCHDOG_NOTICE, l(t('view'), 'node/'. $node->nid));
2001-11-18 12:30:08 +00:00
}
}
2005-11-23 10:22:41 +00:00
if (is_numeric(arg(3))) {
// Updating pages in a single book.
$book = node_load(arg(3));
drupal_set_message(t('Updated book %title.', array('%title' => theme('placeholder', $book->title))));
}
else {
// Updating the orphan pages.
drupal_set_message(t('Updated orphan book pages.'));
}
2001-11-18 12:30:08 +00:00
}
2004-05-09 19:28:43 +00:00
/**
2004-05-17 22:00:06 +00:00
* Menu callback; displays the book administration page.
2004-05-09 19:28:43 +00:00
*/
2004-05-17 22:00:06 +00:00
function book_admin($nid = 0) {
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
$op = $_POST['op'];
$edit = $_POST['edit'];
2001-11-18 12:30:08 +00:00
2005-05-05 09:36:51 +00:00
if ($nid) {
return book_admin_edit($nid);
}
else {
return book_admin_overview();
}
}
2005-06-05 10:52:04 +00:00
/**
* Returns an administrative overview of all books.
*/
2005-05-05 09:36:51 +00:00
function book_admin_overview() {
2005-08-30 15:22:29 +00:00
$result = db_query(db_rewrite_sql('SELECT n.nid, n.title, b.weight FROM {node} n INNER JOIN {book} b ON n.vid = b.vid WHERE b.parent = 0 ORDER BY b.weight, n.title'));
2005-05-05 09:36:51 +00:00
while ($book = db_fetch_object($result)) {
$rows[] = array(l($book->title, "node/$book->nid"), l(t('outline'), "admin/node/book/$book->nid"));
}
$headers = array(t('Book'), t('Operations'));
return theme('table', $headers, $rows);
2001-11-18 12:30:08 +00:00
}
2004-05-09 19:28:43 +00:00
/**
* Implementation of hook_help().
*/
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
function book_help($section) {
2003-08-05 18:33:39 +00:00
switch ($section) {
2003-10-09 18:53:22 +00:00
case 'admin/help#book':
2005-11-01 10:17:34 +00:00
$output = '<p>'. t('The <em>book</em> content type is suited for creating structured, multi-page hypertexts such as site resource guides, manuals, and Frequently Asked Questions (FAQs). It permits a document to have chapters, sections, subsections, etc. Authors with suitable permissions can add pages to a collaborative book, placing them into the existing document by adding them to a table of contents menu. ') .'</p>';
$output .= '<p>'. t('Books have additional <em>previous</em>, <em>up</em>, and <em>next</em> navigation elements at the bottom of each page for moving through the text. Additional navigation may be provided by enabling the <em>book navigation block</em> on the <a href="%admin-block">block administration page</a>.', array('%admin-block' => url('admin/block'))) .'</p>';
2005-11-30 13:16:53 +00:00
$output .= '<p>'. t('Users can select the <em>printer-friendly version</em> link visible at the bottom of a book page to generate a printer-friendly display of the page and all of its subsections. ') .'</p>';
2005-11-01 10:17:34 +00:00
$output .= '<p>'. t('Administrators can view a book outline, from which is it possible to change the titles of sections, and their <i>weight</i> (thus reordering sections). From this outline, it is also possible to edit and/or delete book pages. Many content types besides pages (for example, blog entries, stories, and polls) can be added to a collaborative book by choosing the <em>outline</em> tab when viewing the post.') .'</p>';
$output .= t('<p>You can</p>
<ul>
<li>create new book pages: <a href="%node-add-book">create content >> book page</a>.</li>
<li>administer individual books (choose a book from list): <a href="%admin-node-book">administer >> content >> books</a>.</li>
2006-01-29 07:50:45 +00:00
<li>set workflow and other global book settings on the book configuration page: <a href="%admin-settings-content-types-book-page" title="book page content type">administer >> settings >> content types >> configure book page</a>.</li>
<li>enable the book navigation block: <a href="%admin-block">administer >> blocks</a>.</li>
2006-02-14 19:25:02 +00:00
<li>control who can create, edit, and outline posts in books by setting access permissions: <a href="%admin-access">administer >> access control</a>.</li>
2005-11-01 10:17:34 +00:00
</ul>
2006-01-29 07:50:45 +00:00
', array('%node-add-book' => url('node/add/book'), '%admin-node-book' => url('admin/node/book'), '%admin-settings-content-types-book-page' => url('admin/settings/content-types/book'), '%admin-block' => url('admin/block'), '%admin-access' => url('admin/access')));
2006-02-21 18:46:54 +00:00
$output .= '<p>'. t('For more information please read the configuration and customization handbook <a href="%book">Book page</a>.', array('%book' => 'http://drupal.org/handbook/modules/book/')) .'</p>';
2005-11-01 10:17:34 +00:00
return $output;
2004-06-18 15:04:37 +00:00
case 'admin/modules#description':
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
return t('Allows users to collaboratively author a book.');
2003-08-05 18:33:39 +00:00
case 'admin/node/book':
2005-11-30 13:16:53 +00:00
return t('<p>The book module offers a means to organize content, authored by many users, in an online manual, outline or FAQ.</p>');
2003-08-05 18:33:39 +00:00
case 'admin/node/book/orphan':
2004-11-23 22:20:41 +00:00
return t('<p>Pages in a book are like a tree. As pages are edited, reorganized and removed, child pages might be left with no link to the rest of the book. Such pages are referred to as "orphan pages". On this page, administrators can review their books for orphans and reattach those pages as desired.</p>');
2004-01-27 18:47:07 +00:00
case 'node/add#book':
- Patch #5347 by JonBob:
Here's a new patch that unifies the node/52 and book/view/52 paths for nodes. It involves a small change to hook_view(), which is discussed first:
Currently hook_view() expects node modules to return a themed node. However, each module does this the same way; they modify $node as necessary, then call theme('node', $node) and return the result. We can refactor this so that the calling function node_view() calls theme('node') instead. By doing this, it becomes possible for hook_nodeapi('view') to be called after hook_view() where the node contents are filtered, and before theme('node') where the body is enclosed in other HTML. This way the book module can insert its navigation into the body right before the theming.
Advantages of this refactoring:
- I can use it for book.module to remove the extra viewing path.
- The function of hook_nodeapi('view') becomes more like hook_view(), as neither will expect a return value.
- We more closely follow the flow of other nodeapi calls, which usually directly follow their corresponding specific node type hooks (instead of preceding them).
- The attachment.module people could use it to append their attachments in a list after the node.
- Gabor could use it instead of his filter perversion for his "articles in a series" module.
- A little less code in each view hook.
- The content hook is no longer needed, so that means even less code.
Disadvantages:
- Any modules written to use nodeapi('view') could be affected (but these would all be post-4.4 modules).
- Implementations of hook_view() would need to be updated (but return values would be ignored, so most would work without updates anyway).
Now the patch takes advantage of this API shift to inject its navigation at the end of all book nodes, regardless of the viewing path. In fact, since the paths become identical, I've removed the book/view handler entirely. We should probably provide an .htaccess rewrite for this (one is still needed for node/view/nn anyway). At the same time, there is a check in book_block() that shows the block appropriately on these pages.
2004-07-30 13:37:26 +00:00
return t("A book is a collaborative writing effort: users can collaborate writing the pages of the book, positioning the pages in the right order, and reviewing or modifying pages previously written. So when you have some information to share or when you read a page of the book and you didn't like it, or if you think a certain page could have been written better, you can do something about it.");
2003-08-05 18:33:39 +00:00
}
2004-10-08 11:17:59 +00:00
if (arg(0) == 'node' && is_numeric(arg(1)) && arg(2) == 'outline') {
2004-10-14 05:34:12 +00:00
return t('The outline feature allows you to include posts in the <a href="%book">book hierarchy</a>.', array('%book' => url('book')));
2004-10-08 11:17:59 +00:00
}
2002-04-14 19:34:04 +00:00
}
2003-11-20 21:51:23 +00:00
2005-08-25 21:14:17 +00:00