Sensible status messages for forum admin

+1... this might be used during module installation for modules that require their own vocab or perhaps in the installer as a way to set up some default categories for "instant" site creation. Not cluttering the screen with lots of drupal_set_messages would be a good thing in these instances too.

I'm going to put this on hold until after the Drupal 4.6 release.

Definite +1 for HEAD.

Indeed that this is a very nice patch!
+1 from me either..

This patch needs to be updated with the check plain patch. The term name is not correctly escaped, but also, it should use theme('placeholder') for putting the term name into a message, instead of hardcoding <em> tags.

Committed to HEAD.

This patch caused the bug at http://drupal.org/node/22490. I am planning a patch that sets $edit['status'] (and returns $edit, per the previous behavior) instead of returning $status. Thoughts? Should be done tomorrow.

Well, I had considered the multiple return values, but then decided on the 'status' key mainly because of the nature of what an "object" is (or, rather, could be). Are we returning a database object, which has keys that specifically map to the term_data table (in which case, yes, 'status' is incorrect since it has no database comparison), or are we returning a 'term' object, which simply has data related to it (such as its last affected status)? I don't think either distinction has been made in Drupal core in any sort of common or suggested way, and felt that a modified $edit was "cleaner". Although, now that I think about it, there ARE various Drupal functions that iterate over an object's keys under the assumption that they DO relate to the table structure (node_save, I believe, comes to mind). So, perhaps your array return is the right idea after all. Either way, I'll be addressing it first thing tomorrow.

The committed patch breaks two things: the submission of new "free tagging" terms (needed the $tid from taxonomy_save_term) and the auto-creation of the "Forum" vocabulary (needed the $vid from taxonomy_save_vocabulary). The attached patch fixes the above by returning BOTH the $status and the $edit in taxonomy_save_term and taxonomy_save_vocabulary. This was implemented per drumm's suggestion in #10. Updating the issue to 'critical' and 'bug report'.

The patch looks ok to me.

New patch to use list() and array_values() instead, per Dries.

Committed to HEAD.