Another of those “learn from my mistakes” moments: Azure Web Sites don’t include the SQL Server PDO extension if your site is running PHP 5.5.
This I learned the hard way today.
I set up my site to run PHP 5.5.11, the version that as of this writing Azure uses. But my script halted without warning; knowing from experience that this meant there was a PHP error, I quickly popped into my site’s log and saw this entry:
[23-Jun-2014 12:52:36 America/Los_Angeles] PHP Warning: PHP Startup: Unable to load dynamic library 'D:\Program Files (x86)\PHP\v5.5\ext\php_sqlsrv.dll' - The specified module could not be found.
I spend the weekend of April 4-6 at New England GiveCamp, a weekend hackathon that pairs tech and design people with charities in the Boston and New England region.
This year, I worked for Generations Inc., a Boston-based charity that pairs senior citizens as literacy tutors for children.
The process they used for accepting volunteer applications was time- and labor-intensive. Basically, they used the Job Manager WordPress plugin to accept applications, which went into their WordPress install as a custom post type.
Then, a staff member would have to re-enter all that information into Salesforce, which they use to track volunteers, clients and related assignments.
Since Salesforce is the endpoint for managing all of Generations Inc.’s relationships, they wanted a way to take online applications and put them directly into Salesforce. So that was my project for the weekend.
Part 3 in a series on working with the WordPress XML-RPC API with PHP.
To being coding our PHP-based solution for working with the WordPress XML-RPC API, we first need to create models for each of the kinds of data we’re going to leverage. The logical place to begin doing that is with posts, since most content in a typical WordPress install are posts.
A model in this context basically means creating a class. (If you’re not familiar with classes, see this primer.)
The class will bring together not only the post fields that we can manipulate through XML-RPC — some of which are complex — but also the methods (aka functions) that will allow us to easily modify the data in those post fields. This will include methods that prepare our data for sending to XML-RPC, and interpret the responses we get back from the API.
That’s what makes a data model: The data itself, or properties / post fields, and the means to manipulate that data via methods / functions.
Why bother with a model?
Part 2 in a series on working with the WordPress XML-RPC API with PHP.
A significant amount of hue and cry in the WordPress world surrounds security, and not without some cause; a poorly implemented install is susceptible to attack, especially in earlier versions.
Such protests are amplified when it comes to XML-RPC, the SOAP service used by WordPress to allow outside access for content management.
This is largely nonsense. The fact that 9 out of 10 WordPress installs have a well-known admin url (/wp-admin), and probably two-thirds of such installs have a administrator login with the user name “admin”, is a far greater vulnerability than the presence of an XML-RPC server at a known URL.
Because hey, at least XML-RPC limits what can be done to a WordPress install, and structures how you interact with it. It’s the difference between letting your crazy uncle live in the basement, versus giving him the keys to the house: He might burn the place down, either way, but at least you know he won’t steal the silver or make a mess of the living room.
In short, making XML-RPC secure involves the same steps as making WordPress secure, and if you properly secure your WordPress site, you need not fear what XML-RPC might do.
In three previous posts, I discussed creating a single-use form nonce, a multiple-use form nonce and a time-limited form nonce.
In this post, I’ll describe creating a single-use, time-limited form nonce — that is, a token, unique to each form iteration, which can only be used one time. That will ensure not only that the form was created on our server, but also that it cannot be used a second time, and that the form was submitted in a timely fashion.
I’ll build upon my previous single-use nonce methodology, by adding an additional column to my MySQL table — which stores the time at which the nonce was created — and process the form by comparing that time to the time of the form’s submission.
Why might I want to do this? A clear case would be in ordering a commodity which is scarce, such as a concert ticket. I don’t want to allow the end user to hold a lock on that ticket forever — if he doesn’t order it quickly, I want to make it available to someone else who wants it. And I also don’t want to double-charge him if, for some reason, the form is submitted twice — such as with a refresh of the ordering page.