Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
'Minimal' install profile.
Fill DB settings with my local MySQL info.
Default country: Spain
Timezone: Europe/Madrid
Unchecked "Check for updates automatically"
Message Notice: Undefined index: minimal in system_list() (line 194 of core/includes/module.inc).
appears above "Congratulations, you installed Drupal!" at finish page.
Using latest 8.x (594be7b)
Comment | File | Size | Author |
---|---|---|---|
#7 | drupal8.installer-notices.7.patch | 413 bytes | sun |
Comments
Comment #1
webchickYeah, I received a similar error in Spark w/ all of our contributed modules:
Here's the surrounding code from system_list():
Comment #2
sunThis must be a difference between the interactive and non-interactive installer, since the non-interactive installer does not throw these notices (all web tests are using the non-interactive installer to install Drupal now).
There's a popular spot in the installer with regard to that, and it happens to be on the install configure form -- the JavaScript on that page triggers a HTTP request to the freshly installed site, and that's probably the cause.
We should try to validate this by triggering a form validation error on the final install configure form; e.g., by leaving out a #required form field, so the form gets re-rendered. If the notices are triggered by that page/form, then they will appear on the subsequently rendered form. If not, then we need to search elsewhere for the problem.
Comment #3
salvisI'm seeing the same thing as the OP in the current HEAD (cb1248b).
Comment #4
sunComment #5
webchickEh, they're just notices. Not worth holding up features.
Comment #6
webchickTriggering a validation error on that form is harder than it looks, due to the HTML5 required attribute + email field. :) I managed to do it by entering a username of "*&@((!@", and it does indeed then trigger the notice on the configuration form. Conveniently, it does this consistently every time the form is submitted with an error, making it a much shorter path for debugging.
system_list() gets called twice on this page. The first time, minimal is not in $module_files, the second time it is.
I threw in a:
and this gave me:
The system_list() that's working fine has this callstack:
Comment #7
sunComment #8
webchickNope. :\ Doesn't solve the problem.
Comment #9
sunWorth a try :)
So the actual problem is that config system.module is not empty, while state system.module.files is empty.
system.module.files is populated by system_rebuild_module_data().
It may not get populated, because the database is not available yet when system_rebuild_module_data() is invoked by the installer.
Comment #10
sunWhen installing with verbose error_level, the pretty-formatted backtrace is this:
Just for the record: I *love* the new pretty/verbose error messages. :)
Comment #11
steveoliver CreditAttribution: steveoliver commentedhappening for me. Hope I can help.
Comment #12
ytsurksame here, only happening with the minimal profile.
Comment #13
webchickTagging with Spark.
Comment #14
sunBased on the backtrace in #10, it is possible that my patch in #1798732: Convert install_task, install_time and install_current_batch to use the state system might resolve this issue.
Comment #15
webchickSadly, no.
Comment #16
sunThanks for testing.
So I recently tested the interactive installer for #1798732: Convert install_task, install_time and install_current_batch to use the state system and some others issues like hell (I still need to defragment my disk ;)), and apparently, I never saw this PHP notice in my testing.
However, I am perfectly able to reproduce the PHP notice.
Apparently, there's a single, subtle difference between all the testing I performed for aforementioned issue(s) and the environment in which I can reproduce the PHP notice:
As documented in The Ultimate Guide for Contributing to Core™, the essential difference between my tests is a
/scratch
subdirectory — i.e., the PHP notice appears when installing Drupal NOT in a subdirectory.Anyone able to confirm? :) Or am I on crack again? ;)
EDIT: Minor clarification: The testbot installs Drupal in a subdirectory, too. So that would be 100% in line with this.
Comment #17
webchickNo, sadly, I've been installing with subdirectories all along. :( And also tested a http://drupal8.loc/ install and same deal.
I can try and check #1798732: Convert install_task, install_time and install_current_batch to use the state system again today, since I was a bit distracted at a conference when I tried it before.
Comment #18
sunHm. Okay, then perhaps one additional, subtle difference which I did not check myself yet:
Pre-existing settings.php + pre-existing active config directory?
Fact is, all of my /scratch tests were performed in a completely empty environment (as I have a special
reinstall.php
script that nukes the entire environment before redirecting to install.php), and within that environment, I never saw the PHP notice.But to clarify again, just today I saw the PHP notice myself, after re-installing my "master" D8 site (i.e., not in a subdirectory), and without my reinstall.php (i.e., with pre-existing config in the active config directory).
So I'm definitely able to reproduce this issue, just not exactly sure how and when exactly...
Comment #19
webchickWhen I'm testing Spark (which is how I discovered this error to begin with), it's a completely fresh installation every single time. I
drush make build-spark.make foo
to download + install, and thensudo rm -rf foo
to start over. So definitely no pre-existing config, settings.php, any of that.I had briefly added the patch from #1798732: Convert install_task, install_time and install_current_batch to use the state system on Saturday or whatever day that was, and it didn't seem to make a difference. I'll re-add it presently and will run another test now.
Comment #20
webchickCorrection: I'll have a few meetings and then debug some stuff and then have some more meetings and then run a test. ;)
Even with the patch applied, still getting all of the notices in Spark. What's interesting is they're now happening *twice*, and I believe that wasn't the case before adding the install_task patch:
Comment #21
sonicthoughts CreditAttribution: sonicthoughts commentedcould be related to this: http://www.drupaldeveloper.es/en/notice-undefined-index-name-in-system-r...
Comment #22
webchickThis is no longer happening on the latest dev release, so presumably something in all the various bootstrap/module/extension refactoring stuff cleaned this up.