Download the PHP package rebelcode/wp-http without Composer
On this page you can find all versions of the php package rebelcode/wp-http. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package wp-http
RebelCode - WP HTTP Client
A WordPress HTTP client that complies with the PSR-7 HTTP Message and PSR-18 HTTP client standards.
Note: This package was written for use in RebelCode's WordPress products only, as a means to mitigate conflicts with other plugins; most notably, those that use Guzzle. Feel free to use this package, but please be advised that doing so can cause conflicts, which defeats the purpose of this package.
Installation
With Composer:
Without Composer:
- Copy the contents of
srcinto the directory of your choice - Use an autoloader to map the
RebelCode\WordPress\Httpnamespace to that directory - Consider using Composer instead
Usage
Creating a client instance
Sending Requests
The WpClient implements the PSR-18 ClientInterface. Requests are dispatched using sendRequest() method:
Architecture
The design and architecture of this package is loosely based on Guzzle.
The WpClient class does not actually use the WordPress HTTP API to send requests. Rather, it delegates the
handling of the request to a HandlerInterface instance. The only thing the client is directly responsible
for is resolving relative request URIs using a base URI (if one is given to the client during construction).
Handlers are objects that take a RequestInterface instance and return a ResponseInterface instance. The
WpHandler, for example, transforms the request into the array of arguments required by the
wp_remote_request() function, calls the function, then transforms the returned value into a
ResponseInterface instance.
Middleware
Middlewares are a special type of HandlerInterface: they take a RequestInterface and return a ResponseInterface.
The key difference is that middlewares do not actually dispatch the request. Instead, they receive a HandlerInterface
instance during construction and delegate to it by calling $this->next($request).
This allows for multiple middlewares to be chained together, such that the first middleware is given the second
middleware, which in turn is given the third middleware, and so on. The last middleware is then given the base handler,
typically the WpClient instance. This chaining is implemented in the HandlerStack, which is also
a HandlerInterface implementation.
Middleware classes may accept additional constructor arguments, as long as a handler argument is accepted and is passed to the parent constructor.
Example implementation of a middleware
The middleware can then be given to the HandlerStack using a factory function that takes a HandlerInterface
instance and returns the middleware instance.
If the first argument of the middleware constructor is the handler, the Middleware::factory() helper function can be
utilized to reduce boilerplate code. Additional constructor arguments can be passed as the second argument, in an array.
