Splitting this off from #1170362: Install profile is disabled for lots of different reasons and core doesn't allow for that, at least cpelham has run into this, but there is as yet no step to reproduce nor obvious bug there, while there is an obvious issue with the 6-7 upgrade path and install profiles.

Comments

catch’s picture

Status: Postponed (maintainer needs more info) » Closed (duplicate)
catch’s picture

Status: Closed (duplicate) » Postponed (maintainer needs more info)
dboulet’s picture

I sometimes see the "Standard" module in the list of modules to uninstall—is that what we're talking about here? I thought that it was caused by disabling a module that is required by the install profile, such as Overlay.

catch’s picture

If it appears in the list of modules to uninstall, then it's disabled yeah, so this would be the same thing.

This should not happen just by disabling a module that is specified by the install profile if you are using the UI, although that was the issue with drush mentioned in the other issue.

If you're not using drush, could you post step by step actions to reproduce this?

dboulet’s picture

I'll try and see if I can do that. I do use drush a lot, so that could well be the cause—but all of my Drupal 7 sites so far have been new installs so the bug is not caused by an upgrade from D6.

catch’s picture

Title: Install profile being disabled on new Drupal 7 sites » Install profile being disabled on new Drupal 7 sites that don't use drush

There is a known/fixed drush bug at #898768: D7: drush dis [module] can disable profile - does not require an update from 6.x to trigger.

The other issue adds a core update to fix installs that were broken by the older drush version (since IMO it's core's fault for having stupid inconsistencies with install profile dependencies).

I opened this issue because cpelham had the issue, but was not using drush.

dboulet’s picture

Thanks for clearing that up. I haven't been able to reproduce this, so it must've been caused by using drush 3. Now using drush 4 and all seems well.

fietserwin’s picture

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

EDIT: not sure anymore about using the minimal profile when I did the original install.
partial contents of my system table:
(column order: filename name type owner status bootstrap schema_version weight info)
'profiles/minimal/minimal.profile', 'minimal', 'module', '', '0', '0', '0', '1000', ?
'profiles/standard/standard.profile', 'standard', 'module', '', '0', '0', '-1', '1000', ?

But, it is the only installation having a row for the minimal profile in the system table.

cpelham’s picture

Just to re-confirm in this thread: I got the error upon updating from 7.0 to 7.2 on a site that started as a 7.0 site and on which I have not used any version of Drush. It would appear that I initially used an Acquia Drupal 7. I don't know what other info would be helpful. If someone lets me know, I will try to post more detail.

catch’s picture

The following may help.

Name of the install profile (will be in system table if nowhere else).

List of contrib modules installed.

If you have a backup of your db prior to 7.2 upgrade the contents of the system table as a txt file would also help.

Damien Tournoud’s picture

It would appear that I initially used an Acquia Drupal 7

In that case, this is just a case of the install profile actually disappearing from the filesystem.

David_Rothstein’s picture

That seems like it could cause it... Maybe we have a problem with the instructions in UPGRADE.txt?

catch’s picture


3. Remove all old core files and directories, except for the 'sites' directory
   and any custom files you added elsewhere.

Does not mention the profiles directory.

I wonder if this is it then...

Simon Georges’s picture

It happened because "install_finished" task was apparently not executed, I'm still wondering why, and thus the "install_profile" variable did not exist.

catch’s picture

Status: Postponed (maintainer needs more info) » Closed (duplicate)

Without clear steps to reproduce, I'm marking this as a duplicate of #679730: undefined index: name" and nonsensical install profile information printed in system_requirements() which looks like it accounts for these notices without an upgrade needing to be run.

catch’s picture

Title: Install profile being disabled on new Drupal 7 sites that don't use drush » Fix upgrade documentation to ensure people don't remove profiles from /profiles
Category: bug » task
Priority: Critical » Major
Status: Closed (duplicate) » Active

Actually no, because #12/#13 is still a problem.

KarenS’s picture

I posted this on the other issue but it probably belongs here. I can't remember if I used Drush or not for this upgrade, but that's not the problem I ran into. In my case I had initially created a site using an installation profile. I was no longer using the installation profile and it has no D7 version anyway.

I started getting error messages after the upgrade (the undefined index message in the title of the related issue).

I finally figured out what happened. I still had a value in my variables table with the name of the original install profile. The upgrade script reads that variable, and without checking to see if the file even exists, creates an entry in the system table for that profile. So now I have an entry in my system profile for a non-existant profile and it is spitting errors because the profile itself does not exist (so obviously none of the values have been defined).

I have seen in comments in these threads comments like "I originally used the Acquia distribution". That would have created the same situation, a value in the system table that says there should be a profile for a site where no distribution is any longer desired.

One possible way to fix this:

1- Add instructions to the upgrade docs to be sure the D7 version of the profile gets added back, BEFORE running upgrade.txt, if a profile is still going to be used in D7.
2- Alter the upgrade script so that before adding a system entry for a profile it checks to see that the profile actually exists. If it does not, change the variable back to 'standard'.

The only downside to this fix (I think) is that if an installation profile *was* actually supposed to be used and it was left out of the D7 installation by accident, Drupal will no longer use it.

The alternative is to leave the current code alone and alter the instructions to say that if you are going to use an installation profile in D7 it needs to be added back to the D7 codebase. If not, you will have to manually alter the value in the variable back to 'default' (the D6 value for no installation profile) before upgrading.

drakythe’s picture

I just ran into this same error upgrading an Acquia Drupal 7.4.4 core install to 7.8. The error was easily resolved by rolling back my changes and then not deleting the Acquia install profile under the profile folder. Seems this should just be noted in any upgrade instructions.

joelstein’s picture

I ran into this issue when using an installation profile I created to install Drupal, which I then removed (since I no longer need it). Deleting the "install_profile" variable worked, but it would be good to check that the profile exists or something, before trying to load it.

cpelham’s picture

Deleting the install variable also made my error messages go away.

cecrs’s picture

I also had this problem. Acquia install, didn't save the acquia profile when I updated to 7.14. Moved the acquia profile into the updated profiles folder and bingo! Problem solved. +1 vote for amending the UPGRADE.txt instructions...

tim.plunkett’s picture

Version: 8.x-dev » 7.x-dev
Priority: Major » Normal