Convert drupal_http_request usage in install.core.inc to Guzzle.

+++ b/core/includes/install.core.inc
@@ -1437,7 +1439,7 @@ function install_download_translation(&$install_state) {
+ * Attempts to get a file using a http request and to store it locally.

That should be "HTTP" now I guess, instead of "http".

+++ b/core/includes/install.core.inc
@@ -1459,14 +1461,21 @@ function install_retrieve_file($uri, $destination) {
+    $data = drupal_container()
+      ->get('http_default_client')
+      ->get($uri, array('Accept' => 'text/plain'))
+      ->send()
+      ->getBody(TRUE);

@@ -1476,12 +1485,17 @@ function install_retrieve_file($uri, $destination) {
+  $request = drupal_container()->get('http_default_client')->head($uri);
+  try {
+    $response = $request->send();

I generally like chaining, but in the former case it feels like a bit much. I guess it's just a matter of taste, but I find the latter example much more readable.

Leaving at needs review, because both issues are very minor.

+++ b/core/includes/install.core.incundefined
@@ -1459,14 +1461,18 @@ function install_retrieve_file($uri, $destination) {
-  if (file_put_contents($path, $result->data) === FALSE) {
+  catch (BadResponseException $e) {
     return FALSE;

@@ -1476,12 +1482,17 @@ function install_retrieve_file($uri, $destination) {
+  catch (BadResponseException $e) {
+    return FALSE;

A curl exception is now a BadRequestException (which BadResponseException extends from), so that's what you should catch.

I think this is good to go. This is so early in the installer that we can't do exception handling and we didn't do so before, this just converts the calls.

Committed/pushed to 8.x, thanks!

I just tried to re-install with an existing database and got this message instead of the usual "you've already installed don't do it again" message:

The service definition "http_default_client" does not exist.

That's not as useful..

Reverted for now to avoid inflating the critical bugs list.

I think what is meant in #11 is that @catch did *not* drop the database before hitting install.php. He expected the usual "You've already installed Drupal, what are you doing here?" message, but instead got a fatal.

Well, but If I read that correctly, you re-installed from the start with the patch already applied. That is what seems to be the problem (that's what I assume, at least). Catch hit install.php on an existing site directly after applying the patch.

Edit: Wrote something other than what I meant...

Here's the steps (from memory so hopefully I didn't miss anything):

1. Didn't drop database

2. English (British) was autoselected - however note this fails to download with the patch not applied on my localhost.

3. settings.php was filled in etc.

4. Re-install attempted via install.php

Hmm I can't reproduce it either, followed up on the other issue though.

Committed/pushed this one.

I just tried to install in French and got "The service definition "http_default_client" does not exist." :( It goes away when I roll back this patch.

You can also set up a Guzzle HTTP Client yourself.

There is also an issue that will change how the whole thing works, but I'm not exactly sure what happens with the CoreBundle.

Not sure why I couldn't reproduce this again. Patch looks good and what I was expecting but yeah thanks for the 'needs manual testing' tag :)

+++ b/core/includes/install.core.inc
@@ -357,6 +357,16 @@ function install_begin_request(&$install_state) {
     drupal_container($container);
+
+    // Register the Guzzle http client for fetching translation file from a
+    // remote translation server such as localization.drupal.org.
+    $container->register('http_default_client', 'Guzzle\Http\Client')

The $container->register() should be moved up before the call to dupal_container($container), I think. I guess this works because objects are handled as references in PHP, but conceptually this is wrong. Here we're setting the container, and a few lines down down we're fetching it again.

Minor: http -> HTTP, translation file -> translation files,
localization.drupal.org -> localize.drupal.org

Moving to needs work for that, although, since this apparently fixes translation in other languages (I didn't try it out myself) it might (or might not) make sense to commit this as is.

Edit: Missing word.

I did below on Windows 7/Firefox-18.0.1

1. Checkout latest 8.x and apply the latest patch - checked(used patch in #30)
2. Drop database - checked
3. Remove sites/default/settings.php - checked
4. Remove directory sites/default/files - checked
5. Install Drupal via the browser - checked
6. In the first installation step select a non-English language. - checked. Selected French
7. The installation should be completed without errors. - Stopped at step 2 (see steps below)

Step 1:

Step 2:

Seems I have access to translation server:

Am I missing something here?

Seems that was my network issue. Though, I can see translation site, Drupal somehow can't access. is it worth mentioning port in help text or would it become too technical/confusing?

I manage to test it in other network and except a warning in step-6 (site information page), no error!!!

Step 1:

Step 2:

Step 3:

Step 4:

Step 5:

Step 6:

Step 7:

Step 8:

I applied @Sutharsan's patch in #30 to 8.x 2f7db4222b2afc4415b9fad0ad578b142ab8cf3d and found:

• It fixed the original error about 'drupal_http_request' and I can select a language (even ones with no translation as in #1904214: Installer auto-selects languages that don't have a translation, causing a requirements error).
• Installation with plain old "English" still works.
• Selecting another language downloaded the .po file, but resulted in a PHP error later on during the installation:
  PHP Fatal error: Call to a member function get() on a non-object in /Users/thsutton/Sites/drupal8/htdocs/core/includes/bootstrap.inc on line 2481, referer: http://ttt.dev/core/install.php?langcode=fr&profile=minimal

Forgot to change status.

@Sutharsan, the installation with no translation selected completed normally with and without the patch. Steps to reproduce:

1. git pull (updates to 0a42fa60e0bec915ac82487dc30828ae476e1080)
2. git apply install-convert-to-guzzle-1887046-30.patch
3. Select French translation and continue
4. Select Minimal profile and continue
5. Enter MySQL database details and continue
6. Error 500.

Here's the Apache error log from the start of the installation:

<pre>
[error] [client 127.0.0.1] PHP Fatal error:  Class 'Drupal\\menu_link\\MenuLinkStorageController' not found in /Users/thsutton/Sites/drupal8/htdocs/core/includes/menu.inc on line 2687
[error] [client 127.0.0.1] PHP Fatal error:  Call to a member function get() on a non-object in /Users/thsutton/Sites/drupal8/htdocs/core/includes/bootstrap.inc on line 2481, referer: http://drupal8.dev/core/install.php?langcode=fr&profile=minimal
[error] [client 127.0.0.1] File does not exist: /Users/thsutton/Sites/drupal8/htdocs/favicon.ico, referer: http://drupal8.dev/core/install.php?langcode=fr&profile=minimal&op=start&id=1
[error] [client 127.0.0.1] PHP Fatal error:  Class 'Drupal\\menu_link\\MenuLinkStorageController' not found in /Users/thsutton/Sites/drupal8/htdocs/core/includes/menu.inc on line 2687, referer: http://drupal8.dev/core/install.php?langcode=fr&profile=minimal&op=start&id=1
</pre>

I tend to agree that this is unrelated, except for the fact the leaving the language as en (with or without the patch) completes the "installation profile" phase and you can continue with configuring the site and get a working install. :-)

I installed the #30 patch as described above (language dutch). It works like a charm! Thanks.

Current DEV cannot installed if you select a language other than English. This looks still major to me.

Had the same problem when trying to install in German language but with patch from #30 it works fine!

I think that is sufficient testing that this actually does fix the problem. Code looks good as well. Let's do this!

Yes the code does indeed fix the problem. I applied the patch then did a clean install (dutch), and it worked.

Thanks for all the manual testing.

Committed/pushed to 8.x.

Just downloaded the 20 April dev version and faced this issue. Patch #30 doesn't worked for me: Hunk #1 FAILED at 356

Open a new bug report if you have a problem. This has been committed long ago.

Test instructions added