CCK 6.x Cannot Be Set Up in Install Profiles

I ran into this also. When install.inc calls the drupal_check_profile() function, it loads all the needed .install files. Unfortunately the database's system table doesn't exist yet, so any calls to drupal_get_path() throw a PHP error and the installation fails.

It looks like the Date module package is already familiar with this problem, and has solved it by creating a date_load() function to be called from the install profile that loads the necessary includes.

This patch mimics that approach for use in CCK, applies to DRUPAL-6--2 branch.

Well I was mimicking the Date package, but looks like KarenS is too fast for me :)

This patch mimics the approach used by the latest version of the Date package, where dependent modules are simply manually enabled when they're needed. So now all CCK dependent module simply call module_enable('content') in their install hooks.

I'm not sure I understand the patch.
The intent of the incriminated include_once() line is to ensure content.module file is loaded even when updates are being run on diabled cck / field modules.

The patch replaces it with simply enabling content.module when a field module gets enabled, which :
- doesn't cover the case above
- shouldn't be needed according to module dependency ?

The problem is that in install profiles, the "system" database table isn't available. Calls to "drupal_get_path()" ultimately query the system table, and since it's not around, a mySQL error is thrown and the installation fails.

The original issue this all stems from is #209041: optionwidgets.install calls content_notify, where the include_once was originally added.

To reproduce, add "content" and "text" modules to the default.profile and try to install Drupal. To get extra fun, put them in the wrong order, with "text" before "content".

As for this being the correct solution... I don't think it is either. It's what date.module was doing so I assumed it would work fine. Instead, I'd recommend we use drupal_load() every time we need the module file, as including module files is it's entire purpose (like module_load_include() for include files).

This patch makes it so that CCK can be installed though install profiles, and with the modules in any order. Drupal does not install the modules in dependency order when using an install profile. Alternatively, we can cut out all the includes entirely if we decide that install profiles should just put modules in the right order.

It looks like in Drupal 6, all enabled modules are always loaded while running update.php (this should address the issue yched raised in #5). To test the content_* functions, I added a pseudo update the text.install just to check function availability. Remove the include_once() at the top of the text.install file, then add this update:

function text_update_6002() {
  $ret = array();
  if (function_exists('content_database_info')) {
    $ret[] = array('success' => TRUE, 'query' => 'content_database_info exists');
  }
  if (function_exists('content_notify')) {
    $ret[] = array('success' => TRUE, 'query' => 'content_notify exists');
  }
  return $ret;
}

Run update 6002, and the functions should exist.

There is another complication -- in D6 all modules that are in the folder get their updates run EVEN IF THEY'RE NOT ENABLED. And for extra fun, they get updated in a random order that ignores weights and dependencies.

Then on top of that if you have a module that is dependent on another module and the other module is not enabled (Like when you change dependencies in the code, which I did in the Date module) you end up with the dependent module disabled even if the module that depends on it is enabled, breaking all kinds of things. There are a couple core issues about these problems, but nothing done with it yet.

I don't know that my solution was the right one, it was basically a desperation move after trying other things that all broke in one setup or another.

As a re: to quicksketch's #6, I think I'm all for 'install profiles should just put modules in the right order'.

I'm not sure where this puts us wrt the 'ensure content.module is loaded when running updates for text.module even when both are disabled' issue. It looks like this still requires some explicit loading, right ?

The problem with #6 that install profiles should put modules in right order is that the update will *not* put them in the right order, so we still can't make assumptions about that. But profiles are part of install, not update, right? And I think core now *does* put modules in the right order for installs, just not for updates.

I must be missing something, but I don't understand how #7 will do anything :/

I agree we don't need to enable the modules, just include them (enabling was to fix a different problem in the date module). I think we're good if we either explicitly include any necessary files in every function or create a text_load() function that includes everything and invoke it from every function. Either one will get the includes out of the global space, which is the main problem.

sunfish62, you're request is beyond the abilities of the CCK team. It'll require changes to Drupal core to effectively make it so that you can specify modules in any order in install profiles. The solution posted in#6 just makes it so that you can 1) install CCK at all and 2) install the included sub-modules in any order.

KarenS: Core does not put modules in the right order when using an install profile (though it does when you enable several modules at once after installation). In an install profile, core uses the order that the modules are specified by the profile. I'm all for not using my temporary fix that makes it so CCK can be installed in any order, because it doesn't solve the larger problem that core should really handle for us.

sunfish... just do everthing manually if you gotta... figure out what functions you need to run from the .install files... it will a least get the job done if core isn't prepared to do the job properly yet.

Let's recap on the problem here:

- Drupal core checks the requirements of modules before allowing installation in a profile.
- Because hook_requirements() lives in the .install file, Drupal loads that file.
- Any use of the database (such as using the drupal_get_path() function) immediately when loading the file will cause installation to fail, because the database has no tables in it.

I doubt that we'll be able to correct this in Drupal 6 (anyone looked at the RTBC list recently?) so I think our only option is to do all module includes in every function when needed.

Subscribe

Bumping to critical, RC5 blocker.

quicksketch : thx for the recap, this is welcome.
Couldn''t we simply get away with calling drupal_load('module', 'content'); at the top-level of all our .install files ?

Unfortunately drupal_load() follows the same path as drupal_get_path().

drupal_load() => drupal_get_filename() => db_query("SELECT filename FROM {system} WHERE name = '%s' AND type = '%s'", $name, $type))

There is a check for db_is_active() before doing the query... but it looks like the db is active, there just aren't any tables in it yet :P Maybe we could correct this in core simply by setting the $active_db to FALSE when doing the check? I'm not sure if that'd be considered a hack.

Hm, too bad. I just stopped at the db_active() check and thought it would be ok.
OK, so here's the candidate patch. Removes all top-level includes, and calls drupal_load('module', 'content') in any function (including updates) that makes use of content's API.

I tested it to work OK for a D5 -> D6 upgrade with all cck modules disabled.
Can we have a final test that it works OK for an install profile that sets up CCK ?

updated patch after #289138: Locked field support.

subscribing

questions:
1- Isn't the installation profile taking dependencies into account to know which modules to install first? (I thought it did)
2- What would be the consequences of an install profile which remove the line 6 of all sub-modules of CCK?
3- Can't be treated separately the install profile and the update cases?

yched said this is critical in #19.

sunfish62: Patches always apply to the latest -dev code.

Guys,

patch is working. (against CVS).

However, the CVS version still complain about " Fatal error: Class 'views_handler_filter_float' not found in ...cck/includes/content.views.inc on line 187". Since its not related to this bug, marking it as tested.

regards,

massa

brmassa : 'Patch is working' is not very explicit.
Can you confirm that you could install CCK as part of an install profile ?

+ The error you see is because you need Views 6.x-2.x-dev, not RC1

Yves,

sorry. i meant it installed correctly using a profile.

i got the error, but all tables from all cck modules were created as expected (i saw them on phpmyadmin). The error means that the install phase was complete, coz was called by normal Views operation.

regards,

massa

Yves,

i did again the install (with views), successfully.

regards,

massa

sunfish62 : You need to follow 'view all releases' on views project page. Then, it's at the bottom of the page. Not the most obvious place, I agree.
Direct link is http://drupal.org/node/95897

I'll commit this ASAP, thx brmassa, and thx quicksketch for insisting.

I am working on an Installation Profile and have been having the same problem. After applying the patch, I am able to enable and use CCK with the installation profile.

Will these modifications make it into the final release of CCK 2, or will people using installation profiles need to apply this patch manually?

Committed. Thks all !

Feedback welcome from 'install profile'-savvy people in #295914: CCK in install profile - undefined function content_instance_tablename()

Thanks yched! You're everyone's hero!