Make Node.module optional

This is an initial patch I've been working on this evening. We intend to update Taxonomy so it uses Field and AFAIK it doesn't require the hardcoded relationship with Node anymore that is has now. If we pull that off, this patch doesn't have to worry about making Taxonomy independent from Node anymore.

The last submitted patch failed testing.

Even without decoupling taxonomy from node, it could always have node as a dependency until that's done.

What do we do about the default front page? This is set to node, which will not be possible anymore with this patch.

Also, should we set Node as a dependency for modules like Blog, Forum, etc? They don't rely on Node's API, but are of no use without it. Therefore it's not strictly necessary to set dependencies, but it may very well prevent confused users.

Slightly improved patch. SimpleTest often cannot perform the tests at all or returns PHP notices and warnings, which I haven't yet been able to solve.

The last submitted patch failed testing.

Simplified the code. The patch also prevents a redudant menu rebuild at admin/build/modules. One of the tests still fails, I'll check that out ASAP.

All tests pass now. However, I'd like to get rid of the call to menu_rebuild() in system_modules(), which is now necessary for MenuIncTestCase->testMenuName() to pass. Simply replacing the drupalGet() call to /admin/build/modules with menu_rebuild() didn't work.

I've seen people complaining about node module being required in #drupal before.

However - it should still be enabled in the 'expert' profile - same as we enable stuff like dblog, block and menu in there to avoid a completely unusable (as opposed to just stripped down) site on install.

Things like moving hard coded stuff from system.module to hook_modules_enabled() are good cleanup regardless of whether node.module is optional or not, so I'd support those changes in their own right too.

IMO the Expert profile should only enable the absolutely necessary modules and Block, because the interface is nothing without a module that displays menus.

Discussed this with catch and we agreed that change belongs in a different issue. This patch updates the Expert install profile.

When the patch is applied, and node module disabled, the home page of the site, gives you a "Page not found" error. Actually, I don't know how to solve that problem, maybe just make a static page, like the welcome screen after install, that doesn't depend on the node system.
I set this "needs work" because of this, if this issue is neglectable or should be part of a follow-up issue, set back to NR or RTBC.

One other note: node module currently does not let itself be unistalled. Would that also be part of a followup issue?

The problem with the front page is a known problem (See comment #4). Node uninstallation should be part of this patch as well. Just haven't got around to improving the patch yet.

Sorry...

Moved all the (un)installation code from system.install to node.install. Functionality seems to work. Let's see what our bot says.

The last submitted patch failed testing.

Defining Node as the first module to be installed in the default profile fixed the problem. It works as far as I can see, but it seems there still is some sort of a dependency that hasn't been dealt with yet.

Install profiles don't pay attention to dependencies defined in info files, it seems, so the fix in #17 was no workaround after all. This patch introduces a Node dependency for Comment

The last submitted patch failed testing.

My editor made me omit a comma.

We still need to decide if we're going to do something about the default front page, which is automatically being set to 'node'. This will not be a problem with the current installation profiles, since both enable Node. The point is that System module (I believe) uses 'node' as the default value and therefore is still dependent on Node in some way.

The attached patch moves the front page help you see if no nodes have been promoted to common.inc and menu.inc. Node now removes it's variables from $conf and cleares the variables cache at uninstallation as well.

(Drupal.org somehow manages to post a comment with the patch, but without the body text I just typed :S )

The last submitted patch failed testing.

Adding an omitted drupal_set_title() prevents a lot of errors.

The last submitted patch failed testing.

The frontpage issue is moved to #419950: Remove /node as default front page.

Still works perfectly, including uninstall (It's kind of scary though to see your database without the node table...).
One thing I noticed, but that's probably not related / not in the scope of this issue: After disabling node module, node actions are still available. Same goes for comment actions though...

Good observation! They shouldn't be available at all after uninstallation.

There's a patch for that: #420124: DX: Remove module actions on uninstall

The last submitted patch failed testing.

The last submitted patch failed testing.

This is a great idea - node module is unnecessary if you're using Drupal for a completely custom web app that has no need for traditional content management. In fact, you may have forgotten it, but node module has been optional before in Drupal's history. It was optional in 4.6 and previous versions, and was only made required in 4.7. IMHO making it required was a mistake, and I think this is a great opportunity to undo that mistake.

re: #20 (the default front page being 'node'), I don't think this is an issue. Core only ships with 2 install profiles, and both of them enable node.module by default.

If you're advanced enough to be writing a custom install profile that disables node module, then I think it's reasonable to expect that you would know to change the default front page to something else (also using the install profile). However, we should add something to this effect in the 'how to write an install profile' docs.

Similarly, if you're advanced enough to be disabling node.module post-install, then you should know to re-configure the front page on the 'site information' page. Although it wouldn't hurt to add a drupal_set_message() call to hook_uninstall() in node module, telling users that they might need to re-configure their front page setting.

The problem is that currently the help text shown right after installation is part of Node.module. Also, we should make sure no errors are thrown on the front page if there is no Node.module. Core is responsible for this. The front page issue is being dealt with in #126221: Make 'node' empty text themable.. In this issue we focus on everything else related to making Node optional.

Note: remove $type = 'node' from menu_get_object().

I still miss the point of having a content management system without the code to handle nodes (which are nothing else than content). How many people would use Drupal without nodes? It would not be possible to use CCK; Views would just be able to show a list of users, or taxonomy terms (which would not have any meaning, without nodes); every module that handles content depends on node.module.

The only case I can see, on using Drupal without node.module is for static output, or for output given by PHP files independent from Drupal; in both the cases, there would not be the need of using Drupal at all.

This patch is about making it optional, not about removing it.

I understood that, but what is the purpose to make it optional when 99% of Drupal sites will need to enable it? It can only cause the modules to write more code just to verify node.module is active, or add a line more in their .info file.

Drupal doesn't need it, ergo it should not be required. That core currently depends on it is mostly due to a lot of cruft. Like the first post in this issue says, making it optional makes Drupal address a wider audience.

Good idea! Front page for anonymous is "mission", for authorized - /user so why /node not /user for anonymous?

This patch is an exact follow-up of the previous one. It applies and it works to a certain degree, but it has not been tested extensively.

A little research supports this patch. #21084: Node module is not marked "required", but is required by other required modules made node required because there were so many direct calls into the module however that clearly was before module dependencies got in. The oldest debate (2003) I was able to find is http://osdir.com/ml/php.drupal.devel/2003-12/msg00176.html and even there it was asked not to make it required.

New patch. I guess I'm about halfway in updating all code. All include files have been updated and all modules from Aggregator to Locale.

Some notes:
- node_types_rebuild() has gone from drupal_flush_all_caches(). This means we manually need to check of next to every call to drupal_flush_all_caches() if a call to node_types_rebuild() is desired.
- menu_rebuild() has gone from node_types_rebuild().
- menu_get_object($type = 'node', $position = 1, $path = NULL) is now menu_get_object($type, $position = 1, $path = NULL).
- I am unsure what to do with menu_tree_collect_node_links() and menu_tree_check_access(). I could wrap them in a lot of module_exist() calls, but that won't make things prettier.
- I am unsure what to do with the 'default_nodes_main' variable/setting in system_site_information_settings(). I don't see any existing page under Site configuration where it would fit.
- I am unsure what to do with 'toggle_node_user_pictures' in theme.inc due to lack of experience with themes. Is there a way to make themes provide this setting?
- {block_node_type} is now {node_block_visibility} and content type visibility settings are now set through hook_form_FORM_ID_alter() and enforced through hook_block_list_alter().
- Promoted to front page is now Promoted to /node. Although correct, I do feel we need to think of a better description.
- field_attach_prepare_translation() in field.attach.inc contains Node-specific code. There's a TODO comment that expresses concerns as to whether that particular function belongs in Field API or not.
- theme_options_none() accepts $node_type as third argument. The function is only being called from options.module. Can somebody confirm this $node_type argument can indeed be removed? There are other occurrences of node-specific code in options.module as well. I have no experience with Field whatsoever, so somebody else needs to check this out.
- The variable 'language_content_type_$type' has been renamed to 'node_type_language_$type', because its form elements have been moved from Locale to Node.
- Node has been renamed to Content. This is because with this patch Node appears in the modules list and without renaming it, it would have been the only occurence of 'node' in the UI. Bojhan and catch agree.

The last submitted patch failed testing.

The part of the patch that updates Locale has been moved to #540294: Decouple Locale from Node.

Do not even think of touching promoted in this issue as it'll be a huge distraction. #404300: "Promote to front page" is a misnomer

The part of the patch that updates Locale has been moved to #543804: Decouple Block from Node.

Path.module contains a lot of code that is specific for creating aliases for nodes. Since Path is an API and UI for creating aliases for any path, I believe it should not contain code to create paths for specific entities. How do you think about this?

The part of the patch that updates Help has been moved to #543906: Decouple Help from Node.

The part of the patch that updates Profile has been moved to #543920: Decouple Profile from Node.

The part of the patch that updates System has been moved to #545524: Decouple System from Node.