drupal/modules/book/book.module

812 lines
31 KiB
Plaintext
Raw Normal View History

<?php
// $Id$
/**
* @file
* Allows users to collaboratively author a book.
*/
/**
* Implementation of hook_node_name().
*/
function book_node_name($node) {
return t('book page');
}
/**
* Implementation of hook_perm().
*/
function book_perm() {
return array('maintain books', 'edit own book pages');
}
/**
* Implementation of hook_access().
*/
function book_access($op, $node) {
global $user;
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
// Everyone can access all published book pages whether these pages
// are still waiting for approval or not. We might not always want
// to display pages that are waiting for approval, but we take care
// of that problem in the book_content() function.
return ($node->status ? $node->status : ($node->uid == $user->uid && user_access('edit own book pages')));
}
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.
return user_access('maintain books');
}
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
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
// of that page waiting for approval and as long as the "create new
// revision"-bit is set. That is, only updates that don't overwrite
// the current or pending information are allowed.
return (user_access('maintain books') && !$node->moderate && $node->revision)
|| ($node->uid == $user->uid && user_access('edit own book pages'));
}
}
/**
* Implementation of hook_link().
*/
function book_link($type, $node = 0, $main = 0) {
2003-04-21 14:55:03 +00:00
$links = array();
if ($type == 'page' && user_access('access content')) {
$links[] = l(t('books'), 'book', array('title' => t('Read and contribute to the collaborative books.')));
}
if ($type == 'node' && $node->type == 'book') {
if (!$main) {
- 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
$links[] = l(t('printer-friendly version'), 'book/print/'. $node->nid, array('title' => t('Show a printer-friendly version of this book page and its sub-pages.')));
}
}
2003-04-21 14:55:03 +00:00
return $links;
}
/**
* Implementation of hook_menu().
*/
function book_menu() {
$items = array();
$items[] = array('path' => 'node/add/book', 'title' => t('book page'),
'access' => user_access('maintain books'));
$items[] = array('path' => 'admin/node/book', 'title' => t('books'),
'callback' => 'book_admin',
'access' => user_access('administer nodes'),
'weight' => 4);
$items[] = array('path' => 'admin/node/book/orphan', 'title' => t('orphan pages'),
'callback' => 'book_admin_orphan',
'access' => user_access('administer nodes'),
'weight' => 8);
$result = db_query('SELECT n.nid, n.title FROM {node} n INNER JOIN {book} b ON n.nid = b.nid WHERE b.parent = 0 ORDER BY b.weight, n.title');
while ($book = db_fetch_object($result)) {
$items[] = array('path' => 'admin/node/book/'. $book->nid, 'title' => t('"%title" book', array('%title' => $book->title)));
}
$items[] = array('path' => 'book', 'title' => t('books'),
'callback' => 'book_render',
'access' => user_access('access content'),
'type' => MENU_SUGGESTED_ITEM);
$items[] = array('path' => 'book/print', 'title' => t('printer-friendly version'),
'callback' => 'book_print',
'access' => user_access('access content'),
'type' => MENU_CALLBACK);
return $items;
}
/**
* 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.
*/
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();
if ($op == 'list') {
$block[0]['info'] = t('Book navigation');
}
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
// Only display this block when the user is browsing a book:
if (arg(0) == 'node' && is_numeric(arg(1))) {
$result = db_query('SELECT n.nid, n.title, b.parent FROM {node} n INNER JOIN {book} b ON n.nid = b.nid WHERE n.nid = %d', arg(1));
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;
}
$block['subject'] = $path[0]->title;
$block['content'] = book_tree($expand[0], 5, $expand);
}
}
}
return $block;
}
/**
* Implementation of hook_load().
*/
function book_load($node) {
global $user;
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
$book = db_fetch_object(db_query('SELECT parent, weight, log FROM {book} WHERE nid = %d', $node->nid));
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.
if ($user->uid) {
$book->uid = $user->uid;
$book->name = $user->name;
}
else {
$book->uid = 0;
$book->name = '';
}
}
- 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
// We set the revision field to indicate that we have to create
// a new revision when updating this book page. We enable this
// always such that the "edit this page" links appear.
$book->revision = 1;
return $book;
}
/**
* Implementation of hook_insert().
*/
function book_insert($node) {
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
db_query("INSERT INTO {book} (nid, parent, weight, log) VALUES (%d, %d, %d, '%s')", $node->nid, $node->parent, $node->weight, $node->log);
}
/**
* Implementation of hook_update().
*/
function book_update($node) {
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
db_query("UPDATE {book} SET parent = %d, weight = %d, log = '%s' WHERE nid = %d", $node->parent, $node->weight, $node->log, $node->nid);
}
/**
* Implementation of hook_delete().
*/
function book_delete(&$node) {
db_query('DELETE FROM {book} WHERE nid = %d', $node->nid);
}
/**
* Implementation of hook_validate().
*/
function book_validate(&$node) {
// Set default values for non-administrators.
if (!user_access('administer nodes')) {
$node->weight = 0;
$node->revision = 1;
}
}
/**
* Implementation of hook_form().
*/
function book_form(&$node) {
global $user;
$op = $_POST['op'];
$output = form_select(t('Parent'), 'parent', $node->parent, book_toc($node->nid), t('The parent subject or category the page belongs in.'));
if (function_exists('taxonomy_node_form')) {
$output .= implode('', taxonomy_node_form('book', $node));
}
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
$output .= form_textarea(t('Body'), 'body', $node->body, 60, 20, '', NULL, TRUE);
$output .= form_textarea(t('Log message'), 'log', $node->log, 60, 5, t('An explanation of the additions or updates being made to help the group understand your motivations.'));
if (user_access('administer nodes')) {
$output .= form_weight(t('Weight'), 'weight', $node->weight, 15, t('The heavier pages will sink and the lighter pages will be positioned nearer the top.'));
}
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:
$output .= form_hidden('revision', 1);
}
return $output;
}
/**
* Implementation of hook_node_link().
*/
function book_node_link($node = 0) {
global $user;
$op = $_POST['op'];
$edit = $_POST['edit'];
if ($node->type != 'book') {
if ($edit['nid']) {
$node = node_load(array('nid' => $edit['nid']));
}
if ($op == t('Add to book outline')) {
db_query('INSERT INTO {book} (nid, parent, weight) VALUES (%d, %d, %d)', $node->nid, $edit['parent'], $edit['weight']);
drupal_set_message(t('Added the node to the book.'));
}
if ($op == t('Update book outline')) {
db_query('UPDATE {book} SET parent = %d, weight = %d WHERE nid = %d', $edit['parent'], $edit['weight'], $node->nid);
drupal_set_message(t('Updated the book outline.'));
}
if ($op == t('Remove from book outline')) {
db_query('DELETE FROM {book} WHERE nid = %d', $node->nid);
drupal_set_message(t('Removed the post from the 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
$output .= '<h3>'. t('Edit book outline for node "%booktitle"', array('%booktitle' => '<em>'. $node->title .'</em>')) .'</h3>';
if ($edit['nid']) {
$page = db_fetch_object(db_query('SELECT * FROM {book} WHERE nid = %d', $node->nid));
$output .= form_select(t('Parent'), 'parent', $page->parent, book_toc($node->nid), t('The parent subject or category the page belongs in.'));
$output .= form_weight(t('Weight'), 'weight', $node->weight, 15, t('The heavier pages will sink and the lighter pages will be positioned nearer the top.'));
if ($page->nid) {
$output .= form_submit(t('Update book outline'));
$output .= form_submit(t('Remove from book outline'));
}
else {
$output .= form_submit(t('Add to book outline'));
}
}
else {
$output .= form_submit(t('Edit book outline'));
}
$output .= form_hidden('nid', $node->nid);
return form($output, 'post', url('admin/node/book'));
}
}
/**
* Return the the most recent revision that matches the specified conditions.
*/
function book_revision_load($page, $conditions = array()) {
$revisions = array_reverse(node_revision_list($page));
foreach ($revisions as $revision) {
- 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
// Extract the specified revision:
$node = node_revision_load($page, $revision);
- 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
// Check to see if the conditions are met:
$status = TRUE;
foreach ($conditions as $key => $value) {
if ($node->$key != $value) {
- 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
$status = FALSE;
}
}
if ($status) {
return $node;
}
}
}
/**
* Return the path (call stack) to a certain book page.
*/
function book_location($node, $nodes = array()) {
$parent = db_fetch_object(db_query('SELECT n.nid, n.title, b.parent FROM {node} n INNER JOIN {book} b ON n.nid = b.nid WHERE n.nid = %d', $node->parent));
if ($parent->title) {
$nodes = book_location($parent, $nodes);
array_push($nodes, $parent);
}
return $nodes;
}
function book_location_down($node, $nodes = array()) {
$last_direct_child = db_fetch_object(db_query('SELECT n.nid, n.title, b.parent FROM {node} n INNER JOIN {book} b ON n.nid = b.nid WHERE b.parent = %d ORDER BY b.weight DESC, n.title DESC', $node->nid));
if ($last_direct_child) {
array_push($nodes, $last_direct_child);
$nodes = book_location_down($last_direct_child, $nodes);
}
return $nodes;
}
/**
* Fetch the node object of the previous page of the book.
*/
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.
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:
$direct_above = db_fetch_object(db_query("SELECT n.nid, n.title FROM {node} n INNER JOIN {book} b ON n.nid = b.nid WHERE b.parent = %d AND n.status = 1 AND (n.moderate = 0 OR n.revisions != '') 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));
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.
$path = book_location_down($direct_above);
return $path ? (count($path) > 0 ? array_pop($path) : NULL) : $direct_above;
}
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:
$prev = db_fetch_object(db_query("SELECT n.nid, n.title FROM {node} n INNER JOIN {book} b ON n.nid = b.nid WHERE n.nid = %d AND n.status = 1 AND (n.moderate = 0 OR n.revisions != '')", $node->parent));
return $prev;
}
}
/**
* Fetch the node object of the next page of the book.
*/
function book_next($node) {
// get first direct child
$child = db_fetch_object(db_query("SELECT DISTINCT(n.nid), n.title FROM {node} n ". node_access_join_sql() ." INNER JOIN {book} b ON n.nid = b.nid WHERE b.parent = %d AND n.status = 1 AND ". node_access_where_sql() ." AND (n.moderate = 0 OR n.revisions != '') ORDER BY b.weight ASC, n.title ASC", $node->nid));
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.
while (($leaf = array_pop($path)) && count($path)) {
$next = db_fetch_object(db_query("SELECT DISTINCT(n.nid), n.title FROM {node} n ". node_access_join_sql() ." INNER JOIN {book} b ON n.nid = b.nid WHERE b.parent = %d AND n.status = 1 AND ". node_access_where_sql() ." AND (n.moderate = 0 OR n.revisions != '') 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));
if ($next) {
return $next;
}
}
}
/**
* Implementation of hook_content().
*/
function book_content($node, $teaser = FALSE) {
$op = $_POST['op'];
- 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
// Always display the most recently approved revision of a node
// (if any) unless we have to display this page in the context of
// the moderation queue.
if ($op != t('Preview') && $node->moderate && arg(0) != 'queue') {
$revision = book_revision_load($node, array('moderate' => 0, 'status' => 1));
if ($revision) {
$node = $revision;
}
}
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
// Extract the page body.
$node = node_prepare($node, $teaser);
return $node;
}
/**
* 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) {
$node = book_content($node, $teaser);
- 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 (!$teaser && $node->moderate) {
$node->body .= '<div class="log"><div class="title">'. t('Log') .':</div>'. $node->log .'</div>';
}
}
/**
- 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.
*/
- 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) {
$book = db_fetch_array(db_query('SELECT * FROM {book} WHERE nid = %d', $node->nid));
if ($book) {
foreach ($book as $key => $value) {
$node->$key = $value;
}
$node = book_navigation($node);
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
}
}
- 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;
}
}
/**
* Prepares both the custom breadcrumb trail and the forward/backward
* navigation for a node presented as a book page.
*/
function book_navigation($node) {
$path = book_location($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
// Construct the breadcrumb:
$node->breadcrumb = array(); // Overwrite the trail with a book trail.
foreach ($path as $level) {
- 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
$node->breadcrumb[] = array('path' => 'node/'. $level->nid, 'title' => $level->title);
}
$node->breadcrumb[] = array('path' => 'node/'. $node->nid);
if ($node->nid) {
$output .= '<div class="book">';
if ($tree = book_tree($node->nid)) {
$output .= '<div class="tree">'. $tree .'</div>';
}
if ($prev = book_prev($node)) {
$links .= '<div class="prev">';
- 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
$links .= l(t('previous'), 'node/'. $prev->nid, array('title' => t('View the previous page.')));
$links .= '</div>';
- 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
$titles .= '<div class="prev">'. $prev->title .'</div>';
}
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
$links .= '<div class="prev">&nbsp;</div>'; // Make an empty div to fill the space.
}
if ($next = book_next($node)) {
$links .= '<div class="next">';
- 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
$links .= l(t('next'), 'node/'. $next->nid, array('title' => t('View the next page.')));
$links .= '</div>';
- 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
$titles .= '<div class="next">'. $next->title .'</div>';
}
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
$links .= '<div class="next">&nbsp;</div>'; // Make an empty div to fill the space.
}
if ($node->parent) {
$links .= '<div class="up">';
- 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
$links .= l(t('up'), 'node/'. $node->parent, array('title' => t('View this page\'s parent section.')));
$links .= '</div>';
}
$output .= '<div class="nav">';
- 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 .= ' <div class="links">'. $links .'</div>';
$output .= ' <div class="titles">'. $titles .'</div>';
$output .= '</div>';
$output .= '</div>';
}
$node->body = $node->body.$output;
return $node;
}
function book_toc_recurse($nid, $indent, $toc, $children, $exclude) {
if ($children[$nid]) {
foreach ($children[$nid] as $foo => $node) {
if (!$exclude || $exclude != $node->nid) {
$toc[$node->nid] = $indent .' '. $node->title;
$toc = book_toc_recurse($node->nid, $indent .'--', $toc, $children, $exclude);
}
}
}
return $toc;
}
function book_toc($exclude = 0) {
$result = db_query('SELECT DISTINCT(n.nid), n.title, b.parent FROM {node} n '. node_access_join_sql() .' INNER JOIN {book} b ON n.nid = b.nid WHERE n.status = 1 AND '. node_access_where_sql() .' ORDER BY b.weight, n.title');
while ($node = db_fetch_object($result)) {
if (!$children[$node->parent]) {
$children[$node->parent] = array();
}
array_push($children[$node->parent], $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 user is an administrator, add the top-level book page;
// only administrators can start new books.
if (user_access('administer nodes')) {
$toc[0] = '<'. t('top-level') .'>';
}
$toc = book_toc_recurse(0, '', array(), $children, $exclude);
return $toc;
}
function book_tree_recurse($nid, $depth, $children, $unfold = array()) {
2002-01-01 11:26:29 +00:00
if ($depth > 0) {
- import.module: + Improved input filtering; this should make the news items look more consistent in terms of mark-up. + Quoted all array indices: converted all instances of $foo[bar] to $foo["bar"]. Made various other changes to make the import module compliant with the coding style. - theme.inc: + Fixed small XHTML glitch - comment system: + Made it possible for users to edit their comments (when certain criteria are matched). + Renamed the SQL table field "lid" to "nid" and updated the code to reflect this change: this is a rather /annoying/ change that has been asked for a few times. It will impact the contributed BBS/forum modules and requires a tiny SQL update: sql> ALTER TABLE comments CHANGE lid nid int(10) NOT NULL; + Moved most (all?) of the comment related logic from node.php to comment.module where it belongs. This also marks a first step towards removing/reducing "node.php". + Added a delete button to the comment admin form and made it so that Drupal prompts for confirmation prior to deleting a comment from the database. This behavior is similar to that of deleting nodes. + Disabled comment moderation for now. + Some of the above changes will make it easier to integrate the upcomcing mail-to-web and web-to-mail gateways. They are part of a bigger plan. ;) - node system: + Made it so that updating nodes (like for instance updating blog entries) won't trigger the submission rate throttle. + Fixed a small glitch where a node's title wasn't always passed to the $theme->header() function. + Made "node_array()" and "node_object()" more generic and named them "object2array()" and "array2object()". + Moved most (all?) of the comment related logic from node.php to comment.module where it belongs. This also marks a first step towards removing/reducing "node.php". - misc: + Applied three patches by Foxen. One to improve performance of the book module, and two other patches to fix small glitches in common.inc. Thanks Foxen!
2001-12-30 16:16:38 +00:00
if ($children[$nid]) {
foreach ($children[$nid] as $foo => $node) {
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);
$output .= '<ul>'. $tree .'</ul>';
$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>';
}
}
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>';
}
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>';
}
2002-01-01 11:26:29 +00:00
}
2001-12-27 15:20:20 +00:00
}
}
- import.module: + Improved input filtering; this should make the news items look more consistent in terms of mark-up. + Quoted all array indices: converted all instances of $foo[bar] to $foo["bar"]. Made various other changes to make the import module compliant with the coding style. - theme.inc: + Fixed small XHTML glitch - comment system: + Made it possible for users to edit their comments (when certain criteria are matched). + Renamed the SQL table field "lid" to "nid" and updated the code to reflect this change: this is a rather /annoying/ change that has been asked for a few times. It will impact the contributed BBS/forum modules and requires a tiny SQL update: sql> ALTER TABLE comments CHANGE lid nid int(10) NOT NULL; + Moved most (all?) of the comment related logic from node.php to comment.module where it belongs. This also marks a first step towards removing/reducing "node.php". + Added a delete button to the comment admin form and made it so that Drupal prompts for confirmation prior to deleting a comment from the database. This behavior is similar to that of deleting nodes. + Disabled comment moderation for now. + Some of the above changes will make it easier to integrate the upcomcing mail-to-web and web-to-mail gateways. They are part of a bigger plan. ;) - node system: + Made it so that updating nodes (like for instance updating blog entries) won't trigger the submission rate throttle. + Fixed a small glitch where a node's title wasn't always passed to the $theme->header() function. + Made "node_array()" and "node_object()" more generic and named them "object2array()" and "array2object()". + Moved most (all?) of the comment related logic from node.php to comment.module where it belongs. This also marks a first step towards removing/reducing "node.php". - misc: + Applied three patches by Foxen. One to improve performance of the book module, and two other patches to fix small glitches in common.inc. Thanks Foxen!
2001-12-30 16:16:38 +00:00
}
return $output;
}
function book_tree($parent = 0, $depth = 3, $unfold = array()) {
$result = db_query('SELECT DISTINCT(n.nid), n.title, b.parent FROM {node} n '. node_access_join_sql() .' INNER JOIN {book} b ON n.nid = b.nid WHERE n.status = 1 AND '. node_access_where_sql() .' AND n.moderate = 0 ORDER BY b.weight, n.title');
- import.module: + Improved input filtering; this should make the news items look more consistent in terms of mark-up. + Quoted all array indices: converted all instances of $foo[bar] to $foo["bar"]. Made various other changes to make the import module compliant with the coding style. - theme.inc: + Fixed small XHTML glitch - comment system: + Made it possible for users to edit their comments (when certain criteria are matched). + Renamed the SQL table field "lid" to "nid" and updated the code to reflect this change: this is a rather /annoying/ change that has been asked for a few times. It will impact the contributed BBS/forum modules and requires a tiny SQL update: sql> ALTER TABLE comments CHANGE lid nid int(10) NOT NULL; + Moved most (all?) of the comment related logic from node.php to comment.module where it belongs. This also marks a first step towards removing/reducing "node.php". + Added a delete button to the comment admin form and made it so that Drupal prompts for confirmation prior to deleting a comment from the database. This behavior is similar to that of deleting nodes. + Disabled comment moderation for now. + Some of the above changes will make it easier to integrate the upcomcing mail-to-web and web-to-mail gateways. They are part of a bigger plan. ;) - node system: + Made it so that updating nodes (like for instance updating blog entries) won't trigger the submission rate throttle. + Fixed a small glitch where a node's title wasn't always passed to the $theme->header() function. + Made "node_array()" and "node_object()" more generic and named them "object2array()" and "array2object()". + Moved most (all?) of the comment related logic from node.php to comment.module where it belongs. This also marks a first step towards removing/reducing "node.php". - misc: + Applied three patches by Foxen. One to improve performance of the book module, and two other patches to fix small glitches in common.inc. Thanks Foxen!
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;
}
2002-01-01 11:26:29 +00:00
if ($tree = book_tree_recurse($parent, $depth, $children, $unfold)) {
- 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 '<ul>'. $tree .'</ul>';
}
}
/**
2004-05-17 22:00:06 +00:00
* Menu callback; prints a listing of all books.
*/
function book_render() {
$result = db_query('SELECT n.nid FROM {node} n INNER JOIN {book} b ON n.nid = b.nid WHERE b.parent = 0 AND n.status = 1 AND (n.moderate = 0 OR n.revisions IS NOT NULL) ORDER BY b.weight, n.title');
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:
$node = node_load(array('nid' => $page->nid));
if ($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
// Take the most recent approved revision, extract the page and check output:
$node = book_content($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
// Output the content:
$output .= '<div class="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
$output .= '<div class="title">'. l($node->title, 'node/'. $node->nid) .'</div>';
$output .= '<div class="body">'. $node->teaser .'</div>';
$output .= '</div>';
}
}
drupal_set_title(t('Books'));
print theme('page', $output);
}
/**
- 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
* Menu callback; generates printer-friendly book page with all descendants.
*/
function book_print($nid = 0, $depth = 1) {
global $base_url;
$result = db_query('SELECT DISTINCT(n.nid) FROM {node} n '. node_access_join_sql() .' INNER JOIN {book} b ON n.nid = b.nid WHERE n.status = 1 AND '. node_access_where_sql() .' AND n.nid = %d AND (n.moderate = 0 OR n.revisions IS NOT NULL) ORDER BY b.weight, n.title', $nid);
while ($page = db_fetch_object($result)) {
// load the node:
$node = node_load(array('nid' => $page->nid));
if ($node) {
// output the content:
if (node_hook($node, 'content')) {
$node = node_invoke($node, 'content');
}
- 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 .= '<h1 id="'. $node->nid .'" name="'. $node->nid .'" class="book-h'. $depth .'">'. $node->title .'</h1>';
if ($node->body) {
$output .= $node->body;
}
}
}
$output .= book_print_recurse($nid, $depth);
- 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
$html = '<html><head><title>'. $node->title .'</title>';
$html .= '<base href="'. $base_url .'/" />';
$html .= "<style type=\"text/css\">\n@import url(misc/print.css);\n</style>";
$html .= '</head><body>'. $output .'</body></html>';
print $html;
}
function book_print_recurse($parent = '', $depth = 1) {
$result = db_query("SELECT DISTINCT(n.nid) FROM {node} n ". node_access_join_sql() ." INNER JOIN {book} b ON n.nid = b.nid WHERE n.status = 1 AND ". node_access_where_sql() ." AND b.parent = '$parent' AND (n.moderate = 0 OR n.revisions IS NOT NULL) ORDER BY b.weight, n.title");
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:
$node = node_load(array('nid' => $page->nid));
- 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
// Take the most recent approved revision:
if ($node->moderate) {
$node = book_revision_load($node, array('moderate' => 0, 'status' => 1));
}
if ($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
// Output the content:
if (node_hook($node, 'content')) {
$node = node_invoke($node, 'content');
}
- 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 .= '<h1 id="'. $node->nid .'" name="'. $node->nid .'" class="book-h'. $depth .'">'. $node->title .'</h1>';
if ($node->body) {
$output .= '<ul>'. $node->body .'</ul>';
}
$output .= book_print_recurse($node->nid, $depth + 1);
}
}
return $output;
}
function book_admin_view_line($node, $depth = 0) {
return array('<div style="padding-left: '. (25 * $depth) .'px;">'. form_textfield(NULL, $node->nid .'][title', $node->title, 64, 255) .'</div>', form_weight(NULL, $node->nid .'][weight', $node->weight), l(t('view'), 'node/'. $node->nid), l(t('edit'), 'node/'. $node->nid .'/edit'), l(t('delete'), 'admin/node/delete/'. $node->nid));
}
function book_admin_view_book($nid, $depth = 1) {
$result = db_query("SELECT n.nid FROM {node} n INNER JOIN {book} b ON n.nid = b.nid WHERE b.parent = %d ORDER BY b.weight, n.title", $nid);
while ($node = 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
$node = node_load(array('nid' => $node->nid));
$rows[] = book_admin_view_line($node, $depth);
$rows = array_merge($rows, book_admin_view_book($node->nid, $depth + 1));
}
return $rows;
}
/**
* Display an administrative view of the hierarchy of a book.
*/
function book_admin_view($nid, $depth = 0) {
if ($nid) {
- 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
$node = node_load(array('nid' => $nid));
- 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 .= '<h3>'. $node->title .'</h3>';
$header = array(t('Title'), t('Weight'), array('data' => t('Operations'), 'colspan' => 3));
$rows[] = book_admin_view_line($node);
$rows = array_merge($rows, book_admin_view_book($nid));
- 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 .= theme('table', $header, $rows);
$output .= form_submit(t('Save book pages'));
return form($output);
}
}
function book_admin_save($nid, $edit = array()) {
if ($nid) {
- 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
$book = node_load(array('nid' => $nid));
foreach ($edit as $nid => $value) {
- 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
// Check to see whether the title needs updating:
$title = db_result(db_query('SELECT title FROM {node} WHERE nid = %d', $nid));
if ($title != $value['title']) {
db_query("UPDATE {node} SET title = '%s' WHERE nid = %d", $value['title'], $nid);
}
- 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
// Check to see whether the weight needs updating:
$weight = db_result(db_query('SELECT weight FROM {book} WHERE nid = %d', $nid));
if ($weight != $value['weight']) {
db_query('UPDATE {book} SET weight = %d WHERE nid = %d', $value['weight'], $nid);
}
}
$message = t('Updated book %title.', array('%title' => "<em>$book->title</em>"));
watchdog('special', $message);
return $message;
}
}
/**
2004-05-17 22:00:06 +00:00
* Menu callback; displays a listing of all orphaned book pages.
*/
function book_admin_orphan() {
- 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
$result = db_query('SELECT n.nid, n.title, n.status, b.parent FROM {node} n INNER JOIN {book} b ON n.nid = b.nid');
while ($page = db_fetch_object($result)) {
$pages[$page->nid] = $page;
}
if ($pages) {
$output .= '<h3>'. t('Orphan pages') .'</h3>';
$header = array(t('Title'), t('Weight'), array('data' => t('Operations'), 'colspan' => 3));
foreach ($pages as $nid => $node) {
if ($node->parent && empty($pages[$node->parent])) {
$rows[] = book_admin_view_line($node, $depth);
$rows = array_merge($rows, book_admin_view_book($node->nid, $depth + 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
$output .= theme('table', $header, $rows);
}
- 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
print theme('page', $output);
}
/**
2004-05-17 22:00:06 +00:00
* Menu callback; displays the book administration page.
*/
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'];
switch ($op) {
- 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
case t('Edit book outline'):
case t('Add to book outline'):
case t('Remove from book outline'):
case t('Update book outline'):
$output = book_node_link();
break;
- 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
case t('Save book pages'):
drupal_set_message(book_admin_save($nid, $edit));
// fall through:
default:
$output .= book_admin_view($nid);
break;
}
- 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
print theme('page', $output);
}
/**
* 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) {
switch ($section) {
case 'admin/help#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("
<p>The book organises content into a nested hierarchical structure. It is particularly good for manuals, Frequently Asked Questions (FAQs) and the like, allowing you to have chapters, sections, etc.</p>
<p>A book is simply a collection of nodes that have been linked together. These nodes are usually of type <em>book page</em>, but you can insert nodes of any type into a book outline. Every node in the book has a <em>parent</em> node which \"contains\" it. This is how book.module establishes its hierarchy. At any given level in the hierarchy, a book can contain many nodes. All these sibling nodes are sorted according to the <em>weight</em> that you give them.</p>
<p>A book page is a special node type that allows you to embed PHP within the body of the page. This capability is only offered to administrators, since malicious users could abuse this power. In addition, book pages contain a <em>log message</em> field which helps your users understand the motivation behind an edit of a book page. Each edited version of a book page is stored as a new revision of a node. This capability makes it easy to revert to an old version of a page, should that be desirable.</p>
<p>Like other node types, book submissions and edits may be subject to moderation, depending on your configuration. Similarly, books use <a href=\"%permissions\">permissions</a> to determine who may read and write to them. Only administrators are allowed to create new books, which are really just nodes whose parent is <em>&lt;top-level&gt;</em>. To include an existing node in your book, click on the \"administer\"-link in that node. At the bottom of this administration page, click on the <em>edit book outline</em> button. This enables you to place the node wherever you'd like within the book hierarchy. To add a new node into your book, use the <a href=\"%create\">create content &raquo; book page</a> link.</p>
<p>Administrators may review the hierarchy of their books by clicking on the <a href=\"%collaborative-book\">collaborative book</a> link in the adminstration pages. There, nodes may be edited, reorganized, removed from book, and deleted. This behavior may change in the future. When a parent node is deleted, it may leave behind child nodes. These nodes are now <em>orphans</em>. Administrators should periodically <a href=\"%orphans-book\">review their books for orphans</a> and reaffiliate those pages as desired. Finally, administrators may also <a href=\"%export-book\">export their books</a> to a single, flat HTML page which is suitable for printing.</p>
<h3>Maintaining a FAQ using a collaborative book</h3>
<p>Collaborative books let you easily set up a Frequently Asked Questions (FAQ) section on your web site. The main benefit is that you don't have to write all the questions/answers by yourself - let the community do it for you!</p>
<p>In order to set up the FAQ, you have to create a new book which will hold all your content. To do so, click on the <a href=\"%create\">create content &raquo; book page</a> link. Give it a thoughtful title, and body. A title like \"Estonia Travel - FAQ\" is nice. You may always edit these fields later. You will probably want to designate <em>&lt;top-level&gt;</em> as the parent of this page. Leave the <em>log message</em> and <em>type</em> fields blank for now. After you have submitted this book page, you are ready to begin filling up your book with questions that are frequently asked.</p>
<p>Whenever you come across a post which you want to include in your FAQ, click on the <em>administer</em> link. Then click on the <em>edit book outline</em> button at the bottom of the page. Then place the relevant post wherever is most appropriate in your book by selecting a <em>parent</em>. Books are quite flexible. They can have sections like <em>Flying to Estonia</em>, <em>Eating in Estonia</em> and so on. As you get more experienced with the book module, you can reorganize posts in your book so that it stays organized.</p>
<p>Notes:</p><ul><li>Any comments attached to those relevant posts which you designate as book pages will also be transported into your book. This is a great feature, since much wisdom is shared via comments. Remember that all future comments and edits will automatically be reflected in your book.</li><li>You may wish to edit the title of posts when adding them to your FAQ. This is done on the same page as the <em>Edit book outline</em> button. Clear titles improve navigability enormously.</li><li>Book pages may come from any content type (blog, story, page, etc.). If you are creating a post solely for inclusion in your book, then use the <a href=\"%create\">create content &raquo; book page</a> link.</li><li>If you don't see the <em>administer</em> link, then you probably have insufficient <a href=\"%permissions\">permissions</a>.</li><li>If you want to get really fancy, note that books are one of the few content types which allow raw PHP in their <em>body</em>. So you've got lots of geeky possibilities there.</li></ul>", array("%permissions" => url("admin/user/configure/permission"), "%create" => url("node/add/book"), "%collaborative-book" => url("admin/node/book"), "%orphans-book" => url("admin/node/book/orphan"), "%export-book" => url("book/print")));
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.');
case 'admin/node/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('The book module offers a mean to organize content, authored by many users, in an online manual, outline or FAQ.');
case 'admin/node/book/orphan':
- 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('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.');
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.");
}
}
function book_help_page() {
- 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
print theme('page', book_help('admin/help#book'));
}
?>