Issue #2950407 by tstoeckler, arnested: Make installer aware of the configured...
Merge request reports
Activity
added 1 commit
- 4d935921 - Remove the explicit creation of the files directory
- Resolved by Tobias Zimmermann
mentioned in merge request !47
35 } 36 37 /** 38 * {@inheritdoc} 39 */ 40 protected function setUpLanguage() { 41 parent::setUpLanguage(); 42 43 $this->assertSession()->pageTextContains('Requirements problem'); 44 $this->assertSession()->pageTextContains('Errors found'); 45 $this->assertSession()->pageTextContains('Translations directory'); 46 $this->assertSession()->pageTextContains('The translations directory does not exist.'); 47 $this->assertSession()->pageTextContains('The installer requires that you create a translations directory as part of the installation process. Create the directory /this/directory/does/not/exist . More details about installing Drupal are available in INSTALL.txt.'); 48 49 // Prepare the custom translations directory outside of the files directory. 50 $translation_directory = $this->root . '/' . $this->siteDirectory . '/translations'; changed this line in version 5 of the diff
- Resolved by Tobias Zimmermann
1893 1901 * error with detailed information. NULL if the file already exists for this 1894 1902 * language code. 1895 1903 */ 1896 function install_check_translations($langcode, $server_pattern) { 1897 $requirements = []; 1904 function install_check_translations($langcode, $install_state) { I think maybe instead of changing the argument to accept the entire install state we could consider adding an argument with the translation directory. That way when we add primitive type hinting we can be sure that both of these things are strings as expected rather than the nebulous thing that is install state. OTOH maybe install state should be an value object and then we'd have getters. Hmmm. I guess this is okay. Adding an issue to convert install_state into a value object with array access for BC seems like a nice way forward.
I had thought about this exact thing for a bit and then decided to go this route in particular because of https://www.drupal.org/project/drupal/issues/3182660 (or !47 on here), as that makes
install_check_translations()
need another key in the install state.Having the install state be a value object would definitely improve things, but on top of that, I think it would be great to improve the interaction of the install state with these sorts of config overrides in the early installer. I.e. I think ideally we should be able to get rid of the
$GLOBALS['config']
usage ininstall_begin_request()
(which is being touched here, as well) in favor of some form of "EarlyInstallerConfigFactory" that is accessible via the install state.But in any case I think we agree that a value object would be preferable. I couldn't find an existing issue for that, so created https://www.drupal.org/project/drupal/issues/3192990
added 218 commits
-
51ae49fd...d99b12fb - 212 commits from branch
project:9.2.x
- a3cbd557 - Issue #2950407 by tstoeckler, arnested: Make installer aware of the configured...
- 321ee84e - Remove the explicit creation of the files directory
- 3252f1af - Fix wording in deprecation message
- dfa243aa - Fix coding standards
- 22153e3a - Fix install_download_additional_translations_operations()
- eff870e3 - Name the translations directory custom_translations in the test
Toggle commit list-
51ae49fd...d99b12fb - 212 commits from branch