Jump to:
| Project: | Drupal core |
| Version: | 6.19 |
| Component: | documentation |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
Here's a backtrace:
* Called from: C:\www\webapps\drupal6\includes\form.inc, function: _element_info, line: 869,
args: Array ( [0] => Array ( [0] => fieldset [1] => fieldset ....
* Called from: C:\www\webapps\drupal6\includes\form.inc, function: form_builder, line: 924,
args: Array ( [0] => user_profile_form [1] => Array ( [#type] => Array ....
* Called from: C:\www\webapps\drupal6\includes\form.inc, function: form_builder, line: 400,
args: Array ( [0] => user_profile_form [1] => Array ( [#uid] => 1 ....
* Called from: C:\www\webapps\drupal6\includes\form.inc, function: drupal_process_form, line: 119,
args: Array ( [0] => user_profile_form [1] => Array ( [#uid] => 1 ....
* Called from: C:\www\webapps\drupal6\modules\user\user.pages.inc, function: drupal_get_form, line: 239,
args: Array ( [0] => user_profile_form [1] => stdClass Object ( [uid] => 1 ....
* Called from: , function: user_edit, line: ,
args: Array ( [0] => stdClass Object ( [uid] => 1 [name] => admin ....
* Called from: C:\www\webapps\drupal6\includes\menu.inc, function: call_user_func_array, line: 348,
args: Array ( [0] => user_edit [1] => Array ( [0] => stdClass Object ....
* Called from: C:\www\webapps\drupal6\index.php, function: menu_execute_active_handler, line: 18,
args: Array ( ) .
PHP 5.2.5
Comments
#1
#2
What more do you need?
#3
Steps to reproduce, whether this happens on a core installation, or only on an install with modules (or a custom module). The full backtrace. In case of a custom module, the code that adds fields to the user edit form.
#4
That is about as much backtrace as I know how to get.
As far as I can tell the only modules that should be involved are Profile and User Terms. I don't recall seeing this before the current version of User_Terms and 6.17 were installed, but we also added our 13th profile field at the same time.. Everything seems to work, except the fieldset label.
I suspect it's something I did, but I need help finding it.
#5
Please reopen if you are able to confirm it is a core bug.
#6
I have confirmed this is a core "bug" (although it may just be poor docs). It happens on at least 6.17 and 6.19. You should be able to reproduce it by saving profile data in the "account" category. That is the default category in user_save, which is how my site is propagating the profile values. If I go into the profile_fields table and change all the category values to anything else, this issue goes away. Or I can make it go away by changing function profile_form_profile, adding a check for "account':
while ($field = db_fetch_object($result)) {$category = trim($field->category);
if (!isset($fields[$category]) && $category != 'account') {
$fields[$category] = array('#type' => 'fieldset', '#title' => check_plain($category), '#weight' => $weight++);
}
#7
If you try to add a profile field to the "account" category, you will see the nice error message:
As a consequence, this seems to work as designed. Manually messing up with the database is not a use case that Drupal supports :)
#8
Then the API documentation needs to clearly state that "account" is reserved, and not that it is for profile fields (which is what it says now). As a matter of fact, it kind of implies that you should use "account."
#9
Changing title, as I think this is what you are now advocating be changed on
http://api.drupal.org/api/function/user_save/6
to take into account what Damien said in #7 above.
Please change title and clarify if that is not what you meant.
#10
That is good enough. Unfortunately my PC crashed and I haven't dowloaded the API stuff to this company PC, so I can't do it myself.