2001-03-10 11:07:52 +00:00
<?php
2001-10-20 18:57:09 +00:00
// $Id$
2000-12-23 15:20:10 +00:00
2004-08-21 06:42:38 +00:00
/**
* @file
* Controls the boxes that are displayed around the main content.
*/
2004-05-11 20:10:14 +00:00
/**
* Implementation of hook_help().
*/
function block_help($section) {
2003-08-05 18:33:39 +00:00
switch ($section) {
2003-10-09 18:53:22 +00:00
case 'admin/help#block':
2004-05-11 20:10:14 +00:00
return t("
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
<p>Blocks are the boxes visible in the sidebar(s) of your web site. These are usually generated automatically by modules (e.g. recent forum topics), but you can also create your own blocks.</p>
2004-01-21 06:36:56 +00:00
<p>The sidebar each block appears in depends on both which theme you're using (some are left-only, some right, some both), and on the settings in block management.</p><p>Whether a block is visible in the first place depends on four things:</p><ul><li>It must have its \"enabled\" box checked in block management.</li><li>If it has its \"custom\" box checked in block management, the user must have chosen to display it in their user preferences.</li><li>If the \"path\" field in block management is set, the visitor must be on a page that matches the path specification (more on this later).</li><li>If the block has its throttle box checked, the user will only see the block if the site throttle level is low.</li></ul>
2004-07-07 05:42:24 +00:00
<p>The block management screen also lets you specify the vertical sort-order of the blocks within a sidebar. You do this by assigning a <strong>weight</strong> to each block. Lighter blocks (smaller weight) \"float up\" towards the top of the sidebar. Heavier ones \"sink down\" towards the bottom of it.</p>
2004-06-18 15:04:37 +00:00
<p>The path setting lets you define the pages on which a specific block is visible. If you leave the path blank it will appear on all pages. The path uses a regular expression syntax so remember to escape special characters! The path expression is matched against the relative URL of a Drupal page, e.g. <code>book</code>, <code>node/12</code>, <code>admin</code>.</p>
2004-01-21 06:36:56 +00:00
<p>In case you do not know what a regular expression is, you should read about them in the PHP manual. The chapter to look at is the one on <a href=\"%pcre\">Perl-Compatible Regular Expressions (PCRE)</a>.</p>
<p>However, for basic tasks it is sufficient to look at the following examples:</p>
2004-06-18 15:04:37 +00:00
<p>If the block should only show up on blog pages, use <^blog>. To display on all node views use <^node>. The angular brackets are used as delimiters of the regular expression. To show up on either forum or book pages use <^(forum|book)>. The round brackets form a group of expressions, divided by the | character. It matches if any of the expressions in it match. A more complicated example is <^node/add/(story|blog|image)>. Blocks which have their paths set to this expression will show up on story, block, or image composition pages. If you want to show a block an all pages, but not the search page, use <^(?!search)>.</p>
2004-01-21 06:36:56 +00:00
<h3>Administrator Defined Blocks</h3>
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
<p>An administrator defined block contains content supplied by you (as opposed to being generated automatically by a module). Each admin-defined block consists of a title, a description, and a body which can be as long as you wish. The Drupal engine will 'render' the content of the block.</p>", array('%pcre' => 'http://php.net/pcre/'));
2004-06-18 15:04:37 +00:00
case 'admin/modules#description':
2004-05-11 20:10:14 +00:00
return t('Controls the boxes that are displayed around the main content.');
2004-06-18 15:04:37 +00:00
case 'admin/block':
2004-08-01 19:26:07 +00:00
return t("Blocks are the boxes in the left- and right- side bars of the web site, depending on the chosen theme. They are made available active modules or created manually. The \"enabled\" checkbox sets the default status of the block. Only enabled blocks are shown. When the \"custom\" checkbox is checked, your users can show or hide the block using their account settings. In that case, the 'enabled' checkbox signifies the block's default status. You can assign the block's placement by giving it a region and a weight. The region specifies which side of the page the block is on, and the weight sorts blocks within a region. Lighter (smaller weight value) blocks \"float up\" towards the top of the page. The path setting lets you define which pages you want a block to be shown on. Blocks can automatically be temporarily disabled to reduce server load when your site becomes extremely busy by checking throttle. The auto-throttle functionality must be enabled on the <a href=\"%throttle\">throttle configuration page</a> after having enabled the throttle module.", array('%throttle' => url('admin/settings/throttle')));
2004-06-18 15:04:37 +00:00
case 'admin/block/add':
2004-10-09 06:29:16 +00:00
return t("Here you can create a new block. Once you have created this block you must make it active and give it a place on the page using <a href=\"%overview\">blocks</a>. The title is used when displaying the block. The description is used in the \"block\" column on the <a href=\"%overview\">blocks</a> page.", array('%overview' => url('admin/block')));
2003-08-05 18:33:39 +00:00
}
2001-01-13 16:33:19 +00:00
}
2004-05-11 20:10:14 +00:00
/**
2004-05-17 22:00:06 +00:00
* Menu callback; presents the block-specific information from admin/help.
2004-05-11 20:10:14 +00:00
*/
2003-11-20 21:51:23 +00:00
function block_help_page() {
2004-05-11 20:10:14 +00:00
print theme('page', block_help('admin/help#block'));
2003-11-20 21:51:23 +00:00
}
2004-05-11 20:10:14 +00:00
/**
* Implementation of hook_perm().
*/
2001-06-20 20:00:40 +00:00
function block_perm() {
2004-05-11 20:10:14 +00:00
return array('administer blocks');
2001-06-29 22:08:57 +00:00
}
2004-04-21 13:56:38 +00:00
/**
2004-06-18 15:04:37 +00:00
* Implementation of hook_menu().
2004-04-21 13:56:38 +00:00
*/
2004-09-16 07:17:56 +00:00
function block_menu($may_cache) {
2004-06-18 15:04:37 +00:00
$items = array();
2004-09-16 07:17:56 +00:00
if ($may_cache) {
$items[] = array('path' => 'admin/block', 'title' => t('blocks'),
'access' => user_access('administer blocks'),
'callback' => 'block_admin');
$items[] = array('path' => 'admin/block/list', 'title' => t('list'),
'type' => MENU_DEFAULT_LOCAL_TASK, 'weight' => -10);
$items[] = array('path' => 'admin/block/edit', 'title' => t('edit block'),
'access' => user_access('administer blocks'),
'callback' => 'block_box_edit',
'type' => MENU_CALLBACK);
$items[] = array('path' => 'admin/block/delete', 'title' => t('delete block'),
'access' => user_access('administer blocks'),
'callback' => 'block_box_delete',
'type' => MENU_CALLBACK);
$items[] = array('path' => 'admin/block/add', 'title' => t('add'),
'access' => user_access('administer blocks'),
'callback' => 'block_box_edit',
'type' => MENU_LOCAL_TASK);
}
2004-06-18 15:04:37 +00:00
return $items;
2001-06-20 20:00:40 +00:00
}
2004-05-11 20:10:14 +00:00
/**
* Implementation of hook_block().
*
* Generates the administrator-defined blocks for display.
*/
function block_block($op = 'list', $delta = 0) {
if ($op == 'list') {
$result = db_query('SELECT bid, title, info FROM {boxes} ORDER BY title');
2002-10-26 15:17:26 +00:00
while ($block = db_fetch_object($result)) {
2004-05-11 20:10:14 +00:00
$blocks[$block->bid]['info'] = $block->info;
2002-10-26 15:17:26 +00:00
}
return $blocks;
}
else {
2004-05-11 20:10:14 +00:00
$block = db_fetch_object(db_query('SELECT * FROM {boxes} WHERE bid = %d', $delta));
$data['subject'] = $block->title;
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
$data['content'] = check_output($block->body, $block->format);
2002-10-26 15:17:26 +00:00
return $data;
2002-05-02 19:13:45 +00:00
}
}
2000-12-23 15:20:10 +00:00
function block_admin_save($edit) {
2002-10-26 15:17:26 +00:00
foreach ($edit as $module => $blocks) {
foreach ($blocks as $delta => $block) {
2003-11-28 20:03:00 +00:00
db_query("UPDATE {blocks} SET region = %d, status = %d, custom = %d, path = '%s', weight = %d, throttle = %d WHERE module = '%s' AND delta = '%s'",
2004-05-11 20:10:14 +00:00
$block['region'], $block['status'], $block['custom'], $block['path'], $block['weight'], $block['throttle'], $module, $delta);
2002-10-26 15:17:26 +00:00
}
2000-12-23 15:20:10 +00:00
}
2002-11-17 06:42:52 +00:00
2004-05-11 20:10:14 +00:00
return t('the block settings have been updated.');
2000-12-23 15:20:10 +00:00
}
2002-10-30 08:12:28 +00:00
/**
2004-05-11 20:10:14 +00:00
* Update the 'blocks' DB table with the blocks currently exported by modules.
2002-11-01 10:47:20 +00:00
*
2003-12-08 06:32:19 +00:00
* @param $order_by php <a
* href="http://www.php.net/manual/en/function.array-multisort.php">array_multisort()</a>
* style sort ordering, eg. "weight", SORT_ASC, SORT_STRING.
2003-11-24 22:46:03 +00:00
*
2004-05-11 20:10:14 +00:00
* @return
* Blocks currently exported by modules, sorted by $order_by.
2002-10-30 08:12:28 +00:00
*/
2004-05-11 20:10:14 +00:00
function _block_rehash($order_by = array('weight')) {
$result = db_query('SELECT * FROM {blocks} ');
2002-10-26 15:17:26 +00:00
while ($old_block = db_fetch_object($result)) {
$old_blocks[$old_block->module][$old_block->delta] = $old_block;
}
2004-05-11 20:10:14 +00:00
db_query('DELETE FROM {blocks} ');
2002-10-26 15:17:26 +00:00
foreach (module_list() as $module) {
2004-05-11 20:10:14 +00:00
$module_blocks = module_invoke($module, 'block', 'list');
2002-10-26 15:17:26 +00:00
if ($module_blocks) {
foreach ($module_blocks as $delta => $block) {
2004-05-11 20:10:14 +00:00
$block['module'] = $module;
$block['delta'] = $delta;
2002-10-26 15:17:26 +00:00
if ($old_blocks[$module][$delta]) {
2004-05-11 20:10:14 +00:00
$block['status'] = $old_blocks[$module][$delta]->status;
$block['weight'] = $old_blocks[$module][$delta]->weight;
$block['region'] = $old_blocks[$module][$delta]->region;
$block['path'] = $old_blocks[$module][$delta]->path;
$block['custom'] = $old_blocks[$module][$delta]->custom;
$block['throttle'] = $old_blocks[$module][$delta]->throttle;
2002-10-26 15:17:26 +00:00
}
else {
2004-05-11 20:10:14 +00:00
$block['status'] = $block['weight'] = $block['region'] = $block['custom'] = 0;
$block['path'] = '';
2002-10-26 15:17:26 +00:00
}
// reinsert blocks into table
2003-11-28 20:03:00 +00:00
db_query("INSERT INTO {blocks} (module, delta, status, weight, region, path, custom, throttle) VALUES ('%s', '%s', %d, %d, %d, '%s', %d, %d)",
2004-05-11 20:10:14 +00:00
$block['module'], $block['delta'], $block['status'], $block['weight'], $block['region'], $block['path'], $block['custom'], $block['throttle']);
2002-10-26 15:17:26 +00:00
$blocks[] = $block;
2002-11-01 10:47:20 +00:00
2002-10-30 08:12:28 +00:00
// build array to sort on
$order[$order_by[0]][] = $block[$order_by[0]];
2002-10-26 15:17:26 +00:00
}
}
}
2002-10-30 08:12:28 +00:00
// sort
array_multisort($order[$order_by[0]], $order_by[1] ? $order_by[1] : SORT_ASC, $order_by[2] ? $order_by[2] : SORT_REGULAR, $blocks);
2002-10-26 15:17:26 +00:00
return $blocks;
}
2001-01-26 13:38:46 +00:00
2004-05-11 20:10:14 +00:00
/**
* Prepare the main block administration form.
*/
2002-10-26 15:17:26 +00:00
function block_admin_display() {
2001-01-26 13:38:46 +00:00
2002-10-30 08:12:28 +00:00
$blocks = _block_rehash();
2002-10-26 15:17:26 +00:00
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
// Fetch input formats used by admin-defined boxes.
$formats = array();
$result = db_query('SELECT bid, format FROM {boxes}');
while ($box = db_fetch_object($result)) {
$formats[$box->bid] = $box->format;
}
2004-08-19 15:41:57 +00:00
$header = array(t('Block'), t('Enabled'), t('Custom'), t('Throttle'), t('Weight'), t('Region'), t('Path'), array('data' => t('Operations'), 'colspan' => 2));
2002-12-29 16:03:01 +00:00
2002-10-26 15:17:26 +00:00
foreach ($blocks as $block) {
2004-05-11 20:10:14 +00:00
if ($block['module'] == 'block') {
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
if (filter_access($formats[$block['delta']])) {
$edit = l(t('edit'), 'admin/block/edit/'. $block['delta']);
}
2004-08-05 05:40:53 +00:00
$delete = l(t('delete'), 'admin/block/delete/'. $block['delta']);
2002-05-02 19:13:45 +00:00
}
2003-01-02 06:08:05 +00:00
else {
2004-05-11 20:10:14 +00:00
$edit = '';
$delete = '';
2003-01-02 06:08:05 +00:00
}
2002-12-29 16:03:01 +00:00
2004-05-11 20:10:14 +00:00
$rows[] = array($block['info'], array('data' => form_checkbox(NULL, $block['module'] .']['. $block['delta'] .'][status', 1, $block['status']), 'align' => 'center'), array('data' => form_checkbox(NULL, $block['module'] .']['. $block['delta'] .'][custom', 1, $block['custom']), 'align' => 'center'), array('data' => form_checkbox(NULL, $block['module'] .']['. $block['delta'] .'][throttle', 1, $block['throttle'], NULL, module_exist('throttle') ? NULL : array('disabled' => 'disabled')), 'align' => 'center'), form_weight(NULL, $block['module'] .']['. $block['delta'] .'][weight', $block['weight']), form_radios(NULL, $block['module'] .']['. $block['delta'] .'][region', $block['region'], array(t('left'), t('right'))), form_textfield(NULL, $block['module'] .']['. $block['delta'] .'][path', $block['path'], 10, 255),
2003-11-28 20:03:00 +00:00
$edit, $delete);
2000-12-23 15:20:10 +00:00
}
2001-01-26 13:38:46 +00:00
2004-05-11 20:10:14 +00:00
$output = theme('table', $header, $rows);
$output .= form_submit(t('Save blocks'));
2000-12-23 15:20:10 +00:00
2004-06-18 15:04:37 +00:00
return form($output, 'post', url('admin/block'));
2000-12-23 15:20:10 +00:00
}
2002-05-02 19:13:45 +00:00
function block_box_get($bid) {
2004-05-11 20:10:14 +00:00
return db_fetch_array(db_query('SELECT * FROM {boxes} WHERE bid = %d', $bid));
}
/**
2004-05-17 22:00:06 +00:00
* Menu callback; displays the block editing form.
*
* On edit, saves changes and displays the block overview.
2004-05-11 20:10:14 +00:00
*/
function block_box_edit($bid = 0) {
$edit = $_POST['edit'];
$op = $_POST['op'];
if ($op == t('Save block')) {
drupal_set_message(block_box_save($edit));
cache_clear_all();
$output = block_admin_display();
}
else {
if ($bid) {
$output = block_box_form(block_box_get($bid));
}
else {
$output = block_box_form();
}
}
print theme('page', $output);
2002-05-02 19:13:45 +00:00
}
function block_box_form($edit = array()) {
2004-06-21 21:11:36 +00:00
$group = form_textfield(t('Block title'), 'title', $edit['title'], 50, 64, t('The title of the block as shown to the 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
$group .= filter_form('format', $edit['format']);
2004-06-21 21:11:36 +00:00
$group .= form_textarea(t('Block body'), 'body', $edit['body'], 70, 10, t('The content of the block as shown to the user.'));
$group .= form_textfield(t('Block description'), 'info', $edit['info'], 50, 64, t('A brief description of your block. Used on the <a href="%overview">block overview page</a>.', array('%overview' => url('admin/block'))));
2002-05-02 19:13:45 +00:00
2004-05-11 20:10:14 +00:00
if ($edit['bid']) {
2004-06-21 21:11:36 +00:00
$group .= form_hidden('bid', $edit['bid']);
2002-05-02 19:13:45 +00:00
}
2004-06-21 21:11:36 +00:00
$group .= form_submit(t('Save block'));
2002-05-02 19:13:45 +00:00
2004-06-21 21:11:36 +00:00
$output = form_group(t('Add a new block'), $group);
return form($output);
2002-05-02 19:13:45 +00:00
}
function block_box_save($edit) {
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
if (!filter_access($edit['format'])) {
$edit['format'] = FILTER_FORMAT_DEFAULT;
2002-10-26 15:17:26 +00:00
}
2004-05-11 20:10:14 +00:00
if ($edit['bid']) {
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 {boxes} SET title = '%s', body = '%s', info = '%s', format = %d WHERE bid = %d", $edit['title'], $edit['body'], $edit['info'], $edit['format'], $edit['bid']);
2004-08-16 18:02:48 +00:00
return t('The block has been updated.');
2002-05-02 19:13:45 +00:00
}
else {
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 {boxes} (title, body, info, format) VALUES ('%s', '%s', '%s', %d)", $edit['title'], $edit['body'], $edit['info'], $edit['format']);
2004-08-16 18:02:48 +00:00
return t('The new block has been added.');
2002-05-02 19:13:45 +00:00
}
}
2004-05-11 20:10:14 +00:00
/**
2004-05-17 22:00:06 +00:00
* Menu callback; deletes a custom box, then displays the overview page.
2004-05-11 20:10:14 +00:00
*/
function block_box_delete($bid = 0) {
2002-05-02 19:13:45 +00:00
if ($bid) {
2004-05-11 20:10:14 +00:00
db_query('DELETE FROM {boxes} WHERE bid = %d', $bid);
2004-08-16 18:02:48 +00:00
drupal_set_message(t('The block has been deleted.'));
2004-05-11 20:10:14 +00:00
cache_clear_all();
2002-05-02 19:13:45 +00:00
}
2004-05-11 20:10:14 +00:00
print theme('page', block_admin_display());
2002-05-02 19:13:45 +00:00
}
2004-05-11 20:10:14 +00:00
/**
2004-05-17 22:00:06 +00:00
* Menu callback; displays the block overview page.
2004-05-11 20:10:14 +00:00
*/
2000-12-23 15:20:10 +00:00
function block_admin() {
2004-05-11 20:10:14 +00:00
$edit = $_POST['edit'];
$op = $_POST['op'];
2001-06-20 20:00:40 +00:00
2004-05-11 20:10:14 +00:00
if ($op == t('Save blocks')) {
drupal_set_message(block_admin_save($edit));
cache_clear_all();
2004-09-17 22:07:17 +00:00
drupal_goto($_GET['q']);
2001-06-20 20:00:40 +00:00
}
2004-05-11 20:10:14 +00:00
print theme('page', block_admin_display());
2000-12-23 15:20:10 +00:00
}
2001-11-01 11:00:51 +00:00
2004-05-11 20:10:14 +00:00
/**
* Implementation of hook_user().
*
* Allow users to decide which custom blocks to display when they visit
* the site.
*/
2004-06-27 19:10:52 +00:00
function block_user($type, $edit, &$user, $category = NULL) {
2002-05-02 19:13:45 +00:00
switch ($type) {
2004-05-17 14:50:58 +00:00
case 'form':
2004-06-27 19:10:52 +00:00
if ($category == 'account') {
$result = db_query('SELECT * FROM {blocks} WHERE custom = %d ORDER BY module, delta', 1);
while ($block = db_fetch_object($result)) {
$data = module_invoke($block->module, 'block', 'list');
if ($data[$block->delta]['info']) {
$form .= form_checkbox($data[$block->delta]['info'], "block][$block->module][$block->delta", 1, isset($user->block[$block->module][$block->delta]) ? $user->block[$block->module][$block->delta] : $block->status);
}
2002-05-12 15:40:57 +00:00
}
2004-06-27 19:10:52 +00:00
if (isset($form)) {
return array(array('title' => t('Block configuration'), 'data' => $form, 'weight' => 2));
}
2002-05-02 19:13:45 +00:00
}
2002-11-16 14:28:22 +00:00
break;
2004-05-11 20:10:14 +00:00
case 'validate':
if (!$edit['block']) {
$edit['block'] = array();
2002-09-30 09:19:50 +00:00
}
return $edit;
2002-05-02 19:13:45 +00:00
}
}
2003-11-19 16:13:07 +00:00
/**
* Return blocks available for current $user at $region.
*
2003-12-08 06:32:19 +00:00
* @param $region main|left|right
2003-11-19 16:13:07 +00:00
*
2003-12-08 06:32:19 +00:00
* @return array of block objects, indexed with <i>module</i>_<i>delta</i>
2003-11-19 16:13:07 +00:00
*
2004-06-18 15:04:37 +00:00
* @see <a href="http://drupal.org/node/1042" target="_top">[feature]
2003-11-19 16:13:07 +00:00
* Generic template design difficult w/o block region "look-ahead"</a>
2003-12-08 06:32:19 +00:00
* @todo add a proper primary key (bid) to the blocks table so we don't have
2003-11-19 16:13:07 +00:00
* to mess around with this <i>module</i>_<i>delta</i> construct. currently,
* "blocks" has no primary key defined (bad)!
*/
function block_list($region) {
2004-06-02 18:49:22 +00:00
global $user, $base_url;
2003-11-19 16:13:07 +00:00
static $blocks = array();
if (!isset($blocks[$region])) {
$blocks[$region] = array();
2004-05-11 20:10:14 +00:00
$result = db_query('SELECT * FROM {blocks} WHERE (status = 1 OR custom = 1) '. ($region != 'all' ? 'AND region = %d ' : '') .'ORDER BY weight, module', $region == 'left' ? 0 : 1);
2003-11-19 16:13:07 +00:00
while ($result && ($block = db_fetch_array($result))) {
2004-02-25 21:19:31 +00:00
// When the user's account setting is empty, we use the block's regular 'status' (which is the default)
if ($block['custom'] && $user->uid && !isset($user->block[$block['module']][$block['delta']])) {
$user->block[$block['module']][$block['delta']] = $block['status'];
}
2003-11-28 20:03:00 +00:00
2004-08-06 11:10:15 +00:00
// Determine block visibility
$enabled = $block['status'] && (!$user->uid || !$block['custom']);
$custom = $block['custom'] && $user->block[$block['module']][$block['delta']];
// Match path if necessary
if ($block['path']) {
$base = parse_url($base_url);
$session = session_name() .'='. session_id();
2004-08-06 11:11:30 +00:00
$url = str_replace(array($base['path'], '?'. $session), '', request_uri());
2004-08-06 20:15:32 +00:00
$url = ereg_replace('^/(\?q=)?', '', $url);
2004-08-06 11:11:30 +00:00
$matched = preg_match($block['path'], $url);
2004-08-06 11:10:15 +00:00
}
else {
$matched = true;
}
if (($enabled || $custom) && $matched) {
2003-11-28 20:03:00 +00:00
/*
2003-11-29 06:53:03 +00:00
** Check the current throttle status and see if block should be displayed
** based on server load.
2003-11-28 20:03:00 +00:00
*/
2004-05-11 20:10:14 +00:00
if (!($block['throttle'] && (module_invoke('throttle', 'status') > 4))) {
2004-08-22 17:03:42 +00:00
$array = module_invoke($block['module'], 'block', 'view', $block['delta']);
2004-09-08 15:38:26 +00:00
if (is_array($array)) {
2004-08-22 17:03:42 +00:00
$block = array_merge($block, $array);
}
2003-11-28 20:03:00 +00:00
}
2003-12-04 20:53:19 +00:00
if (isset($block['content']) && $block['content']) {
2003-11-19 16:13:07 +00:00
$blocks[$region]["$block[module]_$block[delta]"] = (object) $block;
}
}
}
}
return $blocks[$region];
}
2003-06-24 15:55:22 +00:00
?>
