- #23685: urlencode() profile field names and values in the URL (any dynamic data in an url should be urlencoded to prevent characters like # and & from being interpreted by the browser/server).

- Patch #19451 by JonBob: improved consistency of module descriptions.  We should write guidelines for this -- maybe in the PHPDoc code of the _help hook.

- Patch #15937 by wulff: made it so that titles of profile fields only need to be unique within a single category.

- Small bugfix + small improvement.

   * 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.

- Patch 13180 by chx: renamed check_query() to db_escape_string() and implemtented it properly per database backend.

  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."

  + Drupal 4.4 stored profile data in the serialized user->data column. Drupal 4.5 stores profile data in tables (but user->data is still available and used for other stuff, like locale or themes).  The update from 4.4 to 4.5 didn't remove the old data from the user->data column properly, because there is no mechanism in user_save to do so (it did try to unset the fields, but this has no effect).

  + On registration, hook_user('insert') is invoked after saving the data column. This means that any module-specific data is put into the data field. We cannot move hook_user('insert') higher up, because before that point, we do not have a complete $user object yet.

- Bugfix: making changes to the user profiles should flush the cache.

- Patch #6500 by Mathias with help from Steven: made it possible to add fields to the registration form.  This feature used to exist.

- Patch #8179 by JonBob: reintroduced menu caching.

- Patch by JonBob: for consistency and readability, add brief descriptions of each source file inside the @file comment block at the head of the file. This helps with Doxygen indexing, and also allows neophytes to see what a file does immediately on opening the source, regardless of the organization of the hooks.

- Code improvements by Stefan: use capital letters for header titles (and added some missing t() functions).

- Code improvements by Stefan: made all status messages consistent (and easier to translate).

- Restoring broken update path.
- Adding birthday/date function back, with update path.
- Show private fields when viewing your own profile, or for admins.
- Do not allow browsing of private fields for non admins (403)
- Throw a 404 for browsing unbrowsable fields, rather than an SQL error
- Fixing input processing: nothing is filtered twice anymore, and I replaced several strip_tags with specialchars (more flexible).
- Minor admin UI tweaks + added friendly field type names.

- Modified patch #9924 by njivi: added a basic member list to the profile module.  (If this deprecates the memberlist module, it ought to be deprecated.)
  I removed the permission njivi introduced and made the page title match the link title.

- Patch #9865 by njivy: avoid mangling %'s in the profile SQL query.

- Patch #9866 by njivy: when the links are generated for each item in a list-type profile field, double quotes in the item name can break the link. To fix this, this patch gives drupal_specialchars() the ENT_QUOTES parameter to convert quotes into HTML entities. This fix is also applied to selection-type profile fields which can have the same problem.

- Patch #9478 by JonBob: allow printf-style arguments in pager_query.

  Currently pager_query() is the black sheep of the database query family, because it does not allow for printf-style arguments to be inserted in the query. This is a problem because it introduces developer confusion when moving from an unpaged query to a paged one, and it encourages substitution of variables directly into the query, which can bypass our check_query() security feature.

  This patch adds this ability to pager_query(). The change is backwards-compatible, but a couple calls to the function in core have been changed to use the new capability.

- More tab-improvements by JonBob: improved support for the default tabs!

- Usability improvement: users can also separate 'list items' (i.e. favorite
  movies) using a comma.  Only few users actually read the form description,
  it seems ...

- Patch by Steven and me: refactored the form handling of nodes. The node system is now using form_set_error() and friends like the rest of Drupal does. This makes for both a consistent user experience and consistent code. It simplifies the forms and validation code, however, it does change the node API slightly:

    * The _validate hook and the _nodeapi('validate') hook of the node API (1) no longer take an 'error' parameter and (2) should no longer return an error array. To set an error, call form_set_error().

    * The _form hook of the node module no longer takes a form hook and should not worry about displaying errors. Ditto for _nodeapi('form_post') and _nodeapi('form_pre').

$ diffstat user.patch
database/database.mysql |    4
database/database.pgsql |    2
database/updates.inc    |   10 -
modules/block.module    |   20 +-
modules/locale.module   |    9
modules/profile.module  |  108 +++++++----
modules/system.module   |    8
modules/user.module     |  456 +++++++++++++++++++-----------------------------
8 files changed, 289 insertions(+), 328 deletions(-)

More functionality, less code.  Here is a list of the changes:

- Some user API changes:
   + When $type is 'form', you have to return an associative array of groups.  In turn, each group is an array with a 'title', 'data' and 'weight'.
   + A new $type has been added, namely 'categories'.  User settings can be organized in categories.  Categories can be sorted, as can the groups within a category.  (Ordering 'categories' is somewhat broken due to a bug in the menu system.)

- The 'my account > edit' page will use subtabs for each 'category'.  Read: you can break down the account settings into multiple subpages.

- Profile module improvements:
   + Added support for private fields to the profile module!
   + Improved workflow of profile administration pages.
   + Improved the form descriptions.

- Code improvements:
   + Unified user_edit() and user_admin_edit().
   + Unified and cleaned up the validation code.  Fixed some validation glitches too.

- Fixed administration pages being broken due to tabs changes, improved form
  handling and form descriptions and fixed an incorrect title.

Tabs patch!

CHANGES
-------

 + Introduced tabs. First, we extended the menu system to support tabs. Next, a tab was added for every link that was (1) an administrative action other than the implicit 'view' (2) relevant to that particular page only. This is illustrated by the fact that all tabs are verbs and that clicking a page's tab leads you to a subpage of that page.

 + Flattened the administration menu. The tabs helped simplify the navigation menu as I could separate 'actions' from 'navigation'. In addition, I removed the 'administer > configuration'-menu, renamed 'blocks' to 'sidebars' which I hope is a bit more descriptive, and made a couple more changes. Earlier, we already renamed 'taxonomy' to 'categorization' and we move 'statistics' under 'logs'.

 + Grouped settings. All settings have been grouped under 'administer > settings'.

TODO
----

 + Update core themes: only Xtemplate default supports tabs and even those look ugly.  Need help.

 + Update contributed modules.  The menu() hook changed drastically.  Updating your code adhere the new menu() function should be 90% of the work.  Moreover, ensure that your modue's admin links are still valid and that URLs to node get updated to the new scheme ('node/view/x' -> 'node/x').

- Improved form handling.

  + Introduced two new functions:
      1. form_set_error($name, $message): files an error against the form
         element with the specified  $name.
      2. form_has_errors(): returns true if errors has been filed against
         form elements.

  + Updated the form handling:
       1. The form_ functions will add 'class="error"' when a form field
          has been found to be erroneous.
       2. The error message is passed to theme_form_element() when the
          particular form field has been found to be erroneous.

  + I updated the user and profile module to take advantage of these new
    functions.

  + IMPORTANT: the _user() hook changed.  The 'validate' case should no
    longer retun an error message when something goes wrong but should
    set it with form_set_error().

- Patch #7585 by Gerhard: extra data added by profile.module to the user
  object got saved in the user's data column even if there is a dedicated
  table for that information.

- Making sure profile fields are saved properly.

- Fixed bug #7406: User delete hook incorrect params.

- Added support for 403 handling.  Patch by JonBob.  As a side benefit,
  administrators will be able to define a custom 403 page, just as they
  can define 404 pages now.

  This needs to be documented in the "Changes since / migrating to ..."
  pages.