Redirect loop during installation with non-English

That is odd.

• Did the web server log anything unusual?
• Is this on a platform on which you have successfully installed Drupal 8 in the past?

I'm facing the same problem with version 9.0.2 and Italian language. No problem if I leave the default "English". I wonder how can I debug this further...

@AppLEaDaY

• Are the translations successfully downloaded to, for example,
  

  sites/default/files/translations/drupal-9.0.x.it.po
  

  ?

The next step is to get a platform config that someone else can reproduce, then use a debugger.

I cannot reproduce this (Apache and PHP from Homebrew on a Mac).

@cilefen

Yes, the Italian translation is successfully downloaded.

I have to say, for the sake of correctness, the loop in not "endless" in my case. For some reason it stops after twenty GET calls like the following.

/core/install.php?rewrite=ok&langcode=it

Response code is 302.

Not sure what you mean with "a platform config than someone else can reproduce".
As for me, I installed with composer and got a document root served by apache on an ubuntu 18.04 with php 7.4 added.

Andrea

@AppLEaDaY

The twenty times thing is probably your browser giving up.

I installed with composer and got a document root served by apache on an ubuntu 18.04 with php 7.4 added.

Yes, that's a bit what I mean. Absent any logs, someone will have to reproduce it. If php.ini and the Apache Web Server configurations are changed from the defaults, we will need them too.

@cilefen

I struggled in order to reproduce the problem elsewhere, but I couldn't.

Tried both with php 7.3 and php 7.4.

I noticed, though, when everything is OK the query string does not include the rewrite=ok pair, but just language=it. I see that pair is set in the .htaccess. I wonder why it disappears in case of success and instead stays there in case of failure.

If php.ini and the Apache Web Server configurations are changed from the defaults

I examined the main apache configuration file: no relevant changes if I compare it to the file shipped with the package and anyway no effect if I replace it with an untouched version. As for the virtual host configuration, there I did nothing different from what I usually do with an ordinary drupal installation.

I also tried to figure out what the code is doing at the moment of the failure, but with no luck so far. To be honest I didn't even understand what is triggering the retry sequence that leads to The page isn’t redirecting properly.

A.

I have this problem on ubuntu 20.04, apache, php 7.3, drupal 9.0.3, ru language. but it installs well with englisch.

I tried install in virtualbox on fresh ubuntu 20.04, apache, php 7.4, drupal 9.0.3, ru language system so no bug was detected.

I have the same problem on Ubuntu 18.04, PHP 7.4.9, Apache 2.4.46 and Drupal 9.0.5.
I use a standard vhost and setup that has always worked so far.

I can't find anything suspicious in the server logs.

I filed a duplicate issue.
Catalina, Safari/Firefox/Google Chrome (browsers all up-to-date 2020-09-05), MariaDB 10.5.5, httpd/apache 2.4.46 and php 7.4.9, all installed with Home-brew, latest versions.
A work-around that works for me: install with default "English", activate multilingual and add desired language.
It seems not to be a Drupal thing but a (universal) browser-thing. Anyone successfully installed Drupal with a non-English language? What specs?

Edit:
tried to install on my host (WIMP: Windows, IIS, PHP, MariaDB) with non-English (Dutch in my case) and it works seamlessly.
Configuration:
PHP 7.4.8
Server Windows NT IIS-328 10.0 build 17763 (Windows Server 2016) AMD64.
MariaDB 10.4.14
Uploaded screenshot with specs JBProductions,png

I have the same problem with new installation of 9.0.5 in ubuntu 18.04, nginx and Php7.3. Only I can see a 302 response of /core/install.php file.

I've debugged this and found out that for the download translations task, there is a redirect to the same url for reloading the page in the new language. But the problem is that this redirect would happen for future tasks also, as drupal goes through each previous task again till the active step. I removed the redirect because the steps are redirected correctly after they are finished and the language is displayed correctly, so no need for this one. Also, the installation of the new language returns NULL if the file already exists, but this value is used further in the install_display_requirements function, which will throw a warning if it's not array. For this, I added a check and if it's null, we set an empty array for the requirements variable.

I tested with both EN and other language, but I am really not sure if the redirect should be removed as it's been there for a long time..

I also have this problem with russian language

It looks like duplicate of already fixed

Most probably .ht.router.php is not used for build-in PHP server

Used to install core 8.9.2 in Russian without any issue

andypost@andy-HP:~/www/drupal-8.9.2$ php -S 0.0.0.0:9090 .ht.router.php 
[Mon Sep  7 14:12:33 2020] PHP 7.4.3 Development Server (http://0.0.0.0:9090) started
[Mon Sep  7 14:12:50 2020] 127.0.0.1:50920 Accepted
[Mon Sep  7 14:12:50 2020] 127.0.0.1:50920 [302]: GET /
[Mon Sep  7 14:12:50 2020] 127.0.0.1:50920 Closing
[Mon Sep  7 14:12:50 2020] 127.0.0.1:50922 Accepted
[Mon Sep  7 14:12:52 2020] 127.0.0.1:50922 [200]: GET /core/install.php
[Mon Sep  7 14:12:52 2020] 127.0.0.1:50922 Closing
....
[Mon Sep  7 14:15:21 2020] 127.0.0.1:52204 [200]: GET /core/misc/icons/333333/caret-down.svg
[Mon Sep  7 14:15:21 2020] 127.0.0.1:52200 Closing
[Mon Sep  7 14:15:21 2020] 127.0.0.1:52202 Closing
[Mon Sep  7 14:15:21 2020] 127.0.0.1:52204 Closing
[Mon Sep  7 14:15:21 2020] 127.0.0.1:52206 Accepted
[Mon Sep  7 14:15:21 2020] PHP Warning:  require_once(/home/andypost/www/autoload.php): failed to open stream: No such file or directory in /home/andypost/www/drupal-8.9.2/core/install.php on line 34
[Mon Sep  7 14:15:21 2020] PHP Stack trace:
[Mon Sep  7 14:15:21 2020] PHP   1. {main}() /home/andypost/www/drupal-8.9.2/.ht.router.php:0
[Mon Sep  7 14:15:21 2020] PHP   2. require() /home/andypost/www/drupal-8.9.2/.ht.router.php:65
[Mon Sep  7 14:15:21 2020] PHP Fatal error:  require_once(): Failed opening required '/home/andypost/www/autoload.php' (include_path='.:/usr/share/php') in /home/andypost/www/drupal-8.9.2/core/install.php on line 34
[Mon Sep  7 14:15:21 2020] PHP Stack trace:
[Mon Sep  7 14:15:21 2020] PHP   1. {main}() /home/andypost/www/drupal-8.9.2/.ht.router.php:0
[Mon Sep  7 14:15:21 2020] PHP   2. require() /home/andypost/www/drupal-8.9.2/.ht.router.php:65
[Mon Sep  7 14:15:21 2020] PHP   2. require() /home/andypost/www/drupal-8.9.2/.ht.router.php:65
[Mon Sep  7 14:15:21 2020] 127.0.0.1:52206 Closing
[Mon Sep  7 14:15:51 2020] 127.0.0.1:52214 Accepted
[Mon Sep  7 14:15:56 2020] 127.0.0.1:52214 [302]: POST /core/install.php?langcode=ru&profile=standard
[Mon Sep  7 14:15:56 2020] 127.0.0.1:52214 Closing
[Mon Sep  7 14:15:56 2020] 127.0.0.1:52216 Accepted
[Mon Sep  7 14:15:57 2020] 127.0.0.1:52216 [200]: GET /core/install.php?langcode=ru&profile=standard&id=3&op=start
[Mon Sep  7 14:15:57 2020] 127.0.0.1:52216 Closing
...
[Mon Sep  7 14:15:57 2020] 127.0.0.1:52410 Accepted
[Mon Sep  7 14:15:59 2020] 127.0.0.1:52410 [200]: POST /core/install.php?langcode=ru&profile=standard&id=3&op=do_nojs&op=do&_format=json
[Mon Sep  7 14:15:59 2020] 127.0.0.1:52410 Closing
[Mon Sep  7 14:16:00 2020] 127.0.0.1:52412 Accepted
[Mon Sep  7 14:16:04 2020] 127.0.0.1:52412 [200]: POST /core/install.php?langcode=ru&profile=standard&id=3&op=do_nojs&op=do&_format=json
[Mon Sep  7 14:16:04 2020] 127.0.0.1:52412 Closing
[Mon Sep  7 14:16:04 2020] 127.0.0.1:52414 Accepted
[Mon Sep  7 14:16:05 2020] 127.0.0.1:52414 [200]: POST /core/install.php?langcode=ru&profile=standard&id=3&op=do_nojs&op=do&_format=json
[Mon Sep  7 14:16:05 2020] 127.0.0.1:52414 Closing
[Mon Sep  7 14:16:05 2020] 127.0.0.1:52416 Accepted
[Mon Sep  7 14:16:06 2020] 127.0.0.1:52416 [303]: GET /core/install.php?langcode=ru&profile=standard&id=3&op=do_nojs&op=finished
[Mon Sep  7 14:16:06 2020] 127.0.0.1:52416 Closing
[Mon Sep  7 14:16:06 2020] 127.0.0.1:52418 Accepted
[Mon Sep  7 14:16:08 2020] 127.0.0.1:52418 [302]: GET /core/install.php?langcode=ru&profile=standard
[Mon Sep  7 14:16:08 2020] 127.0.0.1:52418 Closing
[Mon Sep  7 14:16:08 2020] 127.0.0.1:52422 Accepted
[Mon Sep  7 14:16:11 2020] 127.0.0.1:52422 [200]: GET /
[Mon Sep  7 14:16:11 2020] 127.0.0.1:52422 Closing
...

+++ b/core/includes/install.core.inc
@@ -2263,6 +2260,11 @@ function install_check_requirements($install_state) {
 function install_display_requirements($install_state, $requirements) {
+  // Some functions might return NULL for the requirements array, for example
+  // for the install_download_translation, NULL is used to say that the
+  // translation file for the selected language is already present. So, we need
+  // to avoid the invalid argument warning.
+  $requirements = is_null($requirements) ? [] : $requirements;

we should not hide errors when some broken code using API in a wrong way

#17 working for me

Since 8.5 core docs are https://www.drupal.org/node/2913019

Also there's php core/scripts/drupal server --help to use out of box

The fifth comment included an Apache Web Server configuration and IIS has been mentioned. I don't understand how this is now
"Closed (cannot reproduce)" as if the only context is the built-in PHP webserver.

I only get this error if I am using an alternative version of php 7.4 in my OS Mint 19.
If I am using native version 7.2 then I do not have this error

Ok, I see difference in rewrite=ok handling and build-in server also throws fatal but recovering

So probably needs more debug (still guess mod rewrite is a cause, or missing rewrite for IIS)

I could reproduce it on Ubuntu Desktop 16.04 LTS, Apache server 2.4.18, PHP 7.3.

The problem also occurs with drupal 8.8.9.

But the error only occurs under php7.4 and php7.3. When I switch to php7.2 the installation process works like designed.

#17 works for me.

arch linux
Apache/2.4.46
PHP/7.4.10

Drupal 8.9.7 hungarian installation

I was able to reproduce this wlth an interactive installation where the translation directory is set to a non-standard location in settings.php, i.e.

$config['locale.settings']['translation']['path'] = '../translations';

The problem occurs when install_download_translations() downloads a file (via install_check_translations() and install_retrieve_file(), respectively) that is then not found by install_find_translations() (which is called from install_select_language()) in the redirected request.

I assume it's also possible to reproduce this without a custom translation directory due to #3181644: PCRE library version 10.35 with pcre.jit=1 makes \Drupal\Core\StringTranslation\Translator\FileTranslation::getTranslationFilesPattern() regex misbehave, so people should try whether setting the pcre.jit PHP setting to 0 fixes the issue (for now).

I came across this over in #2950407: Make translations directory configurable during install so people can also try if the merge request there solves the issue. I.e. whether adding https://git.drupalcode.org/project/drupal/-/merge_requests/37.patch as a core patch in composer.json helps.

Setting the PHP setting pcre.jit to 0 works for me as suggested in #30.
pcre.jit=0

#31
Thanks! It works good on Ubuntu 18.04 \ Apache2 \ php7.4-fpm \ Drupal 9.0.7

Install new Drupal 9.1.0 on Ubuntu 20.04 with PHP 8.0 FPM ... always LOOP in French...

Ok, I can bypass : install English Drupal, and add French after...
but... it's not user friendly ;-)

Thanks
Didier

Confirm Loop Drupal 9.1.0, Ru lang
Ubuntu 20.04, php-fpm 7.4

* patch helps me
* drush install also helps

I think if users can not install Drupal - it's a critical problem
#3187634

Is everyone on this issue in fact affected by the PCRE just-in-time compiler as in #30? If yes, this a duplicate of #3181644: PCRE library version 10.35 with pcre.jit=1 makes \Drupal\Core\StringTranslation\Translator\FileTranslation::getTranslationFilesPattern() regex misbehave.

Agree with APolitsin !
If users can not install Drupal - it's a critical problem.

I can bypass because I use Drupal several years ago.
But a new "non english" user will be BLOCK...
This bug is not new...
Thanks.

Is this a duplicate of #3181644: PCRE library version 10.35 with pcre.jit=1 makes \Drupal\Core\StringTranslation\Translator\FileTranslation::getTranslationFilesPattern() regex misbehave? Whether this is critical is another matter.

I agree that this is an absolutely critical issue. And I would not consider this issue a duplicate of #3158071 just because I found this one after more than two hours struggling with my installation.

Working on Drupal for four years now this is a mindblowingly urgent issue, especially when Drupal strives to achieve a simpler and easier way for new users to install. This must be resolved very quickly otherwise we risk losing potential users!

The project has a policy on duplicate issues to help the community in cases like this. Duplicate issues hinder progress by attenuating efforts. The fact that this issue jumped two priority levels eleven days ago makes it crucial to acknowledge that a solution exists in another issue that has code to evaluate if, in fact, the other issue solves it.

#3181644: PCRE library version 10.35 with pcre.jit=1 makes \Drupal\Core\StringTranslation\Translator\FileTranslation::getTranslationFilesPattern() regex misbehave has actual code to test. If #3181644 fixes this issue—I haven't tried #3181644, I am only triaging this critical issue from a process perspective—then this issue really must be marked a duplicate. Any community member can put a large notice in the description of this issue to go over there in that case.

That said, if #3181644: PCRE library version 10.35 with pcre.jit=1 makes \Drupal\Core\StringTranslation\Translator\FileTranslation::getTranslationFilesPattern() regex misbehave does not solve this, continue here.

I just realized that this issue has code too. I missed that somehow.

@APolitsin Did #3181644: PCRE library version 10.35 with pcre.jit=1 makes \Drupal\Core\StringTranslation\Translator\FileTranslation::getTranslationFilesPattern() regex misbehave fix this for you? You made it (and this one) critical. But I am not sure which fixed it. Perhaps both fix it. #3181644: PCRE library version 10.35 with pcre.jit=1 makes \Drupal\Core\StringTranslation\Translator\FileTranslation::getTranslationFilesPattern() regex misbehave has test coverage and is closer to being merged than this issue is as of today.

#31 thanks.

@cilefen see #30 for more information. This issue can be caused by #3181644: PCRE library version 10.35 with pcre.jit=1 makes \Drupal\Core\StringTranslation\Translator\FileTranslation::getTranslationFilesPattern() regex misbehave - and I assume that for many people here the fix there (or the temporary workaround) - solves the issue. It is also possible, though, to trigger this via #2950407: Make translations directory configurable during install however. There may be other cases, as well, but to my knowledge (which may very well be incomplete) this is "duplicated" by those two issues.

So I'm not really sure what that means for this issue (and its priority) myself, but maybe that can help you make an assessment.

Let's postpone this on #3181644: PCRE library version 10.35 with pcre.jit=1 makes \Drupal\Core\StringTranslation\Translator\FileTranslation::getTranslationFilesPattern() regex misbehave. Reading this issue I'm pretty sure it is a duplicate but just in case it is not.

#30 is a good comment. Thank you @tstoeckler, @alexpott. What I want to avoid of course is all the site owners that could test this being here whilst fixes are elsewhere!

Now that #2625820: install_check_translations() sometimes incorrectly returns NULL instead of array was committed to 9.1.x I assume a lot more people will be hitting this as that basically masked this in certain configurations, see also #30. It depends on a whole bunch of factors, but basically anyone with a multilingual site that is setting the translations directory to a non-standard location (for example, outside of the webroot) is at risk of hitting this.

The fix for that will come with #2950407: Make translations directory configurable during install so would be nice to get that in before the next 9.1 release.

#3181644: PCRE library version 10.35 with pcre.jit=1 makes \Drupal\Core\StringTranslation\Translator\FileTranslation::getTranslationFilesPattern() regex misbehave is merged.

@APolitsin and others:

If #3181644: PCRE library version 10.35 with pcre.jit=1 makes \Drupal\Core\StringTranslation\Translator\FileTranslation::getTranslationFilesPattern() regex misbehave fixes this for all cases, then this would be more properly a duplicate. Is this totally fixed?

There haven't been new reports of this problem in about 2 years, which is after #3181644: PCRE library version 10.35 with pcre.jit=1 makes \Drupal\Core\StringTranslation\Translator\FileTranslation::getTranslationFilesPattern() regex misbehave was committed. It would appear that this is fixed, and is a duplicate of that issue as suggested in #45.

Therefore, I am closing this as a duplicate and moving credit over there.

If you are experience this problem and have changed the default translation directory that is being fixed in #2950407: Make translations directory configurable during install.

If you are experiencing this problem on a supported version of Drupal reopen the issue, by setting the status to 'Active', and provide complete steps to reproduce the issue (starting from "Install Drupal core").

Thanks!