Gerhard Potgieter

Senior Software Engineer @ Automattic specializing in eCommerce

Uploading Files With wp_remote_post Or wp_remote_request — July 30, 2014

Uploading Files With wp_remote_post Or wp_remote_request

My job at WooThemes enables me to work on all sorts of cool projects and enables me to push the limits of what is possible with¬†WordPress each day. Some of the projects I work on that I enjoy the most is projects that involves interfacing with any sort of API service, I am a sucker for an API ūüôā

In a recent project which involved interfacing with an API service I had to upload a file to the service, and wanting to stay true to the WordPress way I naturally built the whole API interface layer using native WordPress functionality. This involved making use of the wp_remote_request function, which is called by the wrapper function wp_remote_post to send through POST requests.

After Googling for quite a while I just could not get any examples of uploading files in binary using wp_remote_post or wp_remote_request, for that matter, which resulted in me having to figure this out on my own.

The API document was straight forward, in order to upload a file you need to post it as binary to API endpoint, now there are plenty of example of doing this using cURL, so I used that as a starting point and converted it to WordPress native functionality.

The cURL way of uploading the file

curl -u username:password -H "Content-Type: application/binary" \
–data-binary @file.dat -X POST \

view raw

hosted with ❤ by GitHub

Digging through some cURL docs I found that I basically needed to set a header to binary, and then stream the file binary content as the body, and found the following way of uploading the file using either wp_remote_request or wp_remote_post

// wp_remote_request way
$file = @fopen( 'path/to/file.txt', 'r' );
$file_size = filesize( 'path/to/file.txt' );
$file_data = fread( $file, $file_size );
$args = array(
'method' => 'POST'
'headers' => array(
'accept' => 'application/json', // The API returns JSON
'content-type' => 'application/binary', // Set content type to binary
'body' => $file_data
$result = wp_remote_request( '; $args );
// wp_remote_post way
$file = @fopen( 'path/to/file.txt', 'r' );
$file_size = filesize( 'path/to/file.txt' );
$file_data = fread( $file, $file_size );
$args = array(
'headers' => array(
'accept' => 'application/json', // The API returns JSON
'content-type' => 'application/binary', // Set content type to binary
'body' => $file_data
$result = wp_remote_post( '; $args );

view raw


hosted with ❤ by GitHub

The above code shows examples of using either wp_remote_request or wp_remote_post, as you can see there is not much difference between the two, instead that with wp_remote_post there is no need to set the method header as it is a wrapper function that does that automatically.

In some cases API services will require you to do uploads with PUT requests instead of POST, in that case you will use the wp_remote_request function and just set the method header to PUT instead of POST to make a PUT request.

Hope this helps someone out there that has also struggled to do this using native WordPress functions.




Controlling WordPress Auto Updates — October 25, 2013

Controlling WordPress Auto Updates

WordPress 3.7 was just released and one major feature that it includes is the ability have WordPress automatically updated to new versions without you having to log in and click a button.

I think it is absolutely great feature and can save you so much time in having to not log into all your site and clicking buttons, however it may not to appeal to everyone.

Reliability wise the auto update feature has been tested to death in beta and release candidates and the team working on this has ensured to cover all failure points to ensure that should something go wrong it will roll back to your previous version of WordPress. Even after 25000 auto updates in the RC releases there was not one single failure.

The WordPress team has catered for controlling auto updates via an array of filters and constants, the main constant being WP_AUTO_UPDATE_CORE. With the WP_AUTO_UPDATE_CORE constant you can control to allow disabling of auto updates, only allowing minor updates to occur automatically or allowing all updates to be done automatically.

The code below shows you how to control the automatic updates for different scenarios, you will place the code in your wp-config.php file.

// Enable Automatic Updates for all updates
define( 'WP_AUTO_UPDATE_CORE', true );
// Disable Automatic Updates for all updates
define( 'WP_AUTO_UPDATE_CORE', false );
// Only allow Automatic Updates for minor updates
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

view raw


hosted with ❤ by GitHub

If you want more control of specific features such as allowing auto updates of development releases such as beta and alpha releases, or want to only enable just major or just minor updates you can do that with the use of some filters. The following code shows examples of how to control specific WordPress auto update features, this code needs to be placed in your theme’s functions.php file.

//Allow auto updates of development releases ie alpha, beta and RC
add_filter( 'allow_dev_auto_core_updates', 'wp_control_dev_auto_updates' );
function wp_control_dev_auto_updates( $value ) {
// return true to enable and false to disable
return true;
//Allow auto updates of minor releases ie 3.7.1, 3.7.2
add_filter( 'allow_minor_auto_core_updates', 'wp_control_minor_auto_updates' );
function wp_control_minor_auto_updates( $value ) {
// return true to enable and false to disable
return true;
//Allow auto updates of major releases ie 3.7, 3.8, 3.9
add_filter( 'allow_major_auto_core_updates', 'wp_control_major_auto_updates' );
function wp_control_major_auto_updates( $value ) {
// return true to enable and false to disable
return true;
// Allow auto theme updates
add_filter( 'auto_update_theme', 'wp_control_theme_auto_updates' );
function function wp_control_theme_auto_updates( $value ) {
// return true to enable and false to disable
return true;
// Allow auto plugin updates
add_filter( 'auto_update_plugin', 'wp_control_plugin_auto_updates' );
function function wp_control_plugin_auto_updates( $value ) {
// return true to enable and false to disable
return true;
// Allow auto language updates
add_filter( 'auto_update_translation', 'wp_control_translation_auto_updates' );
function function wp_control_translation_auto_updates( $value ) {
// return true to enable and false to disable
return true;

view raw


hosted with ❤ by GitHub

If you have any questions or suggestions please feel free to leave them in the comments.

WordCamp Cape Town 2013 — September 23, 2013

WordCamp Cape Town 2013

WordCamp Cape Town 2013

At the beginning of the year our team at WooThemes HQ down here in Cape Town decided to approach previous organisers of the WordCamp Cape Town event to hear what their plans was for this year and if they would be willing to give over reigns of the event to us. Without any hassle or negativity from their side they agreed and we immediately set out to start promoting WordPress in South Africa more.

We started the WPCapeTown site, which is our main site and body under which we promote WordPress. The thing to note here is that even though it is a Cape Town community it is not limited to Cape Town and we welcome any WordPress user/creator from all over South Africa.

After two very successful events during the year we are pleased to announce that this year’s WordCamp Cape Town conference is a go. WordCamp Cape Town 2013 will take place at the beautiful Cape Town Stadium on 7 November 2013 and will cater for 400¬†of South Africa’s¬†WordPress¬†small business owners, non-profit agencies, realtors, photographers, designers, bloggers, journalists and web developers

Tickets for the event went on sale Friday 20 September and all discounted early bird tickets sold out in a matter of a couple of hours, with only general tickets left at R350 each.

If you are unfamiliar with WordCamps, they are community-organised events, championed by WordPress users, for WordPress users. The non-profit event will bring together WordPress enthusiasts from across South Africa to share best practices and strategies for WordPress development. Attendees range from casual users to advanced development professionals. All attendees will have the opportunity to attend a variety of sessions, presented by industry professionals, to share ideas and get to know each other.

The speaker list for this year’s WordCamp Cape Town are still in the finalisation stages but you can be assured that it will include top local and international¬†WordPress professionals. This years theme for WordCamp Cape Town is “The Business Of WordPress”.

A WordCamp Cape Town 2013 ticket will give you access to 8 or more sessions as well as lunch, coffee, snacks, secure parking in the stadium, a free WordCamp Cape Town T-shirt and entry to the after party. Additional activities, workshops and networking events will be announced in the weeks leading up to the event.

So what are you waiting for, grab your WordCamp Cape Town 2013 Tickets before they are sold out as this a WordPress event you cannot afford to miss out on.

Deploy From Github To Plugin Repo — September 8, 2013

Deploy From Github To Plugin Repo

Deploy straight from Github to WordPress Plugin SVN Repository

Lately I have been working on quite a few WordPress plugins that are hosted in the plugin repository, and since Github is my go to version control system, I like it a lot and we use at WooThemes as well, I got a bit fed up with having to keep a local SVN copy and doing things manually.

After some googling I eventually found a bash script that enables you to deploy directly from your Github repository without the need to keep a local copy of the SVN repository, it is as simple as adding the script below to your Github repo, changing a few lines in the script and then executing it when you want to deploy to the plugin repository/

I take no credit for this script, in fact it was created by a fellow WooCommerce plugin developer, Brent Shepherd, he developed and maintains the awesome WooCommerce Subscriptions extension.

To deploy straight from your Github repository to your Plugins SVN repository, simply copy the bash script below and place it in a new file in your Github repository, I use, once the file is there you can commit it to Github so it is always part of your plugin, then open up the file and edit the following parameters.

PLUGINSLUG – Change this to the slug of the plugin on
MAINFILE – Change this to the main PHP file that contains the WordPress version number of the plugin
SVNUSER – Change this to the username of the user who owns the plugin, it will be commit under this user.

And that is it, once you have modified the file, you will have to make it executable by (chmod u+x it via terminal, then when you are ready to deploy it, go to your Github repository where you stored the file and run the following command via terminal ./

It will ask you a few questions along the way and do some checks as well as tag the version on Github for you.

#! /bin/bash
# A modification of Dean Clatworthy's deploy script as found here:
# The difference is that this script lives in the plugin's git repo & doesn't require an existing SVN repo.
# main config
MAINFILE="camptix-payfast.php" # this should be the name of your main php file in the wordpress plugin
# git config
GITPATH="$CURRENTDIR/" # this file should be in the base of your git repository
# svn config
SVNPATH="/tmp/$PLUGINSLUG" # path to a temp SVN repo. No trailing slash required and don't add trunk.
SVNURL="$PLUGINSLUG/" # Remote SVN repo on, with no trailing slash
SVNUSER="Kloon" # your svn username
# Let's begin…
echo "……………………………………"
echo "Preparing to deploy wordpress plugin"
echo "……………………………………"
# Check version in readme.txt is the same as plugin file after translating both to unix line breaks to work around grep's failure to identify mac line breaks
NEWVERSION1=`grep "^Stable tag:" $GITPATH/readme.txt | awk -F' ' '{print $NF}'`
echo "readme.txt version: $NEWVERSION1"
NEWVERSION2=`grep "Version:" $GITPATH$MAINFILE | awk -F' ' '{print $NF}'`
echo "$MAINFILE version: $NEWVERSION2"
if [ "$NEWVERSION1" -ne "$NEWVERSION2" ]; then echo "Version in readme.txt & $MAINFILE don't match. Exiting…."; exit 1; fi
echo "Versions match in readme.txt and $MAINFILE. Let's proceed…"
if git show-ref –tags –quiet –verify — "refs/tags/$NEWVERSION1"
echo "Version $NEWVERSION1 already exists as git tag. Exiting….";
exit 1;
echo "Git version does not exist. Let's proceed…"
echo -e "Enter a commit message for this new version: \c"
git commit -am "$COMMITMSG"
echo "Tagging new version in git"
git tag -a "$NEWVERSION1" -m "Tagging version $NEWVERSION1"
echo "Pushing latest commit to origin, with tags"
git push origin master
git push origin master –tags
echo "Creating local copy of SVN repo …"
echo "Exporting the HEAD of master from git to the trunk of SVN"
git checkout-index -a -f –prefix=$SVNPATH/trunk/
echo "Ignoring github specific files and deployment script"
svn propset svn:ignore "
.gitignore" "$SVNPATH/trunk/"
echo "Changing directory to SVN and committing to trunk"
cd $SVNPATH/trunk/
# Add all new files that are not set to be ignored
svn status | grep -v "^.[ \t]*\..*" | grep "^?" | awk '{print $2}' | xargs svn add
svn commit –username=$SVNUSER -m "$COMMITMSG"
echo "Creating new SVN tag & committing it"
svn copy trunk/ tags/$NEWVERSION1/
svn commit –username=$SVNUSER -m "Tagging version $NEWVERSION1"
echo "Removing temporary directory $SVNPATH"
rm -fr $SVNPATH/
echo "*** FIN ***"

view raw

hosted with ❤ by GitHub

%d bloggers like this: