fix system_get_info(), do not discard info about the current installation profile

Setting the profile in settings.php does not solve this issue if you are not using the standard profile (e.g. my site is built on the minimal profile).

Setting the profile to standard in settings.php will essentially force this piece of code from system.install to be skipped

    if ($profile != 'standard') {
      $info = system_get_info('module', $profile);
      $requirements['install_profile'] = array(
        'title' => t('Installation profile'),
        'value' => t('%profile_name (%profile-%version)', array(
          '%profile_name' => $info['name'],
          '%profile' => $profile,
          '%version' => $info['version']
        )),
        'severity' => REQUIREMENT_INFO,
        'weight' => -9
      );
    }

I think the real issue here is that system_get_info('module', $profile) does not return any info about the current running profile.

Drasgardian is correct - but I think that the minimal profile does not need to be checked, same as the standard profile does not need to be checked. Submitting a patch.

Oops, patch doesn't work.

Carry on.

Getting the same error as well, installed trough minimal and the status report page gives 2 undefined index notices. I noticed this on 8.2.7 install; but the attached patch is for 8.4.x.

This is the same intent as the patch in #4 but with a fixed syntax. Thanks @Jaypan.

Setting to NR for testbot.

How can I replicate this issue?

Install with minimal, go to status report, see notice, apply patch, see notice dissapear after refresh.

So, like, what is this check for? (I'm thinking, shouldn't it also not throw an error if you're using some other install profile...? But I'm probably missing the point of the check.) Thanks!

Re-roll the #7 patch because it's failed to apply on 8.4.x branch.

As stated in #3 by drasgardian the problem is in system_get_info().

More precisely the extensions data collected by system_rebuild_module_data() is filtered using \Drupal::moduleHandler()->getModuleList() but the latter does not contain the installation profile, so the info gets discarded.

A patch like the following should fix the issue, but I am not sure if a better fix could be in ModuleHandler.

Jaypan may be right that skipping the info also for the minimal profile could make sense in system_requirements(), but that's a different and more marginal issue, so I am hiding that patch for now, to concentrate on the actual problem.

Feel free to propose it again as a follow-up once the real problem has been dealt with.

Thanks,
Antonio

Got several notices on drupal 8.3.2:

Notice: Undefined index: name in system_requirements() (line 46 of core/modules/system/system.install).
Notice: Undefined index: version in system_requirements() (line 48 of core/modules/system/system.install).

Patch from #14 fixed problem, thanks @ao2

This doesn't seem to be fixing the root cause. If I install the minimal profile n 8.3.x or 8.4.x I don't get the error. Precise steps to reproduce would be great. Also as a bug fix this should be accompanied by a test that fails when the fix is not present.

UPDATE: turns out I was wrong. Please ignore this comment.

Setting version (e.g. version: '8.x-0.1') in [profile].info.yml file fixed the problem for me.

I am not able to reproduce this problem with 8.4.x anymore but from the git history it's not obvious to me what change could have fixed the issue.

Problem still present in 8.5.0-rc1. Setting version in (profile).info.yml does not fix it.

Digging a bit deeper into this, the problem appears to be a consequence of the changes around install profile handling in 8.2 (8.3 ?). The kernel and moduleHandler rely on the validity of a container.modules parameter, which can be missing the install profile. In this situation, core.extension containes a "module" array and a "theme" array, and a string "profile", but the "module" array does not contain the profile.

Suggested fix, which works for our projects with this problem on 8.5.0-rc1, adds the profile to the list of modules during the rebuild of the container.modules parameter.

Let's see how it fares on the full test suite. No idea how to write a test for this, though.

Forgot to CNR.

Getting this error on a Drupal 5.5 install set up using the Config Importer profile. Applied the patch in #22 and rebuild caches: no longer have error.

#22 worked for Drupal 8.6.2

(a) patch works, and thank you!

(b) could someone please explain the purpose of the check...? why does it need to be there at all?

Thanks!

Re-enabling the install profile after it has been uninstalled feels wrong even though you're not supposed to be able to uninstall it. Also you're not supposed to be able to have an empty value here but again there are many instances when people have sites that are in this state. I think we should handle the case in system_requirements() when the profile is empty or no longer installed rather than doing a change to the install profile installation status. The patch in #22 could result in an empty string being added to the module list.

I have this error for 8.7.1

Notice: Undefined index: name in system_requirements() (line 53 of core/modules/system/system.install).
system_requirements('runtime')
call_user_func_array('system_requirements', Array) (Line: 403)
Drupal\Core\Extension\ModuleHandler->invokeAll('requirements', Array) (Line: 112)
Drupal\system\SystemManager->listRequirements() (Line: 49)
Drupal\system\Controller\SystemInfoController->status()
call_user_func_array(Array, Array) (Line: 123)
....
Notice: Undefined index: version in system_requirements() (line 55 of core/modules/system/system.install).
system_requirements('runtime')
call_user_func_array('system_requirements', Array) (Line: 403)
Drupal\Core\Extension\ModuleHandler->invokeAll('requirements', Array) (Line: 112)
Drupal\system\SystemManager->listRequirements() (Line: 49)
Drupal\system\Controller\SystemInfoController->status()
call_user_func_array(Array, Array) (Line: 123)
...

I installed drupal using an existing profile.

Same here with 8.7.1 :

Notice : Undefined index: version in system_requirements() (/var/www/www.adeupa-brest.fr/web/core/modules/system/system.install ligne 55) #0 /var/www/www.adeupa-brest.fr/web/core/includes/bootstrap.inc(587): _drupal_error_handler_real(8, 'Undefined index...', '/var/www/www.ad...', 55, Array) #1 /var/www/www.adeupa-brest.fr/web/core/modules/system/system.install(55): _drupal_error_handler(8, 'Undefined index...', '/var/www/www.ad...', 55, Array) #2 [internal function]: system_requirements('runtime') #3 /var/www/www.adeupa-brest.fr/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(403): call_user_func_array('system_requirem...', Array) #4 /var/www/www.adeupa-brest.fr/web/core/modules/system/src/SystemManager.php(112): Drupal\Core\Extension\ModuleHandler->invokeAll('requirements', Array) #5 /var/www/www.adeupa-brest.fr/web/core/modules/system/src/Controller/SystemInfoCon...(49): Drupal\system\SystemManager->listRequirements() #6 [internal function]: Drupal\system\Controller\SystemInfoController->status() #7 /var/www/www.adeupa-brest.fr/web/core/lib/Drupal/Core/EventSubscriber/EarlyRender...(123): call_user_func_array(Array, Array) #8 /var/www/www.adeupa-brest.fr/web/core/lib/Drupal/Core/Render/Renderer.php(582): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() #9 /var/www/www.adeupa-brest.fr/web/core/lib/Drupal/Core/EventSubscriber/EarlyRender...(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure)) #10 /var/www/www.adeupa-brest.fr/web/core/lib/Drupal/Core/EventSubscriber/EarlyRender...(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) #11 /var/www/www.adeupa-brest.fr/vendor/symfony/http-kernel/HttpKernel.php(151): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() #12 /var/www/www.adeupa-brest.fr/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1) #13 /var/www/www.adeupa-brest.fr/web/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #14 /var/www/www.adeupa-brest.fr/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHa...(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #15 /var/www/www.adeupa-brest.fr/web/core/modules/ban/src/BanMiddleware.php(50): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #16 /var/www/www.adeupa-brest.fr/web/modules/contrib/httpbl/src/HttpblMiddleware.php(59): Drupal\ban\BanMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #17 /var/www/www.adeupa-brest.fr/web/core/lib/Drupal/Core/StackMiddleware/ReverseProx...(47): Drupal\httpbl\HttpblMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #18 /var/www/www.adeupa-brest.fr/web/core/lib/Drupal/Core/StackMiddleware/Negotiation...(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #19 /var/www/www.adeupa-brest.fr/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #20 /var/www/www.adeupa-brest.fr/web/core/lib/Drupal/Core/DrupalKernel.php(693): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #21 /var/www/www.adeupa-brest.fr/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #22 {main}.

I'm getting this in 8.7.1 and need a work around.

It seems, any page on my site with views on it, my pages or admin pages, gets an 'uncaught exception throw in session handler' message so site not usable. After that it then goes directly to install screen telling m that 8.7.1 is already installed.

This arose only after I added a new content type or extended an existing one. Deleting the new content type made the problem go away. I have already successfully created and used lots of content types without an issue

Sorted - MySql resources issue
max_allowed_packet increased from 1M to 16M in /etc/my.cnf

Soooo I no longer remember what change I got when I applied the patch back in October, blah, but at this point (8.7.2 + patch from #22 is still applied), I do get the log messages, but, not often at all... (Again, I'm wondering if they actually went away 100% before?? And, worse still, I'm not sure how to predictably trigger these log messages -- I thought it was whenever cron runs, but I was wrong, it's not nearly that frequently. Blerg.)

Ok the one "clue" I have is that today I guess I saw them after updating Drupal core (6.x to 7.x -- went smoothly), and yesterday it looks like they happened several times while deploying batches of module updates, some of which had DB updates... it's *possible* there's a connection...?

And, I've only seen these log messages get triggered when I'm logged in -- I don't see any of them in my logs where user is Anonymous.

(Hope this "helps"!)

Notice: Undefined index: version in system_requirements() (line 55 of /path/to/core/modules/system/system.install)
Notice: Undefined index: name in system_requirements() (line 53 of /path/to/core/modules/system/system.install)

I know I just posted, BUT, I just "discovered" that it happens every time I go to /admin/reports/status

EDIT: One more: it's happening on another D8 site I have (every time I go to /admin/reports/status) -- and this other site does *not* have the patch applied (#22).

Recap of "clues" (such as they are):

• Every time I go to /admin/reports/status -- and in fact, in every instance of these errors in my logs for the last few months, Location = /admin/reports/status
• Happens with or without patch (#22).
• (meh) I've only seen these log messages get triggered when I'm logged in -- I don't see any of them in my logs where user is Anonymous.
• (meh) I saw them after updating Drupal core (6.x to 7.x -- went smoothly), and yesterday it looks like they happened several times while deploying batches of module updates.

I have these exact same Red Warnings on my new Drupal 8.7.3 web site. It was a new Softaculous (SP?) install and ran warning-free for 4 days before they showed up immediately after one of the every-three-hour Cron runs. They appear when I go to "admin/status/status report" or "admin/configuration" and sometimes "admin/people". I also noticed in "admin/status/status report/checked/details" an "Installation profile" of "(default-)" which did not appear there when the web site was running warning-free.

This issue was reported over three years ago with Drupal 8.? and seems related to a Drupal 8 change moving the "install_profile" from settings.php to ????

I am a user/web site administrator not a programmer and would like to have these warnings gone. I notice that this issue is "unassigned". Being a new Drupal 8 user and very new to this forum, does this mean that there isn't anyone currently looking into this issue? Please excuse my naivete in my questions.

Notices also appear on D8.6.17. (inherited) Site was build on a profile setup (but not passed on) by the previous agency. Profile was not minimal or standard

As reported by alisonjo2786:
- Notices appear when going to /admin/reports/status
- Patch #22 does not solve it.

Looking at this comment in #22:

The kernel and moduleHandler rely on the validity of a container.modules parameter, which can be missing the install profile. In this situation, core.extension contains a "module" array and a "theme" array, and a string "profile", but the "module" array does not contain the profile.

In my (non standard/minimal profile) case, the mentioned "profile" string isn't there, so code in patch #22 is never triggered.
Not sure if this is becauase of the different profile the site started out on, or changes in Core since patch #22.
What also springs to mind: We don't define the installation profile in settings.php any more. This might also be a factor in all of this.

Attached patch fixed it for me (as said D8.6.17).
Fully agreeing with this comment in #22:

Let's see how it fares on the full test suite. No idea how to write a test for this, though.

I updated Drupal Core on my site from 8.7.3 to 8.7.4 using the GreenGeeks update script. Afterward, all the red warnings were gone and they are still gone. I didn't see any reference to this issue in the Release Notes.

After updating to 8.7.5 I had this issue on status report. I was able to resolve by creating this patch.

wrong path on previous patch

Since it is a bug report and pervious patch was failing in the 8.8.x this might work

Triage for bug smash.

To make progress here steps to reproduce are needed. Reading through the issue I found that #11 says to Install with minimal, go to status report, see notice. Then #16 and #19 say it is not reproducible on 8.3.x or 8.4.x. Then #21 says that the problem still present in 8.5.0-rc1. And I tested on Drupal 9.3.x and it is not reproducible.

This needs steps to reproduce.

Then I search for duplicates/related issues and found #1170362: Install profile is disabled for lots of different reasons and core doesn't allow for that which is addressing the same problem, that the profile is disabled/missing. Therefore, closing as a duplicate. If that is wrong, reopen the issue, by setting the status to 'Active', and add a comment.

Also, this does bring out the fact that \Drupal::installProfile(); can return NULL (according to the doc block) and that is not handled. I made #3248052: Handle NULL return from \Drupal::installProfile for that which may positively impact the behavior here.