drupal_get_path('profile', ...) works, but you wouldn't know it from the docs.

Files: 
CommentFileSizeAuthor
#19 716348-system-schema-comment-19.patch559 bytesmikey_p
PASSED: [[SimpleTest]]: [MySQL] 29,412 pass(es).
[ View ]
#13 0001-Issue-716348-by-mikey_p-Revert-documentation-on-drup.patch1.5 KBmikey_p
PASSED: [[SimpleTest]]: [MySQL] 29,415 pass(es).
[ View ]
#8 716348_drupal_get_path.patch1.67 KBgrendzy
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 716348_drupal_get_path.patch.
[ View ]
#3 716348_profile_documentation.patch1.71 KBhefox
PASSED: [[SimpleTest]]: [MySQL] 17,851 pass(es).
[ View ]
drupal_get_path_profile.patch674 bytesgrendzy
PASSED: [[SimpleTest]]: [MySQL] 17,858 pass(es).
[ View ]

Comments

Status:Needs review» Reviewed & tested by the community

Good catch!

Status:Reviewed & tested by the community» Needs work

Actually, can you fix this in http://api.drupal.org/api/function/drupal_get_filename/7 as well?

StatusFileSize
new1.71 KB
PASSED: [[SimpleTest]]: [MySQL] 17,851 pass(es).
[ View ]

Patch applies, but as Jhodgdon mentioned, missing drupal_get_filename, and possibly also missing in system_schema. However, I'm not 100% sure profile data is stored in system, but it seems likely.

Patch attached includes the above along with the two mentioned areas.

Status:Needs work» Needs review

Marking as needs review

Status:Needs review» Reviewed & tested by the community

Assuming the test bot is happy with the patch, I'm happy with it as well.

Status:Reviewed & tested by the community» Fixed

Nice catch. Committed to HEAD!

Status:Fixed» Closed (fixed)

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

Version:7.x-dev» 6.x-dev
Status:Closed (fixed)» Needs review
StatusFileSize
new1.67 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 716348_drupal_get_path.patch.
[ View ]

D6 backport.
I did not include the change to system_schema, because at least in D6 I can't find any evidence that there is ever 'type' = 'profile' in the system table. (for that matter I couldn't get a 'theme_engine' entry in {system} either).

Status:Needs review» Reviewed & tested by the community

This patch still applies and looks fine to me. Sorry for the delay in reviewing, must have gotten lost in the queue...

Status:Reviewed & tested by the community» Needs work

The last submitted patch, 716348_drupal_get_path.patch, failed testing.

Status:Needs work» Fixed

Committed. Drupal 6 does not store profiles in the database (it does not load them after installation), so that's fine. Thanks!

Status:Fixed» Closed (fixed)

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

Version:6.x-dev» 8.x-dev
Priority:Minor» Major
Status:Closed (fixed)» Needs review
Issue tags:+needs backport to D7
StatusFileSize
new1.5 KB
PASSED: [[SimpleTest]]: [MySQL] 29,415 pass(es).
[ View ]

This needs to be reverted as $type = 'profile' does not work any longer since we now treat profiles as modules.

Title:document drupal_get_path('profile', ...)Revert documentation for drupal_get_path and drupal_get_filename for profiles

Changing issue title

Status:Needs review» Postponed (maintainer needs more info)

I'm looking at the code for drupal_get_filename, and it looks like as a fallback it looks in directory $type . 's' to see if the theme/module/profile/whatever exists. So a profile would need to have $type = 'profile' for that to work. The function code might need to be changed...

Also, system_schema() still says in the description that 'type' can be 'profile'. So are you sure that 'profile' is not being put in there? Where's the function that puts entries in?

I'm not sure where this is inserted into the system table, but at least for all dozen or so Drupal 7 sites that I have locally, the profile was listed in the system table as a type='module', and there were no entries for type='profile' at all. I can roll a change to the schema docs into this as well. I wish I could pinpoint where this is getting inserted into the system table but I really have no idea (seems like it could be rather difficult to find as well).

It looks like the profile is added to the list of modules to be installed at: http://api.drupal.org/api/drupal/includes--install.core.inc/function/ins...

This is further corroborated by the snippet in install_finished() that sets the weight of the profile based on type='module': http://api.drupal.org/api/drupal/includes--install.core.inc/function/ins...

I'm open to fixing this function as needed if we'd like to keep that functionality, but for now I'm most interested in getting a patch in as quick as possible, so that this can be fixed in D7 since right now the docs on api.drupal.org are wrong (and I suspect this is a fairly frequently used function). Would getting this docs fix in first, backporting it to D7, and then trying to add the functionality back in with a later patch be a good approach here?

Status:Postponed (maintainer needs more info)» Active

Good sleuthing!

The problem with the doc change you have proposed is that it isn't really accurate. Given the way the functions behave currently, in some cases you would need to pass $type='profile' to drupal_get_filename() in order for it to find the profile (some of the code is looking at file paths, and profiles are definitely in the 'profiles' directory and not in 'modules'). But then as you've pointed out and corroborated, if the profile you are looking for is the active one used to install the site, it will be in the system table as a 'module', so you would need to pass $type='module' to find it.

There is all kinds of wonky code already in that function to handle looking for various things in various places with various file extensions based on $type. IMO the function is currently broken for profiles (there is no one value of $type you can pass to make it work in all cases for a profile), so IMO the proper fix is to put another wonky bit of code in there so that if $type == 'profile' and it is looking in the system table, it looks for table field 'type' having value 'module'.

I think it's a bug in d7 and if we get the fix into d8 first, we should be able to get it into d7, because it's a legitimate bug that needs fixing.

Then the function doc would be correct as it currently is, but we also do need to fix the {system} table's 'type' field description so it doesn't mention 'profile' as a possible value.

Title:Revert documentation for drupal_get_path and drupal_get_filename for profilesUpdate system_schema() description for {system}.type
StatusFileSize
new559 bytes
PASSED: [[SimpleTest]]: [MySQL] 29,412 pass(es).
[ View ]

I decided to open #1136820: Allow drupal_get_filename() to work with the installed profile. since this isn't really a documentation issue anymore. Attached is a patch for system_schema().

Status:Active» Needs review

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

That looks like the right change to system_schema(). Do we need an update function? I guess not -- I don't think we generally make update functions for field descriptions.

So this would be good to get into d8 and d7. I don't think it's "major" any more since the issue scope has decreased considerably.

Status:Reviewed & tested by the community» Fixed

Committed to 7.x and 8.x. Thanks!

Status:Fixed» Closed (fixed)
Issue tags:-needs backport to D7

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