Defaulted Taxonomy Terms for Custom Content Types

Background:

I'm developing a site with a large number of different content types and a very large number of categories. Many of the categories are due to the fact that my publication is issue based and chuncks of content are published simultaneously. In order to group content into an issue, it was suggested on the forums that I use the taxonomy system. Unfortunately this results in an unbelievably large number of items in a dropdown menu. It's quite unmanagable in its current state as I have about 12 years worth of weekly publications to put into the system.

I also needed to have custom output logic on many of these content types, but I wanted to make sure that all of these content types were searchable. The taxonomy system is good for this as well, but requiring that the author click to add one of twenty or so content types and then force them to select their categories as well is asking too much and would probably result in the author miscategorizing documents. Since taxonomy is used for selecting which documents to display in certain places, it's unacceptable to have such an easy source of user error.

My fix:

Default categories for a content type. This is really just a two-line patch:

taxonomy.module:442
-function taxonomy_node_form($type, $node = '', $help = NULL, $name = 'taxonomy') {
+function taxonomy_node_form($type, $node = '', $help = NULL, $name = 'taxonomy', $terms = 0) {

taxonomy.module:448
-$terms = 0;
+ // terms is defaulted on the argument list and passed through to the form generation code

This allows the content type to specify which taxonomy terms are selected by default when the object is created. Since content types must be created by coding, I didn't create a web-interface for this.

I also added an option to sort the taxonomy display in reverse-alpha for items of equal weights (manually specifying 600 weights in order to make the issue numbers sort in reverse cronological order wasn't an option). I'm not going to post my patch for that unless someone really wants it because it's trivial and most people probably wouldn't have use of it.

Problems with this fix:

It puts an important variable (for me) after two variables that I'm never going to change, but I also can't move the variables without introducing an API incompatability. Sometimes I wish php4 had keyword argument support.