Problem:

Issue summary:

NOTE: if you are trying to solve this novice issue, the plan of attack is at http://drupal.org/node/1170362#comment-5050480. We need a simple patch that takes most of http://drupal.org/node/1170362#comment-5011400 but instead of hiding the warning when a profile is not found, it displays its label as "Unknown").

There are multiple issues with install profiles, both within Drupal 7 and on upgraded Drupal 6 sites, these all end up with the same symptom: "Undefined index: distribution_name" due to system_requirements().

Drush 3 and dependencies
When profiles were made into modules, the modules the profiles need were put in dependencies. Unlike other modules, however, these are not real dependencies: your system might still work if you disable some. Like, installing the standard profile then disabling overlay module.

This bug was discovered in #820054: Add support for recommends[] and fix install profile dependency special casing however fixing it would have required an API change for install profile developers, so that issue is only marked against Drupal 8, and workarounds were put into all code dealing with module dependencies to special case profiles instead.

Those workarounds were put into Drush 4/5 as well, but not Drush 3, which is still in use. So any site that runs drush updb with Drush 3 will have its install profile disabled by drush.

There's nothing that can be done about this in drush 3, and the bug is in core, so this issue tried to fix that.

update.php
sun's patches above demonstrate that just running update.php on D7 can disable your install profile, due to some weird things going on in _system_rebuild_module_data()
Sites upgrading from Drupal 6 to a different install profile
In Drupal 6, install profiles were 'run once', this meant that you could make a custom install profile for a site, install it, then never touch the install profile again (including when upgrading). When install profiles became required (half-)modules in Drupal 7, support for this was completely removed - if you install with a profile, we're currently requiring you to upgrade the specific profile you installed with through every possible future version of Drupal core. #1242956: Allow install profiles to be uninstalled starts to discuss this, but since this blocks the upgrade path from D6 it's probably a legitimate bug here too

.

Proposed solution

There are a couple of ways to fix this, and they may be contradictory.

sun's patch started work on automatically ensuring the install profile is enabled every time _system_rebuild_module_data() is called. This would fix install profiles that have been disabled by drush 3 or update.php

However, there is no straight bug fix solution for the situation where a site is no longer using an install profile. For this we could either start allowing people to explicitly disable an install profile, or just make the system tolerant when none is found in the system (for example setting the site to use the 'minimal' profile which should never have any runtime code added to it).

To minimize the number of new comments asking for it, here's a work-around for current Drupal 7 users: You need to enable the profile used to install Drupal by updating the system table. For example: UPDATE system SET status=1 WHERE name='standard'; will enable the Standard profile. If you don't know which profile was used, just use 'standard'.

Files: 
CommentFileSizeAuthor
#181 minimal-install-profile-1170362-181-do-not-test.patch1.62 KBarnested
#174 install.inc_.rej_.txt1.13 KBcecrs
#168 mimimal-install-profile-1170362-168.patch1.45 KBsteinmb
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch mimimal-install-profile-1170362-168.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#148 minimal-install-profile-test-1170362-148.patch2.48 KBpillarsdotnet
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch minimal-install-profile-test-1170362-148.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#147 admin_modules-1170362-147.png101.22 KBpillarsdotnet
#147 test-results-1170362-147.png163.71 KBpillarsdotnet
#147 verbose-message-1170362-147.png88.55 KBpillarsdotnet
#147 minimal-install-profile-test-1170362-147.patch2.3 KBpillarsdotnet
PASSED: [[SimpleTest]]: [MySQL] 35,916 pass(es).
[ View ]
#144 mimimal-install-profile-1170362-144.patch2.05 KBpillarsdotnet
PASSED: [[SimpleTest]]: [MySQL] 35,720 pass(es).
[ View ]
#143 mimimal-install-profile-1170362-143.patch2.05 KBpillarsdotnet
FAILED: [[SimpleTest]]: [MySQL] 35,680 pass(es), 58 fail(s), and 21 exception(s).
[ View ]
#110 profiles.patch2.52 KBcatch
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch profiles.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]
#108 install_profiles.patch2.52 KBcatch
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch install_profiles.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#89 just_tests.patch1.04 KBcatch
FAILED: [[SimpleTest]]: [MySQL] 33,644 pass(es), 1 fail(s), and 2 exception(es).
[ View ]
#89 profiles.patch2.52 KBcatch
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch profiles_0.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]
#65 drupal8.installprofile-disabled.64.patch3.44 KBsun
FAILED: [[SimpleTest]]: [MySQL] 29,955 pass(es), 5,947 fail(s), and 2,913 exception(es).
[ View ]
#63 drupal8.installprofile-disabled.63.patch4.11 KBsun
FAILED: [[SimpleTest]]: [MySQL] 29,925 pass(es), 5,891 fail(s), and 2,888 exception(es).
[ View ]
#62 drupal8.installprofile-disabled.62.patch3.49 KBsun
FAILED: [[SimpleTest]]: [MySQL] 30,646 pass(es), 5,177 fail(s), and 2,598 exception(es).
[ View ]
#61 drupal8.installprofile-disabled.61.patch2.99 KBsun
FAILED: [[SimpleTest]]: [MySQL] 35,596 pass(es), 3 fail(s), and 0 exception(es).
[ View ]
#43 fix_disabled_profiles.patch905 bytescatch
PASSED: [[SimpleTest]]: [MySQL] 32,115 pass(es).
[ View ]
#35 tests_only.patch983 bytescatch
PASSED: [[SimpleTest]]: [MySQL] 32,120 pass(es).
[ View ]
#33 profiles_tests.patch1.84 KBcatch
PASSED: [[SimpleTest]]: [MySQL] 32,207 pass(es).
[ View ]
#33 tests_only.patch976 bytescatch
PASSED: [[SimpleTest]]: [MySQL] 32,110 pass(es).
[ View ]
#31 just_tests.patch2.74 KBcatch
FAILED: [[SimpleTest]]: [MySQL] Failed to run tests: failed during invocation of run-tests.sh.
[ View ]
#31 profile_with_tests.patch1.92 KBcatch
FAILED: [[SimpleTest]]: [MySQL] Invalid PHP syntax in modules/system/system.install.
[ View ]
#27 standard_profile.patch1.4 KBcatch
FAILED: [[SimpleTest]]: [MySQL] Invalid PHP syntax in modules/system/system.install.
[ View ]
#17 default_distribution_name-1170362-17.patch458 bytesstevepurkiss
PASSED: [[SimpleTest]]: [MySQL] 29,940 pass(es).
[ View ]

Comments

gtsopour’s picture

Same Notice

After upgrading to 7.2, i am getting the following notice
Notice: Undefined index: distribution_name in drupal_install_profile_distribution_name() (line 202 of ...\includes\install.inc)

BTMash’s picture

I get the same notice; I'm not entirely sure as I used the standard profile installation (and I see that profile/standard/standard.info still exists). Does it now get seen as a module?

David_Rothstein’s picture

Status:Active» Postponed (maintainer needs more info)

I think this error would be expected if you forgot to visit update.php (or at least clear your site's caches) after updating the code to 7.2.

Can anyone confirm if clearing the site's caches fixes the problem?

BTMash’s picture

I had upgraded my site using drush (and have cleared my site cache multiple times since) - everything works, but I still get the undefined index coming up on the module installation page.

David_Rothstein’s picture

Category:support» bug
Status:Postponed (maintainer needs more info)» Active

OK, thanks. Let's call this a bug for now, then.

cpelham’s picture

I have cleared my cache many times, from the Admin Menu, from the Performance page, and via phpMyAdmin, and I still have the error.

BTMash’s picture

What I see is that it seems to pick up the name of the profile just fine (in my case, 'standard' - I see that there is a standard profile in the profiles directory). But when it gets to the next line $info = system_get_info('module', $profile);, that's where it can't seem to find it. I'll do some more digging tomorrow to see if can figure out anything else that might be of help.

BTMash’s picture

Ok, so I was taking a look at the system table and I saw that the profile was marked as having a status of 0. I noticed that the list being returned from system_list($type) would only return 'modules' with a status of 1. I'm not sure how or why the profile was marked with a status of 0, but once I changed it in the db table, the issue went away.

klaus66’s picture

OK i have the same error.

The profile module is a normal module to expand the user module.
but you shouldn't use it anymore in drupal 7 . You can do the sam things with fields

I have an standart installation of drupal 7 and the profile name must be "Drupal" but he can't find it. but when I debug the function he found the right profile standard that is saved in a global variable but he don't find the the distribution name "Drupal".

Normally the function returns a list of all enabled modules or themes. I can't find where he wants to get the distribution name.

In my system table are only themes and modules.

BTMash’s picture

@klaus66, the profile also looks at modules. If you have a standard installation of drupal, the 'module' name will be 'standard'.

klaus66’s picture

OK thank you I didn't know this.

I find the standard module and it was disabled.

Now I have enabled it and the notice go away.

I hope everything is ok now but my question is now who has disabled my standard module, I not.

gtsopour’s picture

Thanks, I changed my profile status to 1 at system table and the notice go away.

cpelham’s picture

I looked through my system table and didn't see any row including the word standard. What should I do? In my drupal directory there is a folder called profiles and i just double-checked and all the files are there.

gtsopour’s picture

Hello cpelham,

You should see the following row entry in the system table,

#filename - #name - #type
profiles/standard/standard.profile - standard - module

MrPaulDriver’s picture

cpelham : the system table may have more rows than you are viewing. View more rows or click the next button near the foot of the page
-------------------

I'm getting the same error but in my case seems to be related to an acquia profile.

In the system table, all I can see is profiles/acquia/acquia.profile with a status value of 0. Changing the value to 1 does not appear to work.

I think my version 7.0 install was acquia, although I had forgotton this. The version 7.2 that I have installed is standard.

Would changing profiles/acquia/acquia.profile to profiles/standard/standard.profile resolve the problem for me or do I need to get hold of an acquia release?

cpelham’s picture

Paul: Like you, my system table shows an Acquia profile but not a standard profile. Setting the status to 1 did not vanquish the error. I experimented with various changes like changing the name acquia to standard, and changing the bootstrap value from 0 to 1 but none of these made a difference.

stevepurkiss’s picture

Status:Active» Needs review
StatusFileSize
new458 bytes
PASSED: [[SimpleTest]]: [MySQL] 29,940 pass(es).
[ View ]

I am experiencing this error too with a site which was originally an Acquia install before upgrading to 7.

I have looked around at what is causing the issue, it's because as Dries notes in lines 2066 and 2067 of the mollom module from the Acquia Drupal 6 stack:

  // Prior to D7, there is no distribution name recorded anywhere, so we have to
  // use "Drupal".

then goes on to set the distribution name to "Drupal". In the Acquia Drupal 7 stack, the comments aren't there but the code still sets the distribution name:

  // Retrieve Drupal distribution and installation profile information.
  $profile = drupal_get_profile();
  $profile_info = system_get_info('module', $profile) + array(
    'distribution_name' => 'Drupal',
    'version' => VERSION,
  );

I've attached a patch which provides a default distribution_name of 'Drupal' if one doesn't exist in the drupal_install_profile_distribution_name function of includes/install.inc. It's not necessarily the best way to resolve the issue but as the cause is created elsewhere I don't see any harm in providing a default value of "Drupal" to return if none exists, unless anyone knows otherwise...

MrPaulDriver’s picture

Thank you Steve,

Can the patch just be applied on a live site? Or should the install.inc file be patched before the upgrade?

stevepurkiss’s picture

Works on a live site, but does rather come under the class of 'hacking core' I guess, but can't see any other way as it's core producing the error...

David_Rothstein’s picture

Title:Undefined index: distribution_name» Install profile is disabled after upgrade to 7.2 (symptom: "Undefined index: distribution_name")
Priority:Normal» Major
Status:Needs review» Needs work

There is already code in _system_rebuild_module_data() to set "Drupal" as the default value. The undefined index error in this case is just a symptom of the real bug.

If install profiles are getting disabled after upgrading to 7.2, that's somewhat serious and should be tracked down (plus we'll need an update function to restore them). If the profile is disabled then any code (e.g. alter hooks) the profile has defined won't run, which is a problem.

cpelham’s picture

Well, whose attention do we need to bring this to in order to get it fixed?

sun’s picture

Version:7.2» 8.x-dev
Priority:Major» Critical
Issue tags:+needs backport to D7

Unintentionally disabling modules (installation profiles) sounds like a critical bug to me.

I think it'd be wise to keep this critical unless we have proof that it's not critical.

Lastly, #17 can likely be ignored.

David_Rothstein’s picture

Anyone have exact steps to reproduce this issue?

I just tried an upgrade from 7.0 to 7.2 and did not experience any problem. My install profile is still enabled in the database, and consequently I don't get the PHP notices when visiting the modules page.

I thought maybe this was a symptom of #534594: [meta] system info cache writing and registry rebuilding is broken without a full bootstrap (which was in Drupal 7.2 but since rolled back) but if so, I haven't been able to figure out how to trigger it.

stevepurkiss’s picture

OK, my bad re #17, wasn't aware of the wider issues... learning ;)

I'm looking at my 7.0 which was an acquia distro upgraded to 7.0. The acquia profile is disabled, but the distribution_name IS set to Drupal, so it's not so much that the install profile is disabled, but that the distribution name is lost somewhere during the 7.2 upgrade. Of course this does mean the install profile has been disabled all the time in 7.0 for me, I'm wondering whether it has anything to do with a previous issue http://drupal.org/node/679730 - I had applied the first patch in the issue but not the one in #10

stevepurkiss’s picture

I just did a 7.0->7.2 upgrade, did a diff and think I can see where the issue is:

--- a/modules/system/system.install
+++ b/modules/system/system.install
@@ -1,5 +1,4 @@
<?php
-// $Id: system.install,v 1.532 2011/01/02 17:26:39 webchick Exp $

/**
  * @file
@@ -33,11 +32,11 @@ function system_requirements($phase) {
     // is not running the default install profile.
     $profile = drupal_get_profile();
     if ($profile != 'standard') {
-      $info = install_profile_info($profile);
+      $info = system_get_info('module', $profile);
       $requirements['install_profile'] = array(
         'title' => $t('Install profile'),
         'value' => $t('%profile_name (%profile-%version)', array(
-        '%profile_name' => $info['distribution_name'],
+          '%profile_name' => $info['name'],
           '%profile' => $profile,
           '%version' => $info['version']
         )),

As you can see from the above, the function system_get_info is now used to get the profile name, and system_get_info only gets info from enabled modules, and because my acquia profile module is disabled, it's not getting the info, thus the distribution name is lost in the 7.0->7.2 upgrade.

Not sure how many cases of this there's likely to be - I had upgraded my acquia 6 distro to 7 before the acquia 7 distro had come out so there was no continuity of my distro through the upgrade at the time, and to me it makes no difference if the distribution_name is 'Drupal', hence why I did the patch in #17 earlier.

catch’s picture

Issue tags:+D7 upgrade path

If you upgraded from Drupal 6 I think that might be the real issue here.

<?php
/**
 * Rename 'Default' profile to 'Standard.'
 */
function system_update_7049() {
  if (
variable_get('install_profile', 'standard') == 'default') {
   
variable_set('install_profile', 'standard');
  }
}
?>

There is nothing to actually enable the profile.

Here's a rough patch, it enables the standard profile if it's set as the install profile, and not found enabled already in the database.

We can't use module_enable() since in this case we don't want hook_install() or hook_enable() to run, so it does a db_merge(), then have to rebuild the theme data to get info rebuilt etc.

Could potentially generalise this so it gets the name of the profile, checks if it's enabled, then does a similar query if not, but that will only catch contrib profiles where they already did a similar update to system_update_7049() in the first place to change the variable, so we may just want to tell contrib profiles that change name between versions to copy the same code.

catch’s picture

Issue tags:+Needs tests
StatusFileSize
new1.4 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid PHP syntax in modules/system/system.install.
[ View ]

This time with the patch. This is a D7-only patch since it just adds a new update, since only one person on this issue mentioned upgrading from D6 I don't want to jump the gun and move it back to 7 though.

Should add a test for this, should be easy to add to the main upgrade path test.

David_Rothstein’s picture

Title:Install profile is disabled after upgrade to 7.2 (symptom: "Undefined index: distribution_name")» Install profile is disabled after upgrade to Drupal 7 (symptom: "Undefined index: distribution_name")

Aha... It looks like you identified the problem for the most part.

However, I don't see why this would be specifically related to renaming the profile? It looks to me like this will occur for all sites that upgraded from D6, regardless of what profile they used. D6 did not store the profile in the {system} table, which means the only way it gets there during an upgrade currently is via system_rebuild_module_data(), which will never enable something it finds in the filesystem for the first time.

That also seems to be borne out by what @stevepurkiss said above (he's using Acquia Drupal, which did not rename its install profile from D6 to D7).

So putting it together, maybe like this is all we need:

<?php
function system_update_7072() {
  if (!
db_query("SELECT 1 FROM {system} WHERE type = 'profile' AND status = 1")->fetchField()) {
   
system_rebuild_module_data();
   
db_update('system')
      ->
fields(array('status' => 1))
      ->
condition('name', variable_get('install_profile', 'standard'))
      ->
execute();
  }
}
?>
catch’s picture

That's a good point, forgot that profiles were never in the system table ever.

There should be a system_list_reset() after the direct update to clear caches, but apart from that the proposed change looks good.

Not quite the same thing, but #1136820: Allow drupal_get_filename() to work with the installed profile. is similar install profile breakage.

cpelham’s picture

FYI: I have this problem and I did not upgrade from D6. I started with D7. so in my case at least it's not an upgrade issue.

catch’s picture

Version:8.x-dev» 7.x-dev
Status:Needs work» Needs review
StatusFileSize
new1.92 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid PHP syntax in modules/system/system.install.
[ View ]
new2.74 KB
FAILED: [[SimpleTest]]: [MySQL] Failed to run tests: failed during invocation of run-tests.sh.
[ View ]

Moving down to 7.x for now.

Uploading David's suggestion from #28 with an added test. Also a patch with only the test.

Didn't run these locally, sorry for the noise if they fail but otherwise this should be ready.

@cpelham: could you let us know which install profile you used, and what the content of the system table are for it if any?

Status:Needs review» Needs work

The last submitted patch, profile_with_tests.patch, failed testing.

catch’s picture

Status:Needs work» Needs review
StatusFileSize
new976 bytes
PASSED: [[SimpleTest]]: [MySQL] 32,110 pass(es).
[ View ]
new1.84 KB
PASSED: [[SimpleTest]]: [MySQL] 32,207 pass(es).
[ View ]

There's not testing the patches, then there's not even looking at them before uploading, bah.

catch’s picture

Opened #1186196: Fix upgrade documentation to ensure people don't remove profiles from /profiles for this bug on new D7 sites, even if it's the same symptom, it has to be a different bug to the one the patches here fix. That's currently marked needs more info since there aren't steps to reproduce yet.

catch’s picture

StatusFileSize
new983 bytes
PASSED: [[SimpleTest]]: [MySQL] 32,120 pass(es).
[ View ]

This should fail.

catch’s picture

Status:Needs review» Needs work

Out of time to look into this now, but #35 should have failed, so back to CNW.

catch’s picture

Status:Needs work» Active

This is why it doesn't fail, we have that code, it's just buried in includes/update.inc

http://api.drupal.org/api/drupal/includes--update.inc/function/update_fi...

Marked the other issue as duplicate, back to square one here.

cpelham’s picture

I started with Acquia Drupal 7.0. I didn't give any thought to installation profiles. I don't know what related to them I might have done to make mine an usual case.... I had the various Acquia modules turned off when I upgraded from 7.0 to 7.2.

catch’s picture

Did you use drush to update or update.php?

David_Rothstein’s picture

I just tested this, and was able to reproduce the bug when using Drush to update from 6.x to 7.x (with the default install profile).

Per @catch's findings, I was not able to reproduce the bug when using update.php to update from 6.x to 7.x. (Although that update code still seems a bit problematic; after going through update.php you wind up with a ghost entry for profiles/default/default.profile in the {system} table that doesn't seem to go away, in addition to the correct entry for profiles/standard/standard.profile which is enabled.)

catch’s picture

In that case I wonder whether this is #820054: Add support for recommends[] and fix install profile dependency special casing.

iirc drush has some code to disable modules when their dependencies aren't found. If that is running for install profiles, then there will be many, many times where someone has disabled a 'required' module for a profile - drush may then treat the profile the same way as a normal module and disable it.

Haven't yet found that code in drush though but I remember seeing the message.

catch’s picture

Here we are:

#898768: D7: drush dis [module] can disable profile.

Couple of options:

- Add a new core update to re-enable the install profile - IMO this is a core bug that drush has had to work around.

- Ignore it, make people run drush en -y standard themselves, mark this as duplicate.

catch’s picture

Title:Install profile is disabled after upgrade to Drupal 7 (symptom: "Undefined index: distribution_name")» Install profile is disabled if you used any drush version prior to March 2011 on a D7 site
Status:Active» Needs review
StatusFileSize
new905 bytes
PASSED: [[SimpleTest]]: [MySQL] 32,115 pass(es).
[ View ]

Let's do this. Leaving as critical because a lot of people use drush, and this is a core bug which drush has had to work around.

Even with this patch applied, we'll still get reports of this until people update their drush installs.

Status:Needs review» Needs work
Issue tags:-Needs tests, -D7 upgrade path, -needs backport to D7

The last submitted patch, fix_disabled_profiles.patch, failed testing.

catch’s picture

Status:Needs work» Needs review
Issue tags:+Needs tests, +D7 upgrade path, +needs backport to D7

#43: fix_disabled_profiles.patch queued for re-testing.

cpelham’s picture

Title:Install profile is disabled if you used any drush version prior to March 2011 on a D7 site» Install profile is disabled after upgrade to 7.2 (symptom: "Undefined index: distribution_name")

I haven't used drush.

catch’s picture

@cpelham, OK I re-opened #1186196: Fix upgrade documentation to ensure people don't remove profiles from /profiles. It looks like the drush issue is a definite one, even if there could be other causes of the same bug. Please post as much information as you can on that issue.

fietserwin’s picture

Getting the same notice after upgrading a fresh minimal D7.0 installation to D7.2 (on Windows, (thus) no Drush).

klaus66’s picture

I think it must be a core bug.
I only install the newest dev version and I have this notice. No change on erverthing else.

For me I set the status to 1 in my system table and then it is ok. But I must do this every time I update the dev version and this is at the moment often.

michael_clark’s picture

I am having the same error.

msonnabaum’s picture

Status:Needs review» Reviewed & tested by the community

#43 looks reasonable to me. This should only be an issue with drush 3.x as we implemented a workaround in 4.

BTMash’s picture

Looks good to me as well - I essentially did what your patch does and that fixed the issue.

chx’s picture

I am removing the needs test 'cos what do you want test here? That the query worked? That's DBTNG tests.

Summary: When profiles were made into modules, the modules the profiles need were put in dependencies. Unlike other modules, however, these are not real dependencies: your system might still work if you disable some. Like, install standard and disable comment. It is possible that there are some real dependencies for a profile if it implements hooks and needs those modules. Also, there is no "discover my dependencies and enable them before enabling me" used while installing, just   $modules = $install_state['profile_info']['dependencies']; the 'dependencies key here could be anything else and for D8, #820054: Add support for recommends[] and fix install profile dependency special casing indeed suggests changing it.

Now, due to this faux-dependency Drush earlier decided to disable the faux-module because it's dependencies were no longer met. We need to fix this. Whether there are more problems we do not know yet but this is a must.

klaus66’s picture

The problem is in the update.php script. When I run update.php then the status in my standart module is set to 0. I think this cannot be ok.

Tomorrow I debug the update.php and try to find out why.

webchick’s picture

Status:Reviewed & tested by the community» Needs review

Hm. I'm not sure about this.

I just did a fresh installation of Drupal 7.x-dev. The row for "standard" has a type of "module", not "profile". It's the same in the two other D7 installs I have on this laptop from various times in the past. So this query:

+  if (!db_query("SELECT 1 FROM {system} WHERE type = 'profile' AND status = 1")->fetchField()) {

is always going to fail, as far as I can see? Shouldn't we be checking for name = variable_get('install_profile', 'standard') ?

catch’s picture

Status:Needs review» Needs work

That was the patch in #31 except we need this to run regardless of profile name, the new patch is broken then. I definitely didn't test it, looks like no-one else did either. Reminds me of #1006714: drupal_get_path doesn't work for profiles, the whole conversion of profiles to modules was half-arsed and we're still cleaning up.

If we had #1182296: Add tests for 7.0->7.x upgrade path (random test failures) we could write a proper test for this, I don't think it's possible otherwise or not without very nasty hacks in the test to reset schema version or call the function directly after manually putting the db in the inconsistent state.

Do not have motivation to re-roll this, should be easy enough if someone else does.

Damien Tournoud’s picture

I'm currently able to reproduce this by just running drush updatedb (even without any database update required), on the tip of the 5.x branch of Drush. Is there an open issue about that in the Drush queue?

catch’s picture

The only drush issue I know about is the 3.x one that was closed in September.

Damien Tournoud’s picture

On a non-core profile (Commerce Kickstart) I can reproduce by simply visiting update.php.

Damien Tournoud’s picture

Don't mind me, what was happening is that I removed the profile from the filesystem.

sun’s picture

Status:Needs work» Needs review
StatusFileSize
new2.99 KB
FAILED: [[SimpleTest]]: [MySQL] 35,596 pass(es), 3 fail(s), and 0 exception(es).
[ View ]

Friends. As always. TDD.

sun’s picture

StatusFileSize
new3.49 KB
FAILED: [[SimpleTest]]: [MySQL] 30,646 pass(es), 5,177 fail(s), and 2,598 exception(es).
[ View ]

Attached patch fixes the bug for existing sites. Still failures for new sites.

sun’s picture

StatusFileSize
new4.11 KB
FAILED: [[SimpleTest]]: [MySQL] 29,925 pass(es), 5,891 fail(s), and 2,888 exception(es).
[ View ]

Attached patch fixes all issues.

Status:Needs review» Needs work

The last submitted patch, drupal8.installprofile-disabled.63.patch, failed testing.

sun’s picture

Status:Needs work» Needs review
StatusFileSize
new3.44 KB
FAILED: [[SimpleTest]]: [MySQL] 29,955 pass(es), 5,947 fail(s), and 2,913 exception(es).
[ View ]

As I'm going to get a cup of sleep and don't see test results of #63 yet, extra safety patch without the install.core.inc change -- although I think that's valid.

Apparently, SimpleTest uses custom functions to install a Drupal site, for performance reasons. Which in turn means that especially the initial core installation does behave differently. Doesn't invalidate the final test assertions of this patch, but definitely the first.

Status:Needs review» Needs work

The last submitted patch, drupal8.installprofile-disabled.64.patch, failed testing.

David_Rothstein’s picture

Does that test actually fail without the rest of the patch?

Seems like it shouldn't, since so far no one has come up with a (reproducible) way to hit this issue by visiting update.php alone, only when using Drush. Still doesn't hurt to have the test, of course.

Fixing it in _system_rebuild_module_data() does seem reasonable if it works; it's a little silly to hardcode that because there's no legitimate way the profile ever should get disabled in the first place, but it's more robust than an update function and we already hardcode everything else about the profile in _system_rebuild_module_data() already, so why not.

sun’s picture

Title: Install profile is disabled after upgrade to 7.2 (symptom: "Undefined index: distribution_name")» Install profile is disabled after upgrade to 7.2 (symptom: "Undefined index: distribution_name")

@David_Rothstein: yes, #61 was a test-only patch.

I think I now understand what happens in #65: Since the profile module status is enforced in _system_rebuild_module_data() and module_enable() relies on that, hook_install() + hook_enable() are not invoked for the profile module, because... it's already enabled. :(

David_Rothstein’s picture

OK, #61 fails, but I think not in a way that reveals the actual bug (since the test results show that the 'Install profile is enabled' assertion fails both times, rather than only once). Once that problem is fixed my guess is the test will pass either way.

Hm, so regarding the issue with #65, short of a hack that only sets 'status' under certain conditions (e.g. when Drupal is not being installed), which is not so great, is there any way to get around that problem?

catch’s picture

I'm not sure we should try to actually 'fix' this in this issue. We know that at least sites with Drush 3 are likely to hit this condition but no other steps to reproduce.

#1186196: Fix upgrade documentation to ensure people don't remove profiles from /profiles is there for any other occurrences of the bug that aren't due to drush - if we correct it for those too, we might never find those bugs (if they exist at all).

sun’s picture

#61 fails, but I think not in a way that reveals the actual bug (since the test results show that the 'Install profile is enabled' assertion fails both times, rather than only once).

The cause for the first fail is that Simpletest uses a completely different routine to install Drupal. We should eliminate this difference: #1215104: Use the non-interactive installer in WebTestBase::setUp()

hass’s picture

Same issue after manual upgrade (without drush)

rickmanelius’s picture

Same. Subscribe.

Frank Ralf’s picture

Same issue after upgrading from D6 using update.php.

I used the German Drupalcenter version (available from http://www.drupalcenter.de) and the only installation profile entry in the system table after the upgrade was "profiles/drupalcenter/drupalcenter.profile" set to status "disabled" (0). After manually changing the status to "1" with phpMyAdmin the error went away.

hth
Frank

likewhoa’s picture

subscribing.

David_Rothstein’s picture

Title:Install profile is disabled after upgrade to 7.2 (symptom: "Undefined index: distribution_name")» Install profile is disabled after using older versions of Drush to update D7 (symptom: "Undefined index: distribution_name")

Unless we decide to close #1186196: Fix upgrade documentation to ensure people don't remove profiles from /profiles again, let's focus this issue on the Drush case (which we know how to reproduce).

alanburke’s picture

Subscribe
Got this trying to upgrade a site to D7.
It was originally installed as a Drupal 4.6 site, some time before installation profiles!

KarenS’s picture

There's one more piece to this puzzle. I have a site that originally used an install profile but no longer uses it. I did a site upgrade using drush and started getting this error. I now have an entry in my system table for the non-existant install profile that is marked as disabled. Setting it to enabled fixes nothing because it doesn't exist.

The system entry is added by the upgrade process without checking to see if it actually exists, because it is still in the 'install_profile' variable. The system update set the status to active, which Drush fixed for me, but I still need to update the 'install_profile' variable to 'standard'. If I did not use Drush I think I would still have an error, the only difference is that the entry in the system table would have been marked as active.

I don't know how we can tell if the missing installation profile is intentional or by accident. If the missing installation profile is because the profile is no longer being used, we want to remove the system entry or at least mark it inactive and also reset the 'install_profile' variable. If the installation profile *is* still being used but didn't get added to the new site we want to leave the variable alone and set a message warning the user that it is missing.

Kiphaas7’s picture

I ran into this bug too. I'm hoping the following has some added value for this topic in fixing the bug:

My install was a 7.4 install (incrementally updated in time from a clean 7.0). After running the 7.7 update, I got the error mentioned in the OP (line 202 of install.inc). Found this topic, and ignored it for a bit.

Some time later, I was uninstalling a few modules and found the standard profile in the list of modules ready to be uninstalled. This triggered me to go look through install.inc and figure out what was going on.

Apparently, it first look for drupal_get_profile(). drupal_get_profile() get's its return value (in my case) from the variable install_profile (defaults to standard). Not a problem, I found the variable in my variable table and it was set to standard.

system_get_info('module', $profile), was the next line. Digging through, I found that it runs through a list of enabled modules. Somehow my standard profile got disabled (hence it showing up in the list of modules ready to be uninstalled). After manually setting the 'status' to 1 of the module 'standard' in the system table, the error is gone.

So, for me the fix was enabling the standard profile again. Somehow it got disabled. I did not delete a single drupal core folder (including the profiles folder) or muck around with any other core file. I just ftp'd the 7.7 update, and ran the update.php.

catch’s picture

@Kiphaas7: did you use drush to riun updates? If so which version?

Kiphaas7’s picture

No, no drush.

EDIT: Stupid me. This topic is about drush. :/

d3str0y’s picture

I upgraded 7.2->7.7 via FTP

And got this:
Notice: Undefined index: distribution_name in drupal_install_profile_distribution_name() (line 202 of/path/to/site/includes/install.inc).

Also, this:
Notice: Undefined index: name in system_requirements() (line 39 of /path/to/site/modules/system/system.install).
Notice: Undefined index: version in system_requirements() (line 41 of /path/to/site/modules/system/system.install).
http://drupal.org/node/679730

jies’s picture

I too encountered problems that seem to be right to mention here.
Upgrading from 7.4.4 to 7.7 on Windows XP machine used for local development, so no FTP, no drush, nice and simple.

Received message:

Notice: Undefined index: name in system_requirements() (line 39 of /path/to/site/modules/system/system.install).
Notice: Undefined index: version in system_requirements() (line 41 of /path/to/site/modules/system/system.install).

Wiped everything, did new install; no problems, then did security update, same error.
Wiped again, installed, did security update, but KEPT the "Profiles" module from the new install (did not use the one with the security package). Problem went away.

Hope this helps someone.

kervi’s picture

same here

Notice: Undefined index: distribution_name in drupal_install_profile_distribution_name() (line 202 of /h/*******/htdocs/includes/install.inc).

jp1’s picture

I experienced the same problems as # 84, reinstalled and the errors reported by #84 were gone however I received the same error as #85 Uninstalled everything again. Reinstalled in this order: acquia-drupal-win7.4.4-5598.29386 with no errors but two security updates were required again. Upgraded Token 7.x-1.0 beta2 to 7.x-1.0-beta 3 with no errors. Upgraded Drupal Core Installed version 7.4 to version 7.7 this time with no errors the only thing different this time around was to download a fresh copy of version 7.7 zip(3.04MB) . Please Note " #84 had KEPT the "Profiles" module " I did not do this and everything worked ok regardless.

I too am using XP as a devlopment box... no drush and no FTP

catch’s picture

@KarenS: I think that's another aspect to this that some people have run into, but hasn't been discussed yet (and definitely wasn't when install profiles were switched from run-once to required modules in D7). I opened #1242956: Allow install profiles to be uninstalled for D8 but I'm now thinking we should backport this to Drupal 7 too.

I'm going to update the issue summary to try to summarize all of the possibilities, this is a real mess.

catch’s picture

Issue summary:View changes

Created summary

catch’s picture

After writing all that, here's my suggestion for what we do:

1. Fix the patch in #43 - just have a one off that enables the profile again.

2. Make core agnostic about whether the install profile is enabled or not, #679730: undefined index: name" and nonsensical install profile information printed in system_requirements() is related to this.

catch’s picture

Version:7.x-dev» 8.x-dev
Status:Needs work» Needs review
Issue tags:+needs backport to D7
StatusFileSize
new2.52 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch profiles_0.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]
new1.04 KB
FAILED: [[SimpleTest]]: [MySQL] 33,644 pass(es), 1 fail(s), and 2 exception(es).
[ View ]

OK here's a start on part 2 of that.

catch’s picture

Title:Install profile is disabled after using older versions of Drush to update D7 (symptom: "Undefined index: distribution_name")» Install profile is disabled for lots of different reasons and core doesn't allow for that

Re-titling. The more I think about this, #83 is enough to make this non-critical for Drupal 8 I think. Then we need to restore mistakenly disabled profiles in an update for D7. Then there are several outstanding bugs and tasks for cleaning up install profiles already which handle the things not covered here.

catch’s picture

Priority:Critical» Major

Also now there's reasonable documentation of the ways this can occur this feels more major than critical.

cpelham’s picture

Aside from producing this error message, does this issue cause any other problems? I've been running a live site with this issue for several months and haven't noticed any other problems. Do I need to re-create an install profile at some point or is it not really needed?

KarenS’s picture

At the moment the only problem is the error message. The underlying problem is that the system thinks you need a profile that doesn't exist or isn't enabled and somewhere down the road that might lead to other problems. We need to either make sure the profile is available and enabled or reset the system so that it knows there is no profile.

David_Rothstein’s picture

See #20. There are definitely consequences if your profile implements Drupal hooks that are supposed to run during normal site operation.

If it doesn't (e.g., the core install profiles) I'm not sure if there are actually any other noticeable side effects.

catch’s picture

Right. New Drupal 7 profiles can implement hooks etc. and if the profile is disabled those won't run, same as any other module. If you have a highly customized distribution then this could break it. However all install profiles in Drupal 6, and likely many Drupal 7 ones are just supposed to run once and that's it - so it doesn't really make any difference if they're enabled or not, just the current code always assumes they are - there might be some other side-effects similar to these notices maybe, for example where install profiles are special cased elsewhere, but not aware of specifics.

Frank Ralf’s picture

JFTR
The German language version available from http://www.drupalcenter.de (which supposedly most German users will use) comes with its own installation profile which besides the translation contains a module for a block.

robert.laszlo’s picture

Hey. I did the *exact* same thing when updating a Commerce dev machine to D7.7 (manually). Completely forgot that we started with Commerce Kickstart. Were you able to fix this somehow?

krak’s picture

subscribe

catch’s picture

Issue tags:+Quick fix

Adding 'quick fix' tag for issues where the patch is quite straightforward. This issue has a long history but the fix is simple.

catch’s picture

I marked #679730: undefined index: name" and nonsensical install profile information printed in system_requirements() as duplicate. It was the older issue but this has a lot more background on the various causes at this point, and the fixes have to touch exactly the same lines of code.

Frank Ralf’s picture

I still got the same error messages as #84 after upgrading from 7.7 to 7.8. Applying the patch from #89 got rid of the error messages, but not of the installation profile entry in the system table in the database which still points to "profiles/drupalcenter/drupalcenter.profile" (see #96 which is long gone from the installation.

catch’s picture

@Frank. Yeah the patch does not attempt to clean up the system table because profiles can be both intentionally and unintentionally missing. Sounds like it works for you. Would be good to get more reviews here.

Jeff Veit’s picture

subscribe

Frank Ralf’s picture

Sorry, I now get the same error message as #85 (the first part of #83 while the second part of #83 disappeared after applying the patch).

Bojhan’s picture

Status:Needs review» Reviewed & tested by the community

Catch told me its ready to RTBC, therefor marking it RTBC. Having "no profile" should be totally possible and not throw errors.

catch’s picture

#89: profiles.patch queued for re-testing.

Status:Reviewed & tested by the community» Needs work
Issue tags:+Quick fix, +D7 upgrade path, +needs backport to D7

The last submitted patch, profiles.patch, failed testing.

catch’s picture

Status:Needs work» Reviewed & tested by the community
StatusFileSize
new2.52 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch install_profiles.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Re-rolled, if this patch doesn't apply to D7 then the one from #89 should since it was just stuff added to system.test wot broke it.

catch’s picture

Assigned:Unassigned» webchick

Assigning to webchick - this is my patch so I can't commit it and it needs backport so makes sense for webchick to sign off.

catch’s picture

StatusFileSize
new2.52 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch profiles.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]

Re-uploading #89 for 7.x/testbot.

Status:Reviewed & tested by the community» Needs work

The last submitted patch, profiles.patch, failed testing.

webchick’s picture

Priority:Major» Normal

Just had a LONG discussion about this in #drupal-contribute.

At first I was very opposed to this patch because it's merely sweeping details under the rug instead of actually fixing anything. Then catch explained that it's not really possible to fix it, because once this value is missing (regardless of which way it happens), there's no way of rebuilding the information on what it used to be.

The patch as outlined in #108 addresses the notice on the status page by hiding the block about the installation profile on the status page if it can't find one. However, now that installation profiles are modules in D7, it's reasonable for a distribution author to assume that they can put hooks in there that should execute at run-time, and that they can put updates in the .install files and those will run. That's, after all, why we made the change in the first place. #509398: Install profiles should be modules with full access to the Drupal API and all it entails(.install files, dependencies, update_x)

If the status message is gone entirely, a distribution author has very limited ways of troubleshooting why some of their users are getting DB updates and others are not. It involves asking users to dig around in the DB and check for a variable value and all sorts of other nonsense.

So. What I think we should do instead of hiding the message entirely is display the profile name as "Unknown." Then this could be an easy troubleshooting step for distribution authors to ask their users to take in this situation, and we're not "faking" them with some other profile (e.g. minimal) that isn't actually correct.

Also, since this is just about a notice fix, this is no longer 'major'. Additionally, since the actual fix should be pretty straight-forward re-roll/adjustment of #108, I'm tagging as Novice.

webchick’s picture

Issue tags:+Novice

Ahem.

webchick’s picture

Issue summary:View changes

Updated issue summary.

David_Rothstein’s picture

Is it intentional that #108 removes the version string from the info printed on the requirements page?

Based on #679730: undefined index: name" and nonsensical install profile information printed in system_requirements() (which was marked duplicate of this issue) we need to do something about that, since we can't assume all profiles have version info actually defined. However, if it is defined, I would think we should print it. (It goes along with the idea that this is a troubleshooting tool for distribution maintainers, who might need to know what version of the install profile a particular site is running off of.)

KarenS’s picture

This is a fix for a notice that will appear on every page of your site on every page load that provides no clue about how to make it go away. That's a bit more major than a one-time notice.

[Edit] Er, I guess it is not actually on every page on your site. I take that back.

rickmanelius’s picture

Subscribing

moonray’s picture

subscribe

saccard’s picture

subcsribe

likewhoa’s picture

people stop subscribing and start following already! see top of all issue queues for the follow button. 1<3

rickmanelius’s picture

My only concern with displaying 'Uknown' is that it's annoying to still have to see this error message on all admin pages forever until one fakes an installation profile. Is there a way to simply set it to 'standard' in the case of no other profile during an upgrade?

KarenS’s picture

I was trying to figure out how to fix the problem on an installation that already has it, since we need some sort of update hook for those situations (we can't ask someone with a functional, ported site to start over again).

Here are the things that end up broken and how to fix them:

1 - There should be a .profile module in the system table. It should either be standard.profile if you aren't going to use a profile or MYPROFILE.profile if you used a custom installation profile. And the .profile's status should be set to '1'. I have seen two problems, depending on the original source problem. Either the right profile is there and it's status is not set to '1', or the expected profile is missing and the wrong one is there. If you have MYPROFILE.profile and you wanted to be using the standard profile you need to create the standard.profile (or change the values in the one you have) and mark it active.

2 - There is a variable called 'install_profile'. It should be set to 'standard' if you don't want to be using an install profile or the name of the profile you want to use. The value should match the .profile that you set to active.

I have two installations that broke for different reasons. One (a drush site-install that used the standard profile) had the right variable and the right profile and just needed it to be set to active. The other (an upgrade from a site that originally used an install profile that has no D7 version) had the wrong variable and was missing the right profile (had a profile for the non-existant custom install profile). In that case I needed to change the variable and create the standard.profile and set it active. After doing that and clearing the caches both sites seem to be working fine with no error messages.

Getting this into an update hook requires some knowledge about what was intended. I have no idea how to do that.

rickmanelius’s picture

Hi KarenS. Thanks for the very detailed response. I think the last paragraph says it all: requiring information about what was intended.

I saw in another thread how someone simply used drush on the command line to re enable the standard profile... thus adding it to the tables. The problem with this approach is that enabling the profile this way caused the system to try and recreate various input formats, default theme options, etc.

I was thinking of a way to hack it by simply commenting out the entire profile and then enabling that from the command line... then uncommenting after. Not very elegant!

Perhaps the best solution: a 'placeholder' or 'dummy' profile. This was, someone could enable it through a hook update, but it wouldn't actually install a blessed thing. That way the system is happy because there is SOMETHING technically set as a profile, but it doesn't do anything besides act as a placeholder.

Considering the quantity of D6 to D7 upgrades on the horizon, this seems like it would help a lot.

Thoughts?

clemens.tolboom’s picture

I just did a

drush vset distribution_name my_value

on a D7 fresh install with own profile which made the pain go away.

webchick’s picture

Assigned:webchick» Unassigned

I already chimed in on this issue, so I don't believe it's blocked on me anymore. Unassigning.

Szergio’s picture

Status:Needs work» Needs review
Issue tags:-Quick fix, -Novice, -D7 upgrade path, -needs backport to D7

#110: profiles.patch queued for re-testing.

Status:Needs review» Needs work
Issue tags:+Quick fix, +Novice, +D7 upgrade path, +needs backport to D7

The last submitted patch, profiles.patch, failed testing.

mattbanks’s picture

Subscribing

Having same issue. Used Acquia Drupal 6 for college website and we're looking into an upgrade path to D7. Tried the upgrade on a development server and seeing the Undefined index errors for name and version. I used Acquia D7 with the profiles folder there. Would rather not hack core to fix this, but it's throwing a lot of errors and preventing a clean upgrade path, which hinders our ability to move forward with a few projects we have in mind for the site.

St_Dekker’s picture

Can confim that KarenS fix (#121) got rid of the notice,

"Notice: Undefined index: distribution_name in drupal_install_profile_distribution_name() "

on my install, with a custom installation profile.

1. Set the custom install profile (profiles/custom/custom.profile) status to 1 in the system table.
2. Added install_profile variable 'custom', with drush (drush vset install_profile custom)

Jumoke’s picture

#121 and #128 fixed it for me. Thanks

Changed the value of profiles/standard/standard.profile in the Systems table to 1

flock’s picture

"Changed the value of profiles/standard/standard.profile in the Systems table to 1"

Same worked for me.

jorisx’s picture

Yep thanks a lot !
"Changed the value of profiles/standard/standard.profile in the Systems table to 1"

Same worked for me.

rickmanelius’s picture

Well if it's truly a matter of toggling a 0 to a 1, would a simple hook_update fix this issue entirely so we can close it out? I know there are some additional considerations in #121 and before... are there any hidden gotchas for this toggle?

catch’s picture

Yeah the problem is the actual install profile may not even be in the install any more, for example on a site upgraded from 6.x. You can't enable a profile that doesn't exist.

rickmanelius’s picture

I would suggest creating a 'dummy' profile which was nothing more than a .info and a .module file and then assign it to that... because then it handles the error but doesn't fake the system into thinking the styles/preferences of standard or minimal are being used, etc.

KarenS’s picture

Well if it's truly a matter of toggling a 0 to a 1, would a simple hook_update fix this issue entirely so we can close it out?

It's not that simple. That is the right fix for one permutation of the problem, but there are other permutations that won't cover.

I would suggest creating a 'dummy' profile which was nothing more than a .info and a .module file and then assign it to that... because then it handles the error but doesn't fake the system into thinking the styles/preferences of standard or minimal are being used, etc.

I don't see how that is any better than just setting it to use the standard profile. You've left the system in an unsupported state that indicates it is using a non-existant profile and not even a warning any more. What would then happen when they upgrade to D8?

There is no 'harm' in leaving the system set up to use the standard profile if it can't find any other profile to use. The system will work fine. What would be lost is any connection to a custom profile going forward.

So I propose that the upgrade path does the following, and that we add an update hook to double check this on systems that have already upgraded:

1) Check the value of the variable. If the variable says there should be a custom profile, see if there is actually a profile that matches it in the codebase. If the profile exists, make sure the system table entry has been created and is enabled.

2) If the variable says there should be a custom profile but there is no custom profile in the codebase, alter the variable to use the default profile. See if the standard profile exists in the system table. If it does, enable it. If it doesn't, create it. Create a new variable for the lost installation profile and set that to the original value. That would provide something that could be used later by custom code or a contrib module to go back and reset the profile to the right value again.

3) If the variable indicates that the default variable should be used, make sure the default profile exists and is enabled.

The above process would fix every one of the possible problems except one. The only thing that would not be fixed correctly is if the system should be using a custom profile and it still couldn't find that profile anywhere in the codebase. I don't think there is any automatic way to fix that problem, so we have to be sure everyone understands that any custom profile must exist in the system when you do the original upgrade (or before you run this update code). If we add a variable that contains a missing profile that got reset, it should be possible for someone to create a contrib module or custom code to reset those values later, as a final fallback.

KarenS’s picture

Issue tags:-Quick fix, -Novice

Also, I'm not sure this is a quick fix or a novice issue. There is some complexity here.

rickmanelius’s picture

After diving into the profile of open atrium, I rescind my suggestion of just the dummy (or minimal or standard) profile in #134. KarenS suggestions in #135 makes sense. Further explanation

standard.install basically does the following:

Defines default modules to install (in the .info file)
Creates text inputs (filtered, full html)
Sets default theme (bartik)
Sets initial Block configuration (navigation, etc)
Creates initial content Types (page, article)
sets default variables (node submissions, etc)
taxonomy (tags)
default fields (image, etc)
permissions and Roles

It's quite possible for a site to have none of these defaults left unchanged by the time the site launches (least likely to be removed is the input formats.. but even then). In that case, would it be smart for other modules to depend on these values knowing that they are not fixed in code but rather initiated once and then left to change by the user?

In the case of custom, you're completely right... especially if there are non-configuration functions (see open atrium as an example). So the checks listed would be totally valid.

In short:
1) If the installation came from minimal or standard, just toggle on minimal because there is no custom code beyond configurations in either...
2) If the installation came from a custom profile, use the custom profile if still available.
3) If installation came from custom profile that doesn't exist anymore, then send a system warning stating that they need to download/add this profile back in.

These are similar suggestions to KarenS' in #135... but it didn't click for me the first time around... so I thought I'd share.

I also agree that this is not necessarily quick/novice!

mlncn’s picture

Version:8.x-dev» 7.x-dev
Status:Needs work» Reviewed & tested by the community

#43 is ready to be committed. It is a D6-to-D7 upgrade fix (to a problem that is not Drush-specific, attested to by myself and other commenters).

It only does anything if there is not already an enabled profile and if there is a profile that matches what is in the site profile variable.

This is a bug in the D6 to D7 upgrade path that this fixes, and so a D7-only problem. Once it is committed, the much rarer issue shared in D7 and D8 of insufficient feedback should there be no valid enabled profile can be taken care of. (Or alternatively allow sites to not have any profile enabled. Point is those are changes unrelated to fixing the bug in the D6 to D7 upgrade path.)

KarenS’s picture

Status:Reviewed & tested by the community» Needs work

#43 does not fix all the problems noted, and #56 indicates that the patch in #43 is broken and not tested. I see no comments that indicate #43 is 'reviewed and tested'. I tend to agree that fixing the upgrade path in D7 is something that needs to be fixed separately from any D8 issues, but that is not the usual order of things.

vas.ua’s picture

Status:Needs work» Needs review

#108: install_profiles.patch queued for re-testing.

catch’s picture

Version:7.x-dev» 8.x-dev
Status:Needs review» Needs work
mlncn’s picture

I tested #43 (on multiple sites that had this undefined index notice, upgrades with Drush, without Drush, and most recently on a Gardens exported site) and the fix was also confirmed in #51 by msonnabaum and #52 by BTMash.

pillarsdotnet’s picture

Status:Needs work» Needs review
StatusFileSize
new2.05 KB
FAILED: [[SimpleTest]]: [MySQL] 35,680 pass(es), 58 fail(s), and 21 exception(s).
[ View ]

I got the same notice when installing the Minimal profile of a fresh checkout of D8.

The attached patch fixes the problem for me; ymmv.

pillarsdotnet’s picture

StatusFileSize
new2.05 KB
PASSED: [[SimpleTest]]: [MySQL] 35,720 pass(es).
[ View ]

Fixed typo modules_list() --> module_list()

pillarsdotnet’s picture

Note that writing a test for this is blocked by #279515: setting an installation profile for a test doesn't run hook_install_tasks()

EDIT: Apparently not, according to sun's comment.

pillarsdotnet’s picture

Assigned:Unassigned» pillarsdotnet

Will try to write a test.

pillarsdotnet’s picture

Assigned:pillarsdotnet» Unassigned
StatusFileSize
new2.3 KB
PASSED: [[SimpleTest]]: [MySQL] 35,916 pass(es).
[ View ]
new88.55 KB
new163.71 KB
new101.22 KB

Wrote a test, but it passes, even though it's doing (afaict) the same thing I do to reproduce the bug manually.

Help, anyone?

pillarsdotnet’s picture

StatusFileSize
new2.48 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch minimal-install-profile-test-1170362-148.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Moved test to core/modules/simpletest/tests/minimal_profile.test as per catch on irc.

pillarsdotnet’s picture

Truncating the {cache_bootstrap} table makes the error go away.

Steps to reproduce:

  1. Install Drupal 8 with Minimal profile

  2. Immediately visit the admin/modules page. Note the following error:

    Notice: Undefined index: distribution_name in drupal_install_profile_distribution_name() (line 106 of /var/www/core/includes/install.inc).

  3. Refresh the page. Note that the error persists.

  4. Truncate the {cache_bootstrap} table, e.g. by running mysql d8 -e 'delete from cache_bootstrap' from the command line.

  5. Refresh the page. Note that the error goes away.

BTMash’s picture

@pillarsdotnet, Looking through DrupalWebTestCase, setup() calls on $this->resetAll() which flushes out the cache. So its doing the same as your truncating the cache_bootstrap table and thus the error doesn't come up.

I can kinda see why it is doing what it is but its not helpful in our scenario :( The other way I see to do this is to basically replicate what is there setup() but that seems like a poor way to approach this issue. The other option I see is to do what we're attempting in #1364798: Impossible to generate meaningful diffs of upgrade db dumps where we install version X of drupal in a subdirectory using the webrunner which would give us better control on what is going on.

BTMash’s picture

Ok, seems like resetcache might not be the culprit. But I do see variable_set also occurring and since that also clears out the cache bootstrap, I'm wondering if that is the other area this might be coming in from.

sun’s picture

Status:Needs review» Needs work

It is not clear why or how the distribution_name error is related to this issue. I concur with it perhaps being a related symptom, but that is not guaranteed. The recently submitted tests and code changes only attempt to workaround that symptom, but do not attack the actual cause.

To fix this issue, we need clear steps to reproduce how the installation profile can get disabled without intention, so we can re-implement those steps in an automated test. -- if there actually are any ways unrelated to Drush to trigger this issue.

As outlined in #135, nothing will be able to fix existing broken sites where this issue occurs, as we're unable to restore the original install profile name in case it got lost.

sjong37’s picture

Version:8.x-dev» 7.12

Help, what should I do? I am trying to following this thread but am lost. I was directed here from other posts. I get the starting message when trying to add a calendar module to my hosted version of my site.

Here is my set up. D7.12 works fine on my local computer which uses Acquia Desktop control panel. Works great, love it!

But once I uploaded the site to my client's host, I get the above message when trying to add the calendar module and can not upload the new module.

In trying to understand these posts, I looked in the mySQL database and found both entries in the System table: modules/profile/profile.module and profiles/standard/standard.profile. And of course find both in my file directory. From here, I am lost. What can a designer/builder (not developer) do to solve this problem?

Thanks in advanced.

sjong37’s picture

Version:7.12» 8.x-dev

add to post #153. I changed the Status value from ) to 1 for filename profiles/standard/standard.profile in mySQL. The message did not display first thing when accessing module page but still crashes when trying to add module.

pillarsdotnet’s picture

Apparently the fact that a normal installation with Minimal profile throws a user-visible PHP warning is not a bug?

Sheldon Rampton’s picture

Well, for a "novice" issue this has turned into quite a time-consuming headache for me. My problems started when I was assigned to update Drupal core and contrib modules for a website that was originally built a year ago using Pantheon for hosting. Since then, Pantheon has made some changes to its hosting setup. A year ago, they were putting an extra installation profile named "pantheon" inside the profiles directory. That installation profile contained a function named pantheon_install().

Subsequently, Pantheon has deprecated the installation and replaced it with a module named "pantheon." When we migrated to their new hosting setup, they applied a patch which created the new pantheon module inside the sites directory. However, their patch did not remove the old profile. This meant that when I ran update.php, I was getting a fatal error because there were now two functions named pantheon_install(). (One was in the Pantheon profile. The other was in the Pantheon module.)

"Well," says I, "I'll just delete the Pantheon profile, and all will be well." The folks at Pantheon agreed that this was the way to go. As soon as I did that, however, I started seeing other problems on the modules update page, including the "Undefined index: distribution_name" notice. My website also began failing when I attempted to check for new module updates at http://mysite/admin/reports/updates/check. Moreover, I realized that was unable to see the pantheon module listed when I went to admin/modules/update. Presumably this is because D7 regards it as a "required core" module and therefore hides it.

I was able to get rid of the "Undefined index: distribution_name" notice by restoring the deprecated Pantheon profile and simply commenting out the duplicate pantheon_install() function so that I could run update.php without getting a fatal error. However, I still can't see the pantheon module from admin/modules/update, so I can't disable or enable it there.

Jens Peter’s picture

I got a similar error and reading through this node as a designer, I am a bit lost in what I should do...
I upgraded from version 7.12 to version 7.14 and now I get the following error:

Notice: Undefined index: name in system_requirements() (line 39 af /var/www/domaine/www/modules/system/system.install).
Notice: Undefined index: version in system_requirements() (line 41 af /var/www/domaine/www/modules/system/system.install).

I hope someone will be able to point me to a solution that I understand.
Thank you.

James A’s picture

As with #157 I have started getting this issue upgrading from 7.12 to 7.14. I have roled back and tried going to 7.13 and still get the issue. Again the error is lines 39 and 41.

Any help would be appreciated.

James A’s picture

Fixed my issue! I was using a commerce_kickstart build and had not copied the commerce_kickstart folder to the new profiles folder (copied from the core upgrade). Once done I no longer get the error described in #157 and #158. Unfortunately, I think you need this folder in place before you run the update.php otherwise it didn't appear to cure the problem.

gtaylor’s picture

I'm also getting

Notice: Undefined index: distribution_name in drupal_install_profile_distribution_name() (line 202 of .../drupal-7/includes/install.inc)

after upgrading 5-> 6 -> 7.12 -> 7.14

innerservice’s picture

I have experienced the same issue - Upgrade from 6.x to 7.x -

Is there any conclusive fix for this? It appears there are many
suggestions however nothing seems to be final.

KarenS’s picture

If you need a fix for a current D7 site before this patch gets worked out, see my comment at http://drupal.org/node/1170362#comment-5218718. Those things also need to go into some sort of update hook in any fix.

BrendanP’s picture

Just wanted to post my experience in case it helps others.

I had this issue after upgrading a commerce-kickstart install from 7.12 > 7.14

Running drush vset install_profile standard solves the issue for me.

donquixote’s picture

@BrendanP: #163
My install profile is also set to "default" instead of "standard".
I am trying to change the variable value, but with no effect. It says it is changing the variable value, but then it still has the old value. Duh.

---------

@others:
I understand we want to solve the structural issue here, not just fight symptoms.
BUT, most people on Drupal 7 having this problem just see the two annoying and confusing error message fired in system_requirements(). Maybe no further effects whatsoever.
Notice: Undefined index: name in system_requirements()
Notice: Undefined index: version in system_requirements()

I would strongly suggest that we produce a "low-hanging-fruit" D7 patch, that simply turns the confusing error message into a more useful one. Instead of "undefined index" it should say sth like

Your install profile is set to 'default' (or whatever), but there is no module with this name. The developers of Drupal core are trying to find out why this happens, and will hopefully fix this in a future Drupal release. More information on ... (link)

This message can be shown in the status report, and can be ignored on any other pages.

4kant’s picture

@donquixote: I agree, let´s make drupal speak like HAL 9000. Maybe it´s worth one whole major version...
But to be serious: messages could in fact be more friendly sometimes.

donquixote’s picture

Duh, why do I know nothing about HAL 9000. Yes, i can google it :)

The point is, currently we do not show a message, we let php do it. And this is wrong.
If we already know that something could break, then we should define the damage behavior, not let PHP do it.

Whether we openly admit in the product that this is a bug in core, and how we phrase that, is a different question. At least this would be honest, and not leave the user in a position of "what did I do wrong".

(side note) Similarly, we could report other inconsistencies, such as, "the active theme is disabled", or "the active theme does not exist", or "the following enabled modules do not exist" etc, that may be triggered by bugs in Drupal core, broken upgrade path, or just by checking out a different git branch. (/side note)

Sheldon Rampton’s picture

I like donquixote's suggestion. I don't care about the exact wording, but an explanatory message from Drupal certainly would have helped save me some time when I ran into this, as I noted in comment #156.

steinmb’s picture

StatusFileSize
new1.45 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch mimimal-install-profile-1170362-168.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Re-rolled for Drupal 7. No test's in this patch though.

quantos’s picture

Commerce_kickstart looks to be my problem too. I actually thought it might not be needed (after the initial install) and so didn't upload (via source control) when I updated core from 7.12 to 7.14. I then tried editing the db table for status 0/1 and another trick suggested elsewhere. Both failed.

I've now re-uploaded the commerce_kickstart profile folders and re-run update.php but I'm still getting:

Notice: Undefined index: distribution_name in drupal_install_profile_distribution_name() (line 202 of /home/peachydev/xxx.xxx.com/includes/install.inc).

Will have to come back to this later as I'm now spent way too much time on it.

@donquixote after all this, is it safe to say we can actually just ignore this message and that no harm is being done?

Thanks.

Q

steinmb’s picture

@quantos pls. try patch #168

earnie’s picture

is it safe to say we can actually just ignore this message and that no harm is being done?

Only if you can execute update.php without it needing to update anything can it be ignored. So the harm would be if the error is getting in the way of an actual update needing to be performed. If the system gets an error during update.php execution then it aborts the update and no other module updates are executed.

quantos’s picture

thanks @steinmb, looks like I need to read of installing patching next then. Makes designers like me very nervous. :)

and "oh dear" @earnie. That doesn't sound good.

Q

steinmb’s picture

Patching is safe and if things don't work just roll it back :)

cecrs’s picture

StatusFileSize
new1.13 KB

I had this problem. After much (!) reading, I have come to the conclusion that the source of the problem was that I did a localhost install of D7 using Acquia. I then updated to 7.14, but not through Acquia. My speculation is that the install profiles got messed up in that process. At any rate, I applied patch #168, and got this:

File to patch: /Users/cecrs/Sites/acquia-drupal/includes/install.inc
patching file /Users/cecrs/Sites/acquia-drupal/includes/install.inc
Hunk #1 FAILED at 28.
1 out of 1 hunk FAILED -- saving rejects to file /Users/cecrs/Sites/acquia-drupal/includes/install.inc.rej

However, it worked! No more error on the modules page. I went and looked at install.inc.rej, but I'm too much of a noob for it to have had any meaning. ;) For what it's worth, I have attached install.inc.rej...
:)
-cecrs

Update:
The error on the modules page was fixed, but I was still getting the line 39/41 errors on the administration page. I did some more digging around, and found http://drupal.org/node/1186196. I added the acquia profile folder to the updated profiles folder, changed the value in the system table from 0 to 1 (for the acquia profile), and the problem was totally fixed.

Out of pure curiosity, I reverted to the original, unpatched install.inc file and ran update.php. No errors.

:)

Boobaa’s picture

Patch in #158 applied cleanly to drupal-7.15 without offsets and solved my issue: no more annoying messages. TL;DR about the root of the problem, though, so not touching the issue status.

amontero’s picture

For the record, I was experiencing the "Undefined index: distribution_name" error, and eventually I ran drush rr and noticed this in the output:

$ drush rr
Manually deleted 1 stale file from the registry.                                                               [success]
A file has been declared in a module's .info, but could not be found. This is probably indicative of a bug. The missing file is profiles/dbcreate/dbcreate.profile.                                                                            [warning]
The registry has been rebuilt.                                                                                 [success]

'all' cache was cleared

By now, seems that the error went away.

oerjann’s picture

You ment patch in #168, and yes it also solved the issue for me :)

oerjann’s picture

This path fails on Version 7.17. Could you please make an updated Version of this patch that will work on Version 7.17

pillarsdotnet’s picture

@oerjann - Yup; just as soon as the 8.x version gets fixed and applied.

kaizerking’s picture

I have installed to install profiles picked up from features
I am getting the menu rebuild error. runnin update.php,gives a PDO.
when we have such instances there will be some code clashes in system, and install
what will be better is a
1.standard default
2. order of priority i.e which profile is 'master' and which is slave.
3. the one initially selected while installing should act as master and other as salve,
then the dependencies priority should prevail in that order.in the even of uninstalling the master then the slave should prevail.

in the event of uninstalling both then a fall back to standard should happen

arnested’s picture

Reroll of steinmb's Drupal 7 patch in #168. This patch will apply to 7.17.

mntash’s picture

Ok, so will this patch work? What about the method in post #8 which changes the status of the profile in the database? I tried that and it reverted back to 0.

tlcharland’s picture

Status:Needs work» Needs review
Issue tags:-D7 upgrade path, -needs backport to D7

#108: install_profiles.patch queued for re-testing.

Status:Needs review» Needs work
Issue tags:+D7 upgrade path, +needs backport to D7

The last submitted patch, mimimal-install-profile-1170362-168.patch, failed testing.

stuzog’s picture

Trying to update Commerce_2.0-rc4 to 2.0 with drush or via Web, getting the error in drush: "The commerce_kickstart directory could not be found within the modules directory [..../path/to/]/profiles/commerce_kickstart, perhaps the project is enabled but has been deleted from disk"; and "Downloading updates failed: commerce_kickstart-7.x-2.0-core.tar.gz does not contain any .info files." from Web update/

drush up lists: [Commerce Kickstart 7.x-2.0-rc4 7.x-2.0 Update available]. Can't find any profile listing in the system table in the database. Everything else is up to date. Is the only solution to copy across all the latest modules from profiles/commerce_kickstart/modules/commerce_kickstart directory from a fresh download?

oerjann’s picture

#181 also work for version 7.18

iDropper’s picture

Version:8.x-dev» 7.x-dev

I recently upgraded from an acquia 7.16 local install to 7.18 using the drupal.org download and encountered the same line 39/41 issued noted in comment #157. After reading through the responses, I (a very green drupal novice) opened my database, opened the system table, found the only entry that ended in .profile, and changed the number in the status field from 0 to 1. I restarted the drupal stack, reopened my local site, and the error messages were gone.

Is there anything else that I need to do to see if this solved the problem or created additional problems that will plague me later?

earnie’s picture

Version:7.x-dev» 8.x-dev

Please do not change the Version until the 8.x-dev patch has been applied.

vintorg’s picture

Same here. I got done upgrading from 7.18 to 7.19 and got the same errors. I found the profile entry in the systems table, set the status to 1, cleared cache, and the errors are gone.

knalstaaf’s picture

In reply to #189: carefully though. I carelessly followed your advice and my site got PDO'ed and things looked quite sinister with notices like "Additional uncaught exception thrown while handling exception". Could get it all back by running update.php luckily enough.

But your advice does work though. You only have to make sure you apply it to the right record. In my case there are two profile records in the system table:

  • The default one (modules/profile/profile.module)
  • The one that my theme uses (profiles/MYPROFILE/MYPROFILE.profile)

The status that had to be changed according to your instructions (and those of KarenS in #121) is the one of the profile you're using (the second one in my case).

knalstaaf’s picture

Issue summary:View changes

Ading a blurb at the top for novices.

JohnAlbin’s picture

Issue summary:View changes

add work-around to lessen the number of "me too!" comments.

stephit’s picture

Just FYI for anyone who might be helped by this module - I made the mistake of removing an installation profile and was getting the error message. This Profile Switcher module allowed me to switch to the standard install profile and fixed the error:

https://drupal.org/project/profile_switcher

ohthehugemanatee’s picture

Another FYI on this: I just wrote a blog post on how to go from an install profile to vanilla drupal. It's a bit more fleshed out than the one liner workaround above... includes moving all the code out of the profile, updating module/library locations, and using drush to update the saved install profile.

It's a good place to start if you're trying to get out of a relatively simple install profile... I'm working on a followup post for a complex use case (Commons).

Mod74’s picture

Thank you to #190 and all the previous replies it builds off.

I had two entries in the (profiles/MYPROFILE/MYPROFILE.profile) section and wasn't sure which I should change.

So just as a quick FYI the profile your site is using is listed at the top of the page under Admin>>Reports>>Status Report

(admin/reports/status)

I made the change and touch wood this error has gone away. I was getting mighty fed up of manually hacking the .inc files after every update!

Alauddin’s picture

+1 for #191 and profile_switcher module.

it was pretty simple...

1) enable module
2) configure > switch to standard
3) disable and uninstall

ps - just make sure if you have custom profile, to move any 'modules' from within the profile folder to /sites/all/modules
that way you can just dump the custom profile for good and just use drupal standard script.

warning: some modules dont play well when you switch folder location so make sure you take backups :) in general if you move location and flush cache the modules path should refresh and work.

dkane’s picture

+1 for #194. Switching from to Minimal then back to standard solved the issue for me!

The last submitted patch, 148: minimal-install-profile-test-1170362-148.patch, failed testing.

ñull’s picture

After upgrading from D6 to D7, the profile entry in the system table was totally missing. Following suggestion in #191 and #194 I installed profile_switcher that told me it was set to standard. I switched to minimal and from then on the PHP Notice disappeared.

kreatIL’s picture

I got the same error after upgrading from d6 to d7. I had no profile available inside my new d7 installation that fit, except for "minimal", "standard" and "testing". The one that drupal demanded was "drupalcenter". #191 (profile switcher) did it for me. The warning messages went away.

pixelloa’s picture

This is the easy fix that I have found to work:
https://www.drupal.org/node/1170360

Insert: if ( ! array_key_exists('distribution_name', $info)) $info['distribution_name'] = 'Drupal';
BEFORE the existing line that says: return $info['distribution_name'];

Normally between 202 and 207
~cheers!

kreynen’s picture

https://www.drupal.org/project/profile_switcher can now fix this as well on D7 sites.

jelo’s picture

Ran into this after a D6 Acquia site update to D7. Profile Switcher fixed this by easily allowing me to change from Acquia to Standard profile.