WordCamp Boston, 2014
Slides: https://adcwp.me/wcbos2014
Aaron D. Campbell – http://AaronDCampbell.com/
aaron@ithemes.com – @AaronCampbell
http://profiles.wordpress.org/aaroncampbell/
WordPress does an awful lot!
Many popular APIs offer pre-made libraries in several languages
Don’t Use Them!*
*Except to learn how the API works so you can write your own
Some JavaScript libraries are not optional. You can use these, but PLEASE use wp_enqueue_script()
Many APIs require you to register in advance
Once you register you usually get an API key of some kind. Often you get a key as well as an application identifier.
These are yours and are often tied to your site. Do not distribute them with your plugin and be aware that you probably need a new one if you move the plugin to a new domain.
Just choose your method. The default for wp_remote_request() is GET.
$response = wp_remote_request( $url, $args = array() ); $response = wp_remote_get( $url, $args = array() ); $response = wp_remote_post( $url, $args = array() ); $response = wp_remote_head( $url, $args = array() );
Just choose what data you are wanting to retrieve. Usually what you want is the body. The response code is often useful too.
$data = wp_remote_retrieve_body( $response ); $data = wp_remote_retrieve_headers( $response ); $data = wp_remote_retrieve_header( $response, $header ); $data = wp_remote_retrieve_response_code( $response ); $data = wp_remote_retrieve_response_message( $response );
if ( wp_http_supports( array( 'ssl' ) ) ) { // Yay! }
$params = array( 'body' => $this->_prepRequest($args), 'sslverify' => false, 'timeout' => 30, ); // Send the request $resp = wp_remote_post( $endpoint, $params ); return wp_parse_args( wp_remote_retrieve_body( $resp ) );
private function _prepRequest($req) { $defaults = array( 'VERSION' => $version, 'PWD' => $password, 'USER' => $username, 'SIGNATURE' => $signature, 'CURRENCYCODE' => $currency, ); return wp_parse_args( $req, $defaults ); }
Array ( [PROFILEID] => *** [STATUS] => Active [AUTOBILLOUTAMT] => NoAutoBill [DESC] => Annual Subscription [SUBSCRIBERNAME] => Example Man [PROFILESTARTDATE] => 2013-02-10T06:00:00Z [NEXTBILLINGDATE] => 2013-02-10T10:00:00Z [AMT] => 49.00 ... )
$key = 'twp_' . md5( $url ); return tlc_transient( $key ) ->expires_in( 300 ) // cache for 5 minutes ->updates_with( 'parseFeed', array( $o ) ) ->get();
That’s it. It’s like cache-magic
Some APIs will send information to you without you sending a request. PayPal’s IPNs are a good example. They can tell you that a recurring payment has been canceled or that a card being automatically charged every month was declined.
So how do you process data that you didn’t request? Where does it go?
add_action( 'wp_ajax_nopriv_pp_listener', 'listener' ); public function listener() { $_POST = stripslashes_deep($_POST); if ($this->_validateMessage()) $this->_processMessage(); exit; // Stop WordPress entirely }
We use admin-ajax to process incoming requests from PayPal to wp-admin/admin-ajax.php?action=pp_listener
.
You can just process the message right there (update user record, add updated info to database, etc). But what if you’re building this for other people to use? Why not fire actions that other people can hook into?
function _processMessage() { do_action( 'paypal-ipn', $_POST ); if ( !empty($_POST['txn_type']) ) do_action("paypal-{$_POST['txn_type']}", $_POST); }
In this case a ‘paypal-ipn’ action fires and is passed all the data that PayPal sent us. If there is a transaction type, then a more specific ‘paypal-{transaction-type}’ action is also fired.
Don’t reinvent the wheel. Check if WordPress does what you want.
If WordPress has it, USE IT! Otherwise don’t complain when you have to rewrite it because the latest version of WordPress broke it.
Everyone else is _doing_it_wrong(). That doesn’t make it OK.
Code samples adapted from PayPal Framework and Twitter Widget Pro – find other good examples in Otto’s plugins.