This patch adds folksonomy support to Drupal (named internally as "Free tagging"). In a nutshell, the core difference is the input method: unlike normal taxonomies which are administratively controlled, a "free tagging" vocabulary allows tag creation when the node is submitted. It does this through an text input box, as opposed to a dropdown or selectbox. This patch:
* Removes the useless "Preview form" of a vocabulary.
* Alters the vocabulary table to include a new "tags" column.
* Adds a new "Free tagging" preference on vocabulary creation/editing.
* Modifies the vocabulary overview to support pagers for free tagging vocabs.
The new code integrates tightly with the existing taxonomy code. The only additional processing occurs on node save and edit, where we parse through the tags associated with a node. All other display (and thus, code) remains the same.
1. Removed a duplicate line from the changes to update.inc.
2. Excluded the session.inc changes: they did not make sense to me.
3. Excluded the search related changes in the node and search module. According to Steven these are not correct.
- Mass-delete functionality (with confirmation)
- Flexible filtering for the overview table based on status, type and taxonomy.
- Missing drupal_goto's
- Clean up watchdog messages
- Remove some dead code
- Clean up various SQL queries: removing literally inserted data (db_escape_string is evil!), fixing single "%" which should be "%%", fixing integers being compared as strings.
* Less logic in theme code.
* Encourages use of the menu system.
* Easier to find where a title or breadcrumb comes from in other people's code because there are less places to look. Look in menu and then grep for the appropriate set function. Looking for calls to theme_page() is hard because there are too many of them.
* Very slightly more efficient.
Read the manual for pg_escape_string: "Use of this function is recommended instead of addslashes()." Or read sqlite_escape_string: "addslashes() should NOT be used to quote your strings for SQLite queries; it will lead to strange results when retrieving your data."
The primary goal of this patch is to take the 'custom' and 'path' columns of the block overview page and make them into something understandable. As of Drupal 4.5 'custom' lacked an explanation which wasn't buried in help text and path required dealing with regular expressions.
Every block now has a configuration page to control these options. This gives more space to make form controls which do not require a lengthy explanation. This page also gives modules a chance to put their block configuration options in a place that makes sense using new operations in the block hook.
The only required changes to modules implementing hook_block() is to be careful about what is returned. Do not return anything if $op is not 'list' or 'view'. Once this change is made, modules will still be compatible with Drupal 4.5. Required changes to core modules are included in this path.
An additional optional change to modules is to implement the additional $op options added. 'configure' should return a string containing the configuration form for the block with the appropriate $delta. 'configure save' will come with an additional $edit argument, which will contain the submitted form data for saving. These changes to core modules are also included in this patch.
Dries Buytaert
Steven Wittens