If I include book.module in a install profile, I get:

Fatal error: Call to undefined function _node_type_set_defaults() in ./modules/book/book.install on line 37

while doing a fresh install.

Comments

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented

Use of this function in book.install is modeled after its use in the default profile:

http://cvs.drupal.org/viewvc.py/drupal/drupal/profiles/default/default.p...

However, is it possible that the installer is trying to install book module when the node module is not yet installed?

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented
Status: Active » Postponed (maintainer needs more info)

can you re-confirm or give more details about your install profile?

asimmonds’s picture

asimmonds CreditAttribution: asimmonds commented

I have a install profile for my development sandbox that enables all the available core modules:

function sandboxall_profile_modules() {
  return array(
  'actions', 'aggregator', 'blog', 'blogapi', 'book',
  'color', 'comment', 'contact', 'dblog',
  'help', 'locale', 'menu', 'openid', 'path', 'php', 'poll',
  'profile', 'search', 'statistics', 'syslog', 'taxonomy',
  'throttle', 'tracker', 'translation', 'update', 'upload',
  );
}

note: Forum is missing from this list because of a similar problem: http://drupal.org/node/157519

When each of the _install() hooks are executed from the *.install files, all the tables have already been created but the modules have not yet been enabled or loaded (this is done mainly in drupal_install_modules() in includes/install.inc)

Maybe the solution is to enable and load the modules first before executing the .install hooks?
- The module enable/disable code in system_modules_submit() enables/disables modules first before calling drupal_install_modules()

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented
Component: book.module » install system
Status: Postponed (maintainer needs more info) » Active

Ok - so this sounds more like a broader installer system problem - the core (required) modules should be available to all the other modules when they are being enabled.

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented

is this still occuring?

beginner’s picture

beginner CreditAttribution: beginner commented
Component: install system » book.module

I think it would be a book.module bug.

When using an install profile, the modules - including core required modules - are NOT included, so the functions are not defined.
.install is supposed to install the DB tables only.
_book_install_type_create() cannot be run at that stage.

http://drupal.org/node/157519 (forum.install) was resolved when moving such function calls to hook_enable().

To reproduce bug: add 'book' in the list of modules in the default.profile in default_profile_module().
Install using the modified default profile.

Solution? move _book_install_type_create() to hook_enable(). ?

beginner’s picture

beginner CreditAttribution: beginner commented

Well... it might be an installer problem after all. See my mail to the dev list.

beginner’s picture

beginner CreditAttribution: beginner commented
Title: Fatal error if book.module is included in a install profile » Fatal error if book or other modules are included in a install profile
Version: 6.x-dev » 7.x-dev
Component: book.module » install system
Priority: Normal » Critical

Ok. Back to install system. See my post on the list, and replies:
http://lists.drupal.org/archives/development/2007-11/msg00590.html

A fix would require, I think, an API change. and it's too late for D6.
I have documented the bug here:
http://drupal.org/node/67921
http://drupal.org/node/67921/revisions/view/191746/222037

KarenS’s picture

KarenS CreditAttribution: KarenS commented
Version: 7.x-dev » 6.x-dev

Does the batch processing patch at the end of http://drupal.org/node/176003 fix the problem? If so, we could fix two problems with one patch with no need for an API change :)

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented

beginner: Well, if _install() hooks are not supposed to use API functions yet, we should fix book module, if it is misbehaving.

KarenS: it does not seem like that patch *loads* modules after they are enabled, it just separates enabling them one by one into a batch, so it might make the situation even worse (as it is now), with the previously installed modules not loaded yet, so the API functions are not usable still.

yched’s picture

yched CreditAttribution: yched commented

@Gabor : The patch in http://drupal.org/node/176003 precisely takes care of this. Modules are enabled as soon as they are installed, so that the drupal_bootstrap at next install.php (batch) request loads them for any dependant module to rely on.

I happened to try adding book.module to the list of enabled modules in order to test, and got bitten by the bug too - i thought it was caused by my modifications, though, and did not realize it was already a bug in current D6...

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented

yched: your comments seems to contradict. You say it solves the problem but then your patch testing did find the bug??

yched’s picture

yched CreditAttribution: yched commented

My testing when *developping* the patch did find the bug, and thus allowed me to take care of it in the patch I posted :-) Sorry for not being clear. The patch in http://drupal.org/node/176003 does fix the bug.

Besides, I should probably have posted in the patch's thread where you also cross-posted (saw that later).
http://drupal.org/node/176003

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented
Status: Active » Closed (duplicate)

Ah, yes. I see. So what is done here is that system module is installed first. Then a full bootstrap can be done, as it is indeed done in code carried over from before the patch (right after system module is enabled in the same request). Then the patch runs the module installs as profile tasks, so they run in a full bootstrap. So all previously enabled modules are available in all their glory.

Let's go to http://drupal.org/node/176003 then and fix both of the bugs at once.

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented

Install batches are committed, so this bug should also be fixed now. Feel free to retry and reopen if not fixed.