Since it checks in the db after installation and we consider profiles as modules in the db, drupal_get_filename('profile', 'standard') returns nothing (this also affect drupal_get_path(), which wraps drupal_get_filename().

This patch fixes this for the case when the DB is used for lookups, and makes the documentation for both functions correct (it is currently partially incorrect).

This is a pretty big issue if you're doing custom profile development and trying to use drupal_get_path with your profile.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

pillarsdotnet’s picture

catch’s picture

It's very sad that we have so much special casing of profiles all over the place, when turning them into modules was supposed to remove that, but the patch looks good.

However it also looks like this could be added as a test very quickly too.

catch’s picture

FileSize
1.37 KB

Should have one fail.

catch’s picture

FileSize
2.21 KB

Should pass.

sun’s picture

Priority: Major » Normal
Status: Needs review » Reviewed & tested by the community

Looks ready to fly for me.

Chi’s picture

Title: drupal_get_filename does not work for profiles after installation » Some related aspects
Status: Reviewed & tested by the community » Needs work
FileSize
618 bytes

1. file_exists(DRUPAL_ROOT . '/' . $file)
The code above returns TRUE even if $file = FALSE. I think we should fix it.
2. In drupal 6 this path also doesn't come from db. Do we need backport to D6?
3. After applying the previous patch drupal_get_filename works only for current installed profile because other profiles aren't present in the system table.

Chi’s picture

Title: Some related aspects » http://drupal.org/node/1136820

Title edited by mistake.

Chi’s picture

Title: http://drupal.org/node/1136820 » drupal_get_filename does not work for profiles after installation
girishmuraly’s picture

Status: Needs work » Reviewed & tested by the community

@chi, if you look at the schema for the system table, 'filename' is set to be the primary key and cannot be NULL. So I think the extra check to see if $file is empty is not needed. Marking this as RTBC again.

Patch #4 works well for me.

pillarsdotnet’s picture

EDIT: Ignore this (How did that extra stuff get into the patch???)

Title: drupal_get_filename does not work for profiles after installation » Allow drupal_get_filename() to work with the installed profile.
Status: Reviewed & tested by the community » Needs work

The last submitted patch, drupal_get_filename-installed_profile-test+fix-1136820-10.patch, failed testing.

pillarsdotnet’s picture

Chi’s picture

@girishmuraly
I think it isn't clean code.
Example for drupal_get_filename('module', 'nonexist');

$file = db_query("SELECT filename FROM {system} WHERE name = :name AND type = :type", array(':name' => $name, ':type' => $type))->fetchField(); // $file = FALSE because «nonexist» doesn't exist in system table.
  if (file_exists(DRUPAL_ROOT . '/' . $file)) {  // But this will be evaluated to TRUE because path «DRUPAL_ROOT . '/'» exists.
    $files[$type][$name] = $file;
  }
girishmuraly’s picture

@Chi, actually I have to agree with you on that. Didn't think about that case. Yeah, checking: if ($file && file_exists(DRUPAL_ROOT . '/' . $file)) makes sense. A new test case needs also to be added.

girishmuraly’s picture

Issue tags: -Needs backport to D7

Work on the D7 version of this bug is in a different bug - http://drupal.org/node/1006714. That looks more comprehensive and tests are better. Suggest we use that for D7 atleast. Removing the 'needs backport' tag here, if that makes sense.

catch’s picture

Status: Reviewed & tested by the community » Closed (duplicate)

I'm closing this as duplicate of #1006714: drupal_get_path doesn't work for profiles.

pillarsdotnet’s picture