See the Snippets! You can get productive in minutes or waste days and debug huge amounts of free and crappy code to get to 5% of elWpAPI's functionality.

WordPress Remote Control

WordPress XMLRPC Remote Publishing API (and beyond) by Easy-to-use PHP Objects

••• Hey there! Click here to buy, download or update the WpAPI library ONLY after you read the #3 Testimonials •••

HD (Heavy Duty) Snippets

Make sure you have read the Versions page first.

Please watch the video first. An image is worth 1,000 words.
This video is almost 60 minutes long, 15 FPS = 54,000,000 words worth, to be precise!

1 | Including WpAPI-HD

<?php
// Include WPAPI-HD files first
require_once(dirname(__FILE__).'/wpapi-hd/WpAPI-HD.php');
require_once(dirname(__FILE__).'/wpapi-hd/WpAPI-HDpro.php');
require_once(dirname(__FILE__).'/wpapi-hd/WpAPI-HDexp.php');
?>

2 | Preparing a Blog Object

<?php
// Instantiate the Object
$blog = new WpAPI_Blog('http://blog.tld/xmlrpc.php', 'username', 'password');
// Instantiate the Object (override DNS resolving with hard-coded IP address)
$blog = new WpAPI_Blog('http://127.0.0.1:blog.tld/xmlrpc.php', 'username', 'password');
?>

3 | Preparing a Serial API Object

This is the simplest way to use WpAPI-HD. Pretty much same as elWpAPI, this is the serial functionality object. It requires a WpAPI_Blog object as __construct()-or parameter.

<?php
// API Client without custom WpAPI_Response decoder.
// (all methods return a WpAPI_Response)

$wpapi = new WpAPI_API($blog);

// API Client with custom WpAPI_Response decoder.
// (all methods return the result of the WpAPI_Decode($response))
// (an ErrorException is returned (not thrown) in case ->isFault())

$wpapi = new WpAPI_API($blog, function(WpAPI_Response $response){
     
return WpAPI_Decode($response);
});

// API Client with built-in decoder.
// (all methods return the result of the $response->getResponse())
// (an ErrorException is returned (not thrown) in case ->isFault())

$wpapi = new WpAPI_APIdec($blog);
?>

4 | Modifying a Post

Functionality is very similar to the elWpAPI.

<?php
// Get a post from the Server
$post = $wpapi->getPost($postID = 1);
// Import itin a new WpAPI_Post object
$post = new WpAPI_Post($post);
// Change the title
$post->setTitle($post->getTitle().' (Updated)');
// Update the post to server
$wpapi->editPost($postID, $post);
// Get the post again
$post = $wpapi->getPost($postID);
// Show the actual post and check for modifications
var_dump($post);
?>

5 | Using APIpro and APIexp

These classes are Serial API functionality helpers. Equivalents of elWpAPIpro (WpAPI_APIpro) and elWpAPIwrap (WpAPI_APIexp).

<?php
// Using WpAPI_APIpro to get important remote paths
$apipro = new WpAPI_APIpro($api);
$paths = $apipro->fud_primaryPaths();
// Using the WpAPI_APIexp to run get_posts remotely
$apiexp = new WpAPI_APIexp($api);
$allposts = $apiexp->Get_Posts('numberposts=-1');
?>

6 | Basic Multiple Requests

This is the basic WpAPI_Queue usage pattern. See the code and read the comments below.

<?php
// Prepare a new Queue object
$queue = new WpAPI_Queue();
// Add new requests to the Queue (some random stuff)
$queue->enqueueRequest($blog->openRequest(WpAPI_Requests::wp_getPostStatusList()));
$queue->enqueueRequest($blog->openRequest(WpAPI_Requests::wp_getUsersBlogs()));
$queue->enqueueRequest($blog->openRequest(WpAPI_Requests::wp_getOptions()));
$queue->enqueueRequest($blog->openRequest(WpAPI_Requests::wp_getAuthors()));
$queue->enqueueRequest($blog->openRequest(WpAPI_Requests::wp_getPostStatusList()));
$queue->enqueueRequest($blog->openRequest(WpAPI_Requests::blogger_getUserInfo()));
$queue->enqueueRequest($blog->openRequest(WpAPI_Requests::mt_getCategoryList()));
$queue->enqueueRequest($blog->openRequest(WpAPI_Requests::wp_getTags()));
$queue->setStoreFinished(true); // Enable internal storage of finished requests
$queue->executeRequests(5, .1, $speed); // Do the requests
// When using few request, we can just walk the $queue->getFinished() when done
// Only works when $queue->setStoreFinished() is set to TRUE.
// Otherwise implement handlers in $queue->enqueueRequest or store $requests externally

array_walk($queue->getFinished(), function(WpAPI_Response $response){
     
var_dump($response->getResponse());
});
// Empty the internal Finished Requests storage
$queue->purgeFinished();
?>

First a WpAPI_Queue is created. Blog specific Requests are added to the queue with enqueueRequest(). We explicitly demand the storage of Finished Requests (default is to store them). We execute the queue with 5 threads. We walk the finished WpAPI_Response Objects array and handle each response. At the end we empty the Finished storage explicitly and we may reuse the Queue object.

This Basic usage is not memory friendly when handling many requests. All objects are stored in memory and things may get crowded. It's vital to implement a handler, process the Response and discard it swiftly. Like the next method doing the same, but memory friendly.

7 | Advanced Multiple Requests

<?php
// Prepare a new Queue object (with a default handler)
$queue = new WpAPI_Queue(
     
function(WpAPI_Queue $queue, WpAPI_Response $response){
          
// Handle the response here (default handler)
          var_dump($response->getResponse());
     
}
);
// Disable internal storage of finished requests to save memory
$queue->setStoreFinished(false);
// Add a new request with a custom handler
$response = $blog->openRequest(WpAPI_Requests::wp_getUsersBlogs());
$queue->enqueueRequest($response,
     
function(WpAPI_Queue $queue, WpAPI_Response $response, $arg1, $arg2){
          
// Handle the response here (default handler)
          var_dump($response->getResponse());
     
},
     
$arg1, $arg2
); // These are passed to handler also, after first two args
// Add new requests to the Queue (with the default handler)

$queue->enqueueRequest($blog->openRequest(WpAPI_Requests::wp_getOptions()));
$queue->enqueueRequest($blog->openRequest(WpAPI_Requests::wp_getAuthors()));
$queue->enqueueRequest($blog->openRequest(WpAPI_Requests::wp_getPostStatusList()));
$queue->enqueueRequest($blog->openRequest(WpAPI_Requests::blogger_getUserInfo()));
$queue->enqueueRequest($blog->openRequest(WpAPI_Requests::mt_getCategoryList()));
$queue->enqueueRequest($blog->openRequest(WpAPI_Requests::wp_getTags()));
$queue->executeRequests(5, .1, $speed); // Do the requests
// Responses were handled in the default handler from the WpAPI_Queue __construct()-or.

?>

This example usage a default Response handler specified in the __construct()-or. Response objects are no longer stored in the Finished array and are silently discarded. All processing of responses should be done in the default Response handler. This example is memory friendlier.

Custom handlers can be assigned per Request or per Queue. Each handler receives the Queue and Request as arguments. It's easy to assign custom variables to objects that allow easy tracking and processing of the async request.

8 | DB-Driven Multiple Requests

<?php
/**
* Enqueues new Requests from the DB.
* Imaginary DB holds thousands of queued requests.
* We pull new requests from there.
* We later use the tracking_ID to tell which are finished.
*
* @param WpAPI_Queue $queue
* @param int $limit
*/

function EnqueueRequestFromDB(WpAPI_Queue $queue, $limit = 1){
     
for($i = 0; $i < $limit; $i++){
          
// Pull request from DB and enqueue it
          $request = $blog->openRequest(WpAPI_Requests::wp_getUsersBlogs());
          
$request->tracking_ID = '{some GUID here}';
          
$queue->enqueueRequest($request);
     
}
}
// Prepare a new Queue object (with a default handler)
$queue = new WpAPI_Queue(
     
function(WpAPI_Queue $queue, WpAPI_Response $response){
          
// Handle the response here (default handler)
          $tracking_ID = $request->tracking_ID;
          
$mixed = $response->getResponse();
          
// Enqueue new request when old ones finish
          EnqueueRequestFromDB($queue, 1);
     
}
);
// Disable internal storage of finished requests to save memory
$queue->setStoreFinished(false);
EnqueueRequestFromDB($queue, 25); // Enqueue 25 requests from DB here
$queue->executeRequests(0, .1, $speed); // Do the requests (0 threads = queue size)
// Responses were handled in the default handler from the WpAPI_Queue __construct()-or.
// Memory consumption was to its lower as DB handled the storage and the
// queue was self-replenishing.

?>

This is the best example. Database driven, tiny memory footprint, self-replenishing queue that starts with the same number of elements as threads and keeps adding when one it done. Minimal memory usage as responsibility is shifted towards the database. Memory friendliest.

9 | To be continued…

Aside from this, it's all very similar to the old elWpAPI. I will keep adding documentation here. There's also a new stream of posts called Snippets that will start to appear here in the next few days. Specific examples with remoteEval() and removeEvalArgs() will be available. Also WpAPI-HD subtle tricks.

Please ask questions by email and I'll quickly reply. I will also post new examples, based on the questions I get.