Hi,

I'm developing an install profile that uses date_api. Date_api is in the ...profile_modules() list.

However, if the PHP version is less than 5.2, this causes a fatal error message during installation that looks like this.

Fatal error: Call to undefined function db_result() in .../includes/path.inc on line 55

This is my diagnosis:

If PHP is less than 5.2, then in date_api_requirements(), you call l($t('Date PHP4 module'), 'admin/build/modules') which indirectly calls drupal_lookup_path() which calls db_result().

db_result() blows up because it hasn't been defined yet and/or the database hasn't been set up yet.

Ouch.

I'm not sure how or if you want to fix this up.

Comments

bengtan’s picture

bengtan commented

A quick and easy suggestion is to remove the l() call and replace by a hardcoded link?

bengtan’s picture

bengtan commented

Some more thoughts ...

Replacing

l($t('Date PHP4 module'), 'admin/build/modules')

with

$t('Date PHP4 module')

will get around the db_result() blowup.

However, for an install profile, the preceding test !module_exists('date_php4') will return an incorrect result. For an install profile, during requirements checking, the only enabled modules are system and filter. Even if my profile lists date_php4 as a required module, module_exists() will not pick this up.

karens’s picture

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

Is the problem only in hook_requirements()? If so, maybe if I change that to only test during runtime instead of install it will fix the problem. It probably wouldn't hurt anything to do it that way anyway, so I'm committing that change so you can test it.

bengtan’s picture

bengtan commented

The problem is only with hook_requirements() in the .install file, and it only triggers if date_api is listed as a module in an install profile. (And if PHP is less than 5.2)

It's a combination of two things.

Firstly, when the Drupal installer is verifying the existence of modules for an install profile, module_exists only thinks system and filter are installed. (Which is actually true)

Secondly, the l() call in the 'if' clause blows up because it tries to access a database which hasn't been setup yet.

If you move it to a runtime test, that should fix the problem, as both triggering conditions will no longer be satisfied.

However, I don't know if moving it to a run time test cause problems for you somewhere else though.

(I would also like to suggest that as a general rule of thumb, I think it's a good idea not to call l() in an .install file, just like some modules don't call t() in an .install file. They call st() instead.)

bengtan’s picture

bengtan commented

If changing it to a run time test is too hard, you can still just remove the l() call. In which case, the first condition still triggers, and you'll print out a warning/error message about requiring date_php4.module, but at least it doesn't cause a fatal undefined function error.

In this case, however, the warning/error message will be emitted even if the install profile DOES include date_php4, so it'll be a false alarm.

karens’s picture

karens commented
Status: Postponed (maintainer needs more info) » Fixed

I'm going to just leave it as a runtime message, I think that's sufficient. If I understand this right, that means this bug is then fixed.

bengtan’s picture

bengtan commented

Hi, I've just tested your fix in http://drupal.org/cvs?commit=137036 (for 6.x-2.x) and it works. I didn't test the corresponding patch for 5.x-2.x though. Thanks for your help.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.