Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
'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.