WordPress erroneously follows browser-style behaviour with 3xx redirects, where a POST to 302 becomes a GET. Requests instead follows the specification and keeps the same method. Requests also exposes a hook to allow changing the behaviour.
[37428] used the wrong method of adding this hook, now corrected.
See #33055.
git-svn-id: https://develop.svn.wordpress.org/trunk@37429 602fd350-edb4-49c9-b593-d223f7449a82
Requests is a library very similar to WP_HTTP, with a high level of unit test coverage, and has a common lineage and development team. It also supports parallel requests.
See #33055.
git-svn-id: https://develop.svn.wordpress.org/trunk@37428 602fd350-edb4-49c9-b593-d223f7449a82
Known functions, classes, and methods are now auto-linked in Code Reference pages following #meta1483.
Note: Hook references are still linked via inline `@see` tags due to the unlikelihood of reliably matching for known hooks based on a RegEx pattern.
See #32246.
git-svn-id: https://develop.svn.wordpress.org/trunk@37342 602fd350-edb4-49c9-b593-d223f7449a82
Multisite functions use the term "blog" to refer to what we now call a "site," e.g. `get_current_blog_id()`. These functions are here to stay because of our commitment to backwards compatibility. What we can do is set the documentation straight.
See #35417.
git-svn-id: https://develop.svn.wordpress.org/trunk@36416 602fd350-edb4-49c9-b593-d223f7449a82
When the method was introduced in [17914], the name was underscore-prefixed as is core style for private-use, though it was also introduced with a `public` access modifier for the declaration. Due to core's committment to backward-compatibility, the access modifier overrules in this case, meaning that while the method is underscore-prefixed and was originally-intentioned to be private, it is and always will be a public method, and the documentation should reflect that.
Props Frozzare.
Fixes#35289.
git-svn-id: https://develop.svn.wordpress.org/trunk@36367 602fd350-edb4-49c9-b593-d223f7449a82
These provide a more descriptive way to set response codes elsewhere,
so it's readable and less chance for the wrong response code to be
used such as 401 vs 403.
Props rmccue for the idea.
Fixes#35426.
git-svn-id: https://develop.svn.wordpress.org/trunk@36294 602fd350-edb4-49c9-b593-d223f7449a82
The filter explicitly expects one of three passed value types:
* An array containing 'headers', 'body', 'response', 'cookies', and 'filename' elements
* A `WP_Error` instance
* Boolean false (to avoid short-circuiting the response)
Props johnbillion.
Fixes#33995.
git-svn-id: https://develop.svn.wordpress.org/trunk@34509 602fd350-edb4-49c9-b593-d223f7449a82
`class-http.php` requires functions from `http.php`, so loading it by itself wouldn't have worked.
Creates:
`class-wp-http-cookie.php`
`class-wp-http-curl.php`
`class-wp-http-encoding.php`
`class-wp-http-proxy.php`
`class-wp-http-streams.php`
`http-functions.php`
`WP_Http` remains in `class-http.php`.
`http.php` contains only top-level code. Class files only contain classes. Functions file only contains functions.
See #33413.
git-svn-id: https://develop.svn.wordpress.org/trunk@33748 602fd350-edb4-49c9-b593-d223f7449a82
Affects DocBlocks for the following core elements:
* Two arguments in `_walk_bookmarks()`
* A code snippet in the class header for `WP_Roles`
* A code snippet in the class header for `WP_HTTP_Proxy`
* Inline code fixes in the summary and a parameter description for `WP_oEmbed::discover()`
* An argument description in `_WP_Editors::parse_settings()`
* Inline code fixes in the summary and a parameter description the `embed_oembed_discover` hook.
Props rarst.
See #30473.
git-svn-id: https://develop.svn.wordpress.org/trunk@30536 602fd350-edb4-49c9-b593-d223f7449a82
Per our inline documentation standards, no further use of the `@uses` tag is recommended as used and used-by relationships can be derived through other means. This removes most uses of the tag in core documentation, with remaining tags to be converted to `@global` or `@see` as they apply.
Fixes#30191.
git-svn-id: https://develop.svn.wordpress.org/trunk@30105 602fd350-edb4-49c9-b593-d223f7449a82
These unit tests cover the expected vehaviour of certain combinations of URL's, but makes no attempt to test invalid URL structures, as PHP's behavious for invalid URL's is undefined (Some will be treated as paths, others fail, and it varies between PHP 5.4.7+ and <5.4.7).
This change also makes WP_HTTP::parse_url() protected in order to allow unit testing.
See #28001, #29886
git-svn-id: https://develop.svn.wordpress.org/trunk@29864 602fd350-edb4-49c9-b593-d223f7449a82
In older versions of PHP:
- parse_url() will fail to parse a url where the scheme break (://) is present in a relative URL's path
- parse_url() will include the hostname of a schemeless URL in the path component
This handles those two types of URL's by correcting the response from parse_url().
Fixes#28001, #29886
git-svn-id: https://develop.svn.wordpress.org/trunk@29861 602fd350-edb4-49c9-b593-d223f7449a82
A valid relative URL could be mistaken for an absolute url if it contained a :// in any position of the url.
Fixes#28001
git-svn-id: https://develop.svn.wordpress.org/trunk@29850 602fd350-edb4-49c9-b593-d223f7449a82
Previously this would use the generic message corresponding to the response code, which isn't always accurate. Since we're already parsing the headers, we can simply return that directly (This also has the benefit that it's the same code for both Streams and Curl header handling).
Fixes#28919
git-svn-id: https://develop.svn.wordpress.org/trunk@29848 602fd350-edb4-49c9-b593-d223f7449a82
