Split up node module

Renaming to match other issues, and bumping to critical because this is a core-required module.

node_admin_search() can be moved to the node.admin.inc file.

I'm not sure we should be putting page callbacks in content_types.inc. That seems to have other purposes. I'd rather keep page callbacks in their own files for cleanliness, and they should follow the naming convention. Things like node_add() should go in the pages.inc file.

I'm OK with leaving node_view() in the module, as it's probably the most-called page handler so it saves us a disk hit more often than not. node/%node/delete should go in a separate file, though.

Why node.content_forms.inc? Every other core module is using modulename.pages.inc. We should stick to that format for consistency, or else have node_view() in its very own node.pages.inc and the rest of the forms in node.content_forms.inc.

I've been leaving theme_ functions in the main .module file, because I don't fully know the potential issues with moving them. That's something to ask merlin about, since he and dvessel were doing all sorts of refactoring to theme functions, too, and I wanted to avoid clashing. Remember that anything except a page handler that needs to access a theme function will need to manually load the appropriate file first, which is icky. (How often that is for some theme functions I don't know, but I've been erring on the side of caution.)

Thanks for stepping up!

I will defer to merlinofchaos and dvessel regarding the theme functions. If we do decide to move those out, that's something that should then be done to other modules, too. (Oh, refactoring...)

Dries had objected to modulename.feeds.inc for feed-based pages on the grounds that it was too obscure to break handlers up that far. That's why I've not been splitting things up further. Every other module has been using modulename.pages.inc, so it's a question of which way we want to be unclear/inconsistent. I'm inclined to lean toward standardized naming, but am willing to be overruled on that.

I spoke to merlin about the theme functions. Turns out the theme registry hook can specify a theme function lives in another file, if you specify both the file and function keys. Just having a file key would mean it's a template file, but both makes it a function in an include file. So it would look like (I think):

function node_theme() {
  return array(
    'foo' => array(
      'file' => 'node.pages.inc',
      'function' => 'foo',
    ),
   // ...
  );
}

Since that gets more code out of the .module file without resulting in another manual include_once(), let's do that. I guess I need to go back and do that to the other modules now, too. *sigh*

I've run into one or two other functions like that which have to be in the main file for edge cases, so those two don't surprise me.

I'd disagree regarding node_admin_search(). It's an admin page so is not often called. Leaving it in the .module file makes that page very slightly faster, but every other page very slightly slower since it has to parse that function. Moving it to the separate file makes that page slightly slower, and every other slightly faster. For a 2 line function slightly is a small value, but we should be consistent and apply the same logic to the whole module. Ideally if there is a pages file then the .module file should have no page handlers in it at all (except node_view(), because the trade-off goes the other direction on that one since it's so commonly called).

Hm, I think we cross-posted there. :-) I'll give this a test tonight. Thanks.

Applies cleanly, I haven't found any pages it breaks, saves us about 1000 lines of code. I like. Thanks!

This patch needs a quick re-roll.

Committed to CVS HEAD. Thanks.