drupal/database/database.mysql

829 lines
21 KiB
Plaintext
Raw Normal View History

-- MySQL dump 8.22
--
-- Host: localhost Database: drupal_devel
-- Server version 3.23.52-nt
--
-- Table structure for table 'access'
--
CREATE TABLE access (
aid tinyint(10) NOT NULL auto_increment,
mask varchar(255) NOT NULL default '',
type varchar(255) NOT NULL default '',
status tinyint(2) NOT NULL default '0',
PRIMARY KEY (aid)
) TYPE=MyISAM;
--
-- Table structure for table 'accesslog'
--
CREATE TABLE accesslog (
2004-11-28 13:35:11 +00:00
aid int(10) NOT NULL auto_increment,
title varchar(255) default NULL,
path varchar(255) default NULL,
url varchar(255) default NULL,
hostname varchar(128) default NULL,
uid int(10) unsigned default '0',
timer int(10) unsigned NOT NULL default '0',
timestamp int(11) unsigned NOT NULL default '0',
KEY accesslog_timestamp (timestamp),
PRIMARY KEY (aid)
) TYPE=MyISAM;
--
-- Table structure for table 'aggregator_category'
--
CREATE TABLE aggregator_category (
cid int(10) NOT NULL auto_increment,
title varchar(255) NOT NULL default '',
description longtext NOT NULL,
block tinyint(2) NOT NULL default '0',
PRIMARY KEY (cid),
UNIQUE KEY title (title)
) TYPE=MyISAM;
--
-- Table structure for table 'aggregator_category_feed'
--
CREATE TABLE aggregator_category_feed (
fid int(10) NOT NULL default '0',
cid int(10) NOT NULL default '0',
PRIMARY KEY (fid,cid)
) TYPE=MyISAM;
--
-- Table structure for table 'aggregator_category_item'
--
CREATE TABLE aggregator_category_item (
iid int(10) NOT NULL default '0',
cid int(10) NOT NULL default '0',
PRIMARY KEY (iid,cid)
) TYPE=MyISAM;
--
-- Table structure for table 'aggregator_feed'
--
CREATE TABLE aggregator_feed (
fid int(10) NOT NULL auto_increment,
title varchar(255) NOT NULL default '',
url varchar(255) NOT NULL default '',
refresh int(10) NOT NULL default '0',
checked int(10) NOT NULL default '0',
link varchar(255) NOT NULL default '',
description longtext NOT NULL,
image longtext NOT NULL,
etag varchar(255) NOT NULL default '',
modified int(10) NOT NULL default '0',
block tinyint(2) NOT NULL default '0',
PRIMARY KEY (fid),
UNIQUE KEY link (url),
UNIQUE KEY title (title)
) TYPE=MyISAM;
--
-- Table structure for table 'aggregator_item'
--
CREATE TABLE aggregator_item (
iid int(10) NOT NULL auto_increment,
fid int(10) NOT NULL default '0',
title varchar(255) NOT NULL default '',
link varchar(255) NOT NULL default '',
author varchar(255) NOT NULL default '',
description longtext NOT NULL,
timestamp int(11) default NULL,
PRIMARY KEY (iid)
) TYPE=MyISAM;
--
-- Table structure for table 'authmap'
--
CREATE TABLE authmap (
aid int(10) unsigned NOT NULL auto_increment,
uid int(10) NOT NULL default '0',
authname varchar(128) NOT NULL default '',
module varchar(128) NOT NULL default '',
PRIMARY KEY (aid),
UNIQUE KEY authname (authname)
) TYPE=MyISAM;
--
-- Table structure for table 'blocks'
--
CREATE TABLE blocks (
module varchar(64) DEFAULT '' NOT NULL,
delta varchar(32) NOT NULL default '0',
status tinyint(2) DEFAULT '0' NOT NULL,
weight tinyint(1) DEFAULT '0' NOT NULL,
region tinyint(1) DEFAULT '0' NOT NULL,
custom tinyint(2) DEFAULT '0' NOT NULL,
throttle tinyint(1) DEFAULT '0' NOT NULL,
visibility tinyint(1) DEFAULT '0' NOT NULL,
pages text NOT NULL
) TYPE=MyISAM;
--
-- Table structure for table 'book'
--
CREATE TABLE book (
nid int(10) unsigned NOT NULL default '0',
parent int(10) NOT NULL default '0',
weight tinyint(3) NOT NULL default '0',
log longtext,
PRIMARY KEY (nid),
KEY parent (parent)
) TYPE=MyISAM;
--
-- Table structure for table 'boxes'
--
CREATE TABLE boxes (
bid tinyint(4) NOT NULL auto_increment,
title varchar(64) NOT NULL default '',
body longtext,
info varchar(128) NOT NULL default '',
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
format int(4) NOT NULL default '0',
PRIMARY KEY (bid),
UNIQUE KEY info (info)
) TYPE=MyISAM;
--
-- Table structure for table 'cache'
--
2001-07-08 15:01:37 +00:00
CREATE TABLE cache (
cid varchar(255) NOT NULL default '',
data longtext,
expire int(11) NOT NULL default '0',
created int(11) NOT NULL default '0',
headers text,
PRIMARY KEY (cid),
2004-09-15 20:34:35 +00:00
INDEX expire (expire)
) TYPE=MyISAM;
--
-- Table structure for table 'comments'
--
CREATE TABLE comments (
cid int(10) NOT NULL auto_increment,
pid int(10) NOT NULL default '0',
nid int(10) NOT NULL default '0',
uid int(10) NOT NULL default '0',
subject varchar(64) NOT NULL default '',
comment longtext NOT NULL,
hostname varchar(128) NOT NULL default '',
timestamp int(11) NOT NULL default '0',
score mediumint(9) NOT NULL default '0',
status tinyint(3) unsigned NOT NULL default '0',
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
format int(4) NOT NULL default '0',
thread varchar(255) NOT NULL,
users longtext,
name varchar(60) default NULL,
mail varchar(64) default NULL,
homepage varchar(255) default NULL,
PRIMARY KEY (cid),
KEY lid (nid)
) TYPE=MyISAM;
--
-- Table structre for table 'contact'
--
CREATE TABLE contact (
category varchar(255) NOT NULL default '',
recipients longtext NOT NULL default '',
reply longtext NOT NULL default '',
PRIMARY KEY (category)
) TYPE=MyISAM;
--
-- Table structre for table 'node_comment_statistics'
--
CREATE TABLE node_comment_statistics (
nid int(10) unsigned NOT NULL auto_increment,
last_comment_timestamp int(11) NOT NULL default '0',
last_comment_name varchar(60) default NULL,
last_comment_uid int(10) NOT NULL default '0',
comment_count int(10) unsigned NOT NULL default '0',
PRIMARY KEY (nid),
KEY node_comment_timestamp (last_comment_timestamp)
) TYPE=MyISAM;
--
-- Table structure for table 'directory'
--
Oops, a rather large commit: - Changed meta.module, node.module and index.php to use comma-seperated lists of attributes rather then "foo=a,bar=b" lists. This makes it a a lot easier to use both modules. In addition, error handling can be discarded as it can't be made any simpler, really ... It fits rather nicely in Drupal's design so I'm getting more and more happy with this meta.module (but we are not 100% there yet). - node.module, node.inc: + Improved the node-related admin interface so that navigating back and forth the administrative menus is made both easier and faster. + Removed some redundant database fields from the node table. See 2.00-to-x.xx.sql! + Added 2 news hooks called "node_insert" and "node_update". Just like this is the case with the existing hook "node_delete" these new hooks will automatically get called when a node has been inserted or udpated. Note that this is an optional call-back that only needs to be implemented when required. With the addition of these two hooks, the node mechanism (version 1) is pretty well completed. - watchdog.module: + Fixed bug whit the 'regular messages' query in the watchdog.module. - book.module: + Fixed bug in book.module: the 'parent' was not set properly when updating a book page. + Made it so that older versions of a book page are automatically reactived upon deletion of the most recent version, i.e. when doing a version roll-back. - comment.inc: + Undid Remco's patch to comment.inc; it does not work in some cases. - conf.module: + Fine-tuned some of the options in conf.module a bit. - marvin.theme: + Visual changes to make it look better on Windows browsers. Mind to give some feedback on this? + Fixed 3 HTML typos/bugs. + XHTML-ified the theme at a best effort basis; I didn't carry the XHTML specification with me. + Made use of the theme_slogan variable to display the site's slogan. + As soon we have at least one valid XHTML theme we can wonder on how to integrate other XML namespaces (cfr. MathML story at drop.org). - database.mysql: + Updated database.mysql so that it contains all the latest "database patches".
2001-06-17 18:31:25 +00:00
CREATE TABLE directory (
link varchar(255) NOT NULL default '',
name varchar(128) NOT NULL default '',
mail varchar(128) NOT NULL default '',
slogan longtext NOT NULL,
mission longtext NOT NULL,
timestamp int(11) NOT NULL default '0',
PRIMARY KEY (link)
) TYPE=MyISAM;
Oops, a rather large commit: - Changed meta.module, node.module and index.php to use comma-seperated lists of attributes rather then "foo=a,bar=b" lists. This makes it a a lot easier to use both modules. In addition, error handling can be discarded as it can't be made any simpler, really ... It fits rather nicely in Drupal's design so I'm getting more and more happy with this meta.module (but we are not 100% there yet). - node.module, node.inc: + Improved the node-related admin interface so that navigating back and forth the administrative menus is made both easier and faster. + Removed some redundant database fields from the node table. See 2.00-to-x.xx.sql! + Added 2 news hooks called "node_insert" and "node_update". Just like this is the case with the existing hook "node_delete" these new hooks will automatically get called when a node has been inserted or udpated. Note that this is an optional call-back that only needs to be implemented when required. With the addition of these two hooks, the node mechanism (version 1) is pretty well completed. - watchdog.module: + Fixed bug whit the 'regular messages' query in the watchdog.module. - book.module: + Fixed bug in book.module: the 'parent' was not set properly when updating a book page. + Made it so that older versions of a book page are automatically reactived upon deletion of the most recent version, i.e. when doing a version roll-back. - comment.inc: + Undid Remco's patch to comment.inc; it does not work in some cases. - conf.module: + Fine-tuned some of the options in conf.module a bit. - marvin.theme: + Visual changes to make it look better on Windows browsers. Mind to give some feedback on this? + Fixed 3 HTML typos/bugs. + XHTML-ified the theme at a best effort basis; I didn't carry the XHTML specification with me. + Made use of the theme_slogan variable to display the site's slogan. + As soon we have at least one valid XHTML theme we can wonder on how to integrate other XML namespaces (cfr. MathML story at drop.org). - database.mysql: + Updated database.mysql so that it contains all the latest "database patches".
2001-06-17 18:31:25 +00:00
--
-- Table structure for table 'files'
--
CREATE TABLE files (
fid int(10) unsigned NOT NULL default '0',
nid int(10) unsigned NOT NULL default '0',
filename varchar(255) NOT NULL default '',
filepath varchar(255) NOT NULL default '',
filemime varchar(255) NOT NULL default '',
filesize int(10) unsigned NOT NULL default '0',
list tinyint(1) unsigned NOT NULL default '0',
PRIMARY KEY (fid)
) TYPE=MyISAM;
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
--
-- Table structure for table 'filter_formats'
--
CREATE TABLE filter_formats (
format int(4) NOT NULL auto_increment,
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
name varchar(255) NOT NULL default '',
roles varchar(255) NOT NULL default '',
cache tinyint(2) NOT NULL default '0',
PRIMARY KEY (format)
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
) TYPE=MyISAM;
--
-- Table structure for table 'filters'
--
CREATE TABLE filters (
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
format int(4) NOT NULL default '0',
module varchar(64) NOT NULL default '',
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
delta tinyint(2) DEFAULT '0' NOT NULL,
weight tinyint(2) DEFAULT '0' NOT NULL,
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
INDEX (weight)
) TYPE=MyISAM;
--
-- Table structure for table 'flood'
--
CREATE TABLE flood (
event varchar(64) NOT NULL default '',
hostname varchar(128) NOT NULL default '',
timestamp int(11) NOT NULL default '0'
) TYPE=MyISAM;
--
-- Table structure for table 'forum'
--
2003-02-07 08:06:37 +00:00
CREATE TABLE forum (
nid int(10) unsigned NOT NULL default '0',
tid int(10) unsigned NOT NULL default '0',
PRIMARY KEY (nid),
2004-02-21 19:16:48 +00:00
KEY tid (tid)
) TYPE=MyISAM;
Oops, a rather large commit: - Changed meta.module, node.module and index.php to use comma-seperated lists of attributes rather then "foo=a,bar=b" lists. This makes it a a lot easier to use both modules. In addition, error handling can be discarded as it can't be made any simpler, really ... It fits rather nicely in Drupal's design so I'm getting more and more happy with this meta.module (but we are not 100% there yet). - node.module, node.inc: + Improved the node-related admin interface so that navigating back and forth the administrative menus is made both easier and faster. + Removed some redundant database fields from the node table. See 2.00-to-x.xx.sql! + Added 2 news hooks called "node_insert" and "node_update". Just like this is the case with the existing hook "node_delete" these new hooks will automatically get called when a node has been inserted or udpated. Note that this is an optional call-back that only needs to be implemented when required. With the addition of these two hooks, the node mechanism (version 1) is pretty well completed. - watchdog.module: + Fixed bug whit the 'regular messages' query in the watchdog.module. - book.module: + Fixed bug in book.module: the 'parent' was not set properly when updating a book page. + Made it so that older versions of a book page are automatically reactived upon deletion of the most recent version, i.e. when doing a version roll-back. - comment.inc: + Undid Remco's patch to comment.inc; it does not work in some cases. - conf.module: + Fine-tuned some of the options in conf.module a bit. - marvin.theme: + Visual changes to make it look better on Windows browsers. Mind to give some feedback on this? + Fixed 3 HTML typos/bugs. + XHTML-ified the theme at a best effort basis; I didn't carry the XHTML specification with me. + Made use of the theme_slogan variable to display the site's slogan. + As soon we have at least one valid XHTML theme we can wonder on how to integrate other XML namespaces (cfr. MathML story at drop.org). - database.mysql: + Updated database.mysql so that it contains all the latest "database patches".
2001-06-17 18:31:25 +00:00
--
-- Table structure for table 'history'
--
CREATE TABLE history (
uid int(10) NOT NULL default '0',
nid int(10) NOT NULL default '0',
timestamp int(11) NOT NULL default '0',
PRIMARY KEY (uid,nid)
) TYPE=MyISAM;
--
-- Table structure for table 'locales_meta'
--
CREATE TABLE locales_meta (
locale varchar(12) NOT NULL default '',
name varchar(64) NOT NULL default '',
enabled int(2) NOT NULL default '0',
isdefault int(2) NOT NULL default '0',
plurals int(1) NOT NULL default '0',
formula varchar(128) NOT NULL default '',
PRIMARY KEY (locale)
) TYPE=MyISAM;
--
-- Table structure for table 'locales_source'
--
CREATE TABLE locales_source (
lid int(11) NOT NULL auto_increment,
location varchar(255) NOT NULL default '',
source blob NOT NULL,
PRIMARY KEY (lid)
) TYPE=MyISAM;
--
-- Table structure for table 'locales_target'
--
CREATE TABLE locales_target (
lid int(11) NOT NULL default '0',
translation blob NOT NULL,
locale varchar(12) NOT NULL default '',
plid int(11) NOT NULL default '0',
plural int(1) NOT NULL default '0',
KEY lid (lid),
KEY lang (locale),
KEY plid (plid),
KEY plural (plural)
) TYPE=MyISAM;
--
-- Table structure for table 'menu'
--
CREATE TABLE menu (
mid int(10) unsigned NOT NULL default '0',
pid int(10) unsigned NOT NULL default '0',
path varchar(255) NOT NULL default '',
title varchar(255) NOT NULL default '',
description varchar(255) NOT NULL default '',
weight tinyint(4) NOT NULL default '0',
type int(2) unsigned NOT NULL default '0',
PRIMARY KEY (mid)
) TYPE=MyISAM;
--
-- Table structure for table 'moderation_filters'
--
CREATE TABLE moderation_filters (
fid int(10) unsigned NOT NULL auto_increment,
filter varchar(255) NOT NULL default '',
minimum smallint(6) NOT NULL default '0',
PRIMARY KEY (fid)
) TYPE=MyISAM;
--
-- Table structure for table 'moderation_roles'
--
CREATE TABLE moderation_roles (
rid int(10) unsigned NOT NULL default '0',
mid int(10) unsigned NOT NULL default '0',
value tinyint(4) NOT NULL default '0',
KEY idx_rid (rid),
KEY idx_mid (mid)
) TYPE=MyISAM;
--
-- Table structure for table 'moderation_votes'
--
CREATE TABLE moderation_votes (
mid int(10) unsigned NOT NULL auto_increment,
vote varchar(255) default NULL,
weight tinyint(4) NOT NULL default '0',
PRIMARY KEY (mid)
) TYPE=MyISAM;
--
-- Table structure for table 'node'
--
CREATE TABLE node (
nid int(10) unsigned NOT NULL auto_increment,
2005-08-08 18:51:48 +00:00
type varchar(32) NOT NULL default '',
title varchar(128) NOT NULL default '',
uid int(10) NOT NULL default '0',
status int(4) NOT NULL default '1',
created int(11) NOT NULL default '0',
changed int(11) NOT NULL default '0',
comment int(2) NOT NULL default '0',
promote int(2) NOT NULL default '0',
moderate int(2) NOT NULL default '0',
teaser longtext NOT NULL,
body longtext NOT NULL,
revisions longtext NOT NULL,
sticky int(2) NOT NULL default '0',
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
format int(4) NOT NULL default '0',
PRIMARY KEY (nid),
KEY node_type (type(4)),
KEY node_title_type (title,type(4)),
KEY status (status),
KEY uid (uid),
KEY node_moderate (moderate),
KEY node_promote_status (promote, status),
KEY node_created (created),
KEY node_changed (changed),
KEY node_status_type (status, type, nid)
) TYPE=MyISAM;
2004-08-06 09:49:25 +00:00
--
-- Table structure for table `node_access`
--
CREATE TABLE node_access (
nid int(10) unsigned NOT NULL default '0',
gid int(10) unsigned NOT NULL default '0',
realm varchar(255) NOT NULL default '',
grant_view tinyint(1) unsigned NOT NULL default '0',
grant_update tinyint(1) unsigned NOT NULL default '0',
grant_delete tinyint(1) unsigned NOT NULL default '0',
PRIMARY KEY (nid,gid,realm)
) TYPE=MyISAM;
--
-- Table structure for table 'profile_fields'
--
CREATE TABLE profile_fields (
fid int(10) NOT NULL auto_increment,
title varchar(255) default NULL,
name varchar(128) default NULL,
explanation TEXT default NULL,
category varchar(255) default NULL,
page varchar(255) default NULL,
type varchar(128) default NULL,
weight tinyint(1) DEFAULT '0' NOT NULL,
required tinyint(1) DEFAULT '0' NOT NULL,
register tinyint(1) DEFAULT '0' NOT NULL,
visibility tinyint(1) DEFAULT '0' NOT NULL,
options text,
KEY category (category),
UNIQUE KEY name (name),
PRIMARY KEY (fid)
);
--
-- Table structure for table 'profile_values'
--
CREATE TABLE profile_values (
fid int(10) unsigned default '0',
uid int(10) unsigned default '0',
value text,
KEY uid (uid),
KEY fid (fid)
);
--
-- Table structure for table 'url_alias'
--
CREATE TABLE url_alias (
2003-09-30 20:59:26 +00:00
pid int(10) unsigned NOT NULL auto_increment,
src varchar(128) NOT NULL default '',
dst varchar(128) NOT NULL default '',
PRIMARY KEY (pid),
UNIQUE KEY dst (dst),
KEY src (src)
) TYPE=MyISAM;
--
-- Table structure for table 'permission'
--
2002-04-29 16:59:49 +00:00
CREATE TABLE permission (
rid int(10) unsigned NOT NULL default '0',
perm longtext,
2002-04-29 16:59:49 +00:00
tid int(10) unsigned NOT NULL default '0',
KEY rid (rid)
) TYPE=MyISAM;
--
-- Table structure for table 'poll'
--
CREATE TABLE poll (
nid int(10) unsigned NOT NULL default '0',
runtime int(10) NOT NULL default '0',
polled longtext NOT NULL,
active int(2) unsigned NOT NULL default '0',
PRIMARY KEY (nid)
) TYPE=MyISAM;
--
-- Table structure for table 'poll_choices'
--
CREATE TABLE poll_choices (
chid int(10) unsigned NOT NULL auto_increment,
nid int(10) unsigned NOT NULL default '0',
chtext varchar(128) NOT NULL default '',
chvotes int(6) NOT NULL default '0',
chorder int(2) NOT NULL default '0',
PRIMARY KEY (chid),
KEY nid (nid)
) TYPE=MyISAM;
--
-- Table structure for table 'role'
--
CREATE TABLE role (
rid int(10) unsigned NOT NULL auto_increment,
name varchar(32) NOT NULL default '',
PRIMARY KEY (rid),
UNIQUE KEY name (name)
) TYPE=MyISAM;
2001-07-08 15:01:37 +00:00
--
-- Table structure for table 'search_index'
--
2002-04-29 16:59:49 +00:00
CREATE TABLE search_index (
word varchar(50) NOT NULL default '',
- Patch #12232 by Steven/UnConed: search module improvements. 1) Clean up the text analyser: make it handle UTF-8 and all sorts of characters. The word splitter now does intelligent splitting into words and supports all Unicode characters. It has smart handling of acronyms, URLs, dates, ... 2) It now indexes the filtered output, which means it can take advantage of HTML tags. Meaningful tags (headers, strong, em, ...) are analysed and used to boost certain words scores. This has the side-effect of allowing the indexing of PHP nodes. 3) Link analyser for node links. The HTML analyser also checks for links. If they point to a node on the current site (handles path aliases) then the link's words are counted as part of the target node. This helps bring out commonly linked FAQs and answers to the top of the results. 4) Index comments along with the node. This means that the search can make a difference between a single node/comment about 'X' and a whole thread about 'X'. It also makes the search results much shorter and more relevant (before this patch, comments were even shown first). 5) We now keep track of total counts as well as a per item count for a word. This allows us to divide the word score by the total before adding up the scores for different words, and automatically makes noisewords have less influence than rare words. This dramatically improves the relevancy of multiword searches. This also makes the disadvantage of now using OR searching instead of AND searching less problematic. 6) Includes support for text preprocessors through a hook. This is required to index Chinese and Japanese, because these languages do not use spaces between words. An external utility can be used to split these into words through a simple wrapper module. Other uses could be spell checking (although it would have no UI). 7) Indexing is now regulated: only a certain amount of items will be indexed per cron run. This prevents PHP from running out of memory or timing out. This also makes the reindexing required for this patch automatic. I also added an index coverage estimate to the search admin screen. 8) Code cleanup! Moved all the search stuff from common.inc into search.module, rewired some hooks and simplified the functions used. The search form and results now also use valid XHTML and form_ functions. The search admin was moved from search/configure to admin/search for consistency. 9) Improved search output: we also show much more info per item: date, author, node type, amount of comments and a cool dynamic excerpt à la Google. The search form is now much more simpler and the help is only displayed as tips when no search results are found. 10) By moving all search logic to SQL, I was able to add a pager to the search results. This improves usability and performance dramatically.
2004-10-31 03:03:27 +00:00
sid int(10) unsigned NOT NULL default '0',
type varchar(16) default NULL,
- Patch #12232 by Steven/UnConed: search module improvements. 1) Clean up the text analyser: make it handle UTF-8 and all sorts of characters. The word splitter now does intelligent splitting into words and supports all Unicode characters. It has smart handling of acronyms, URLs, dates, ... 2) It now indexes the filtered output, which means it can take advantage of HTML tags. Meaningful tags (headers, strong, em, ...) are analysed and used to boost certain words scores. This has the side-effect of allowing the indexing of PHP nodes. 3) Link analyser for node links. The HTML analyser also checks for links. If they point to a node on the current site (handles path aliases) then the link's words are counted as part of the target node. This helps bring out commonly linked FAQs and answers to the top of the results. 4) Index comments along with the node. This means that the search can make a difference between a single node/comment about 'X' and a whole thread about 'X'. It also makes the search results much shorter and more relevant (before this patch, comments were even shown first). 5) We now keep track of total counts as well as a per item count for a word. This allows us to divide the word score by the total before adding up the scores for different words, and automatically makes noisewords have less influence than rare words. This dramatically improves the relevancy of multiword searches. This also makes the disadvantage of now using OR searching instead of AND searching less problematic. 6) Includes support for text preprocessors through a hook. This is required to index Chinese and Japanese, because these languages do not use spaces between words. An external utility can be used to split these into words through a simple wrapper module. Other uses could be spell checking (although it would have no UI). 7) Indexing is now regulated: only a certain amount of items will be indexed per cron run. This prevents PHP from running out of memory or timing out. This also makes the reindexing required for this patch automatic. I also added an index coverage estimate to the search admin screen. 8) Code cleanup! Moved all the search stuff from common.inc into search.module, rewired some hooks and simplified the functions used. The search form and results now also use valid XHTML and form_ functions. The search admin was moved from search/configure to admin/search for consistency. 9) Improved search output: we also show much more info per item: date, author, node type, amount of comments and a cool dynamic excerpt à la Google. The search form is now much more simpler and the help is only displayed as tips when no search results are found. 10) By moving all search logic to SQL, I was able to add a pager to the search results. This improves usability and performance dramatically.
2004-10-31 03:03:27 +00:00
fromsid int(10) unsigned NOT NULL default '0',
fromtype varchar(16) default NULL,
score int(10) unsigned default NULL,
KEY sid (sid),
KEY fromsid (fromsid),
- Patch #12232 by Steven/UnConed: search module improvements. 1) Clean up the text analyser: make it handle UTF-8 and all sorts of characters. The word splitter now does intelligent splitting into words and supports all Unicode characters. It has smart handling of acronyms, URLs, dates, ... 2) It now indexes the filtered output, which means it can take advantage of HTML tags. Meaningful tags (headers, strong, em, ...) are analysed and used to boost certain words scores. This has the side-effect of allowing the indexing of PHP nodes. 3) Link analyser for node links. The HTML analyser also checks for links. If they point to a node on the current site (handles path aliases) then the link's words are counted as part of the target node. This helps bring out commonly linked FAQs and answers to the top of the results. 4) Index comments along with the node. This means that the search can make a difference between a single node/comment about 'X' and a whole thread about 'X'. It also makes the search results much shorter and more relevant (before this patch, comments were even shown first). 5) We now keep track of total counts as well as a per item count for a word. This allows us to divide the word score by the total before adding up the scores for different words, and automatically makes noisewords have less influence than rare words. This dramatically improves the relevancy of multiword searches. This also makes the disadvantage of now using OR searching instead of AND searching less problematic. 6) Includes support for text preprocessors through a hook. This is required to index Chinese and Japanese, because these languages do not use spaces between words. An external utility can be used to split these into words through a simple wrapper module. Other uses could be spell checking (although it would have no UI). 7) Indexing is now regulated: only a certain amount of items will be indexed per cron run. This prevents PHP from running out of memory or timing out. This also makes the reindexing required for this patch automatic. I also added an index coverage estimate to the search admin screen. 8) Code cleanup! Moved all the search stuff from common.inc into search.module, rewired some hooks and simplified the functions used. The search form and results now also use valid XHTML and form_ functions. The search admin was moved from search/configure to admin/search for consistency. 9) Improved search output: we also show much more info per item: date, author, node type, amount of comments and a cool dynamic excerpt à la Google. The search form is now much more simpler and the help is only displayed as tips when no search results are found. 10) By moving all search logic to SQL, I was able to add a pager to the search results. This improves usability and performance dramatically.
2004-10-31 03:03:27 +00:00
KEY word (word)
) TYPE=MyISAM;
--
-- Table structure for table 'search_total'
--
CREATE TABLE search_total (
word varchar(50) NOT NULL default '',
count int(10) unsigned default NULL,
PRIMARY KEY (word)
) TYPE=MyISAM;
--
2003-12-30 18:33:44 +00:00
-- Table structure for table 'sessions'
--
CREATE TABLE sessions (
uid int(10) unsigned NOT NULL,
sid varchar(32) NOT NULL default '',
hostname varchar(128) NOT NULL default '',
timestamp int(11) NOT NULL default '0',
cache int(11) NOT NULL default '0',
session longtext,
KEY uid (uid),
PRIMARY KEY (sid),
KEY timestamp (timestamp)
) TYPE=MyISAM;
--
-- Table structure for table 'sequences'
--
CREATE TABLE sequences (
name varchar(255) NOT NULL default '',
id int(10) unsigned NOT NULL default '0',
PRIMARY KEY (name)
2002-04-29 16:59:49 +00:00
) TYPE=MyISAM;
--
-- Table structure for table 'node_counter'
--
CREATE TABLE node_counter (
nid int(11) NOT NULL default '0',
totalcount bigint(20) unsigned NOT NULL default '0',
daycount mediumint(8) unsigned NOT NULL default '0',
timestamp int(11) unsigned NOT NULL default '0',
PRIMARY KEY (nid),
KEY totalcount (totalcount),
KEY daycount (daycount),
KEY timestamp (timestamp)
) TYPE=MyISAM;
--
-- Table structure for table 'system'
--
2002-04-29 16:59:49 +00:00
CREATE TABLE system (
filename varchar(255) NOT NULL default '',
name varchar(255) NOT NULL default '',
type varchar(255) NOT NULL default '',
description varchar(255) NOT NULL default '',
status int(2) NOT NULL default '0',
throttle tinyint(1) DEFAULT '0' NOT NULL,
bootstrap int(2) NOT NULL default '0',
PRIMARY KEY (filename)
2002-08-21 04:20:06 +00:00
) TYPE=MyISAM;
--
-- Table structure for table 'term_data'
--
2002-04-29 16:59:49 +00:00
CREATE TABLE term_data (
tid int(10) unsigned NOT NULL auto_increment,
vid int(10) unsigned NOT NULL default '0',
name varchar(255) NOT NULL default '',
description longtext,
2002-04-29 16:59:49 +00:00
weight tinyint(4) NOT NULL default '0',
PRIMARY KEY (tid),
2002-04-29 16:59:49 +00:00
KEY vid (vid)
) TYPE=MyISAM;
--
-- Table structure for table 'term_hierarchy'
--
2002-04-29 16:59:49 +00:00
CREATE TABLE term_hierarchy (
tid int(10) unsigned NOT NULL default '0',
parent int(10) unsigned NOT NULL default '0',
KEY tid (tid),
KEY parent (parent)
) TYPE=MyISAM;
--
-- Table structure for table 'term_node'
--
2002-04-29 16:59:49 +00:00
CREATE TABLE term_node (
nid int(10) unsigned NOT NULL default '0',
tid int(10) unsigned NOT NULL default '0',
KEY nid (nid),
KEY tid (tid),
PRIMARY KEY (tid,nid)
2002-04-29 16:59:49 +00:00
) TYPE=MyISAM;
--
-- Table structure for table 'term_relation'
--
2002-04-29 16:59:49 +00:00
CREATE TABLE term_relation (
tid1 int(10) unsigned NOT NULL default '0',
tid2 int(10) unsigned NOT NULL default '0',
KEY tid1 (tid1),
KEY tid2 (tid2)
) TYPE=MyISAM;
--
-- Table structure for table 'term_synonym'
--
2002-04-29 16:59:49 +00:00
CREATE TABLE term_synonym (
tid int(10) unsigned NOT NULL default '0',
name varchar(255) NOT NULL default '',
KEY tid (tid),
KEY name (name(3))
) TYPE=MyISAM;
--
-- Table structure for table 'users'
--
CREATE TABLE users (
uid int(10) unsigned NOT NULL default '0',
name varchar(60) NOT NULL default '',
pass varchar(32) NOT NULL default '',
mail varchar(64) default '',
mode tinyint(1) NOT NULL default '0',
sort tinyint(1) default '0',
threshold tinyint(1) default '0',
theme varchar(255) NOT NULL default '',
signature varchar(255) NOT NULL default '',
created int(11) NOT NULL default '0',
access int(11) NOT NULL default '0',
login int(11) NOT NULL default '0',
status tinyint(4) NOT NULL default '0',
timezone varchar(8) default NULL,
language varchar(12) NOT NULL default '',
picture varchar(255) NOT NULL DEFAULT '',
init varchar(64) default '',
data longtext,
PRIMARY KEY (uid),
UNIQUE KEY name (name),
KEY access (access)
) TYPE=MyISAM;
--
-- Table structure for table 'users_roles'
--
CREATE TABLE users_roles (
uid int(10) unsigned NOT NULL default '0',
rid int(10) unsigned NOT NULL default '0',
PRIMARY KEY (uid, rid)
) TYPE=MyISAM;
--
-- Table structure for table 'variable'
--
CREATE TABLE variable (
name varchar(48) NOT NULL default '',
value longtext NOT NULL,
PRIMARY KEY (name)
) TYPE=MyISAM;
--
-- Table structure for table 'vocabulary'
--
2002-04-29 16:59:49 +00:00
CREATE TABLE vocabulary (
vid int(10) unsigned NOT NULL auto_increment,
name varchar(255) NOT NULL default '',
description longtext,
help varchar(255) NOT NULL default '',
2002-04-29 16:59:49 +00:00
relations tinyint(3) unsigned NOT NULL default '0',
hierarchy tinyint(3) unsigned NOT NULL default '0',
multiple tinyint(3) unsigned NOT NULL default '0',
required tinyint(3) unsigned NOT NULL default '0',
tags tinyint(3) unsigned NOT NULL default '0',
module varchar(255) NOT NULL default '',
2002-04-29 16:59:49 +00:00
weight tinyint(4) NOT NULL default '0',
PRIMARY KEY (vid)
2002-04-29 16:59:49 +00:00
) TYPE=MyISAM;
--
-- Table structure for table 'vocabulary_node_types'
--
CREATE TABLE vocabulary_node_types (
vid int(10) unsigned NOT NULL DEFAULT '0',
type varchar(16) NOT NULL DEFAULT '',
PRIMARY KEY (vid, type)
) TYPE=MyISAM;
--
-- Table structure for table 'watchdog'
--
CREATE TABLE watchdog (
wid int(5) NOT NULL auto_increment,
uid int(10) NOT NULL default '0',
type varchar(16) NOT NULL default '',
message longtext NOT NULL,
severity tinyint(3) unsigned NOT NULL default '0',
link varchar(255) NOT NULL default '',
location varchar(128) NOT NULL default '',
referer varchar(128) NOT NULL default '',
hostname varchar(128) NOT NULL default '',
timestamp int(11) NOT NULL default '0',
PRIMARY KEY (wid)
) TYPE=MyISAM;
--
-- Insert some default values
--
2001-04-16 13:39:40 +00:00
INSERT INTO system VALUES ('modules/block.module','block','module','',1,0,0);
INSERT INTO system VALUES ('modules/comment.module','comment','module','',1,0,0);
INSERT INTO system VALUES ('modules/filter.module','filter','module','',1,0,0);
INSERT INTO system VALUES ('modules/help.module','help','module','',1,0,0);
INSERT INTO system VALUES ('modules/node.module','node','module','',1,0,0);
INSERT INTO system VALUES ('modules/page.module','page','module','',1,0,0);
INSERT INTO system VALUES ('modules/story.module','story','module','',1,0,0);
INSERT INTO system VALUES ('modules/system.module','system','module','',1,0,0);
INSERT INTO system VALUES ('modules/taxonomy.module','taxonomy','module','',1,0,0);
INSERT INTO system VALUES ('modules/user.module','user','module','',1,0,0);
INSERT INTO system VALUES ('modules/watchdog.module','watchdog','module','',1,0,0);
INSERT INTO system VALUES ('themes/engines/phptemplate/phptemplate.engine', 'phptemplate', 'theme_engine', '', 1, 0, 0);
INSERT INTO system VALUES ('themes/bluemarine/page.tpl.php', 'bluemarine', 'theme', 'themes/engines/phptemplate/phptemplate.engine', 1, 0, 0);
INSERT INTO users (uid, name, mail) VALUES ('0', '', '');
INSERT INTO users_roles (uid, rid) VALUES (0, 1);
INSERT INTO role (rid, name) VALUES (1, 'anonymous user');
INSERT INTO permission VALUES (1,'access content',0);
INSERT INTO role (rid, name) VALUES (2, 'authenticated user');
INSERT INTO permission VALUES (2,'access comments, access content, post comments, post comments without approval',0);
REPLACE variable SET name='update_start', value='s:10:"2005-03-21";';
REPLACE variable SET name='theme_default', value='s:10:"bluemarine";';
REPLACE blocks SET module = 'user', delta = '0', status = '1';
REPLACE blocks SET module = 'user', delta = '1', status = '1';
INSERT INTO sequences (name, id) VALUES ('menu_mid', 1);
INSERT INTO node_access VALUES (0, 0, 'all', 1, 0, 0);
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
INSERT INTO filter_formats VALUES (1,'Filtered HTML',',1,2,',1);
INSERT INTO filter_formats VALUES (2,'PHP code','',0);
INSERT INTO filter_formats VALUES (3,'Full HTML','',1);
INSERT INTO filters VALUES (1,'filter',0,0);
INSERT INTO filters VALUES (1,'filter',2,1);
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
INSERT INTO filters VALUES (2,'filter',1,0);
INSERT INTO filters VALUES (3,'filter',2,0);
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
INSERT INTO variable (name,value) VALUES ('filter_html_1','i:1;');
INSERT INTO locales_meta (locale, name, enabled, isdefault) VALUES ('en', 'English', '1', '1');
INSERT INTO url_alias (src, dst) VALUES ('node/feed', 'rss.xml');
INSERT INTO variable (name, value) VALUES ('node_options_forum', 'a:1:{i:0;s:6:"status";}');