Deprecate wp_get_http()

[johnbillion]

The wp_get_http() function isn't used anywhere (apart from itself).

It's a weird function that accepts a URL and a file path, performs a GET request, saves the response to the file, and returns just the response headers with the response code bolted on. If you don't specify a file path then it just performs a HEAD request. It doesn't accept an arguments array like the rest of the HTTP API functions.

Downloading and saving an external file can be done with download_url() or with the filename argument in any HTTP API request.

This function was introduced back in the dark ages before we had a good HTTP API. Let's deprecate it by moving it to wp-includes/deprecated.php and adding a _deprecated_function() call.

[johnbillion]

The Tests_HTTP_Functions::test_get_request() unit test also needs to be removed or updated to use wp_remote_get().

[DrewAPicture]

+1 for deprecation. Would wp_remote_get() be cited as the alternative?

[johnbillion]

Replying to DrewAPicture:

+1 for deprecation. Would wp_remote_get() be cited as the alternative?

I think download_url() would be closer. I think that's the original intent of the function, anyway.

[dd32]

+1! I would recommend WP_HTTP as the replacement, as download_url() is admin-specific, and WP_HTTP is far more useful (It also allows for returning headers + downloaded file).

[swissspidy]

33709.diff​ does the following:

• Move the function to wp-includes/deprecated.php, recommending WP_HTTP as the alternative
• Updates the tests in Tests_HTTP_Functions accordingly to use wp_remote_get, all continue to pass.

[swissspidy]

Use wp_remote_get instead of wp_safe_remote_get in the tests

[DrewAPicture]

Setting ownership to mark the good-first-bug as "claimed".

@swissspidy: There should be an @see tag following the @deprecated tag, see the ​deprecated functions syntax for guidance.

Also the class name is WP_Http ;)

[swissspidy]

Add @see param, write WP_Http correctly.

[wonderboymusic]

In 33969:

Deprecate wp_get_http() - function isn't used anywhere (apart from itself).

Props swissspidy.
Fixes #33709.

[chris@…]

I don't know the official status of the ​WordPress Importer plugin but it actually uses that function in wordpress-importer/wordpress-importer.php

// fetch the remote url and write it to the placeholder file
$headers = wp_get_http( $url, $upload['file'] );

// request failed
if ( ! $headers ) {
    @unlink( $upload['file'] );
    return new WP_Error( 'import_file_error', __('Remote server did not respond', 'wordpress-importer') );
}

[DrewAPicture]

Let's reopen this pending resolution of a fix for the importer plugin.

@samuelsidler: Who would be the development point of contact to have WordPress Importer updated to use the HTTP API instead?

[samuelsidler]

Replying to DrewAPicture:

@samuelsidler: Who would be the development point of contact to have WordPress Importer updated to use the HTTP API instead?

Looks like @nacin ​touched it (in a material way) last. AKA, patches welcome.

[nacin]

@DrewAPicture, @samuelsidler: @rmccue has been working on a rewrite. He now has commit access to it, and he's planning on a beta release soon. I would not at all be surprised if he included HTTP changes.

[rmccue]

Indeed, I've already removed it thanks to #33241 (which can now be closed in favour of this one, I think). Post coming soon on the importer updates.

[SergeyBiryukov]

#33241 was marked as a duplicate.

[DrewAPicture]

Closing as fixed. See comment:13 for confirmation that wp_get_http() will be removed in the next iteration of the importer.