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.
I’ll be at New England GiveCamp this weekend, helping Generations Inc., a Boston-based charity that couples literacy volunteers with those in need.
The GiveCamp movement promotes hackathons to assist charities with their technical needs. Mostly, New England GiveCamp creates and overhauls websites; but there are a number of other projects out there.
This year, I’ll be creating an interface to accept volunteer applications from Generations Inc.’s website and put those into their Salesforce CRM application. Thankfully, Salesforce has a robust developer support portal, which includes both excellent documentation and a fully functional sandbox, so early indications are that troubles should be few and far between. Knock on silicone.
As always, I’ll post a recap. Until then, you can follow along with GiveCamp on Twitter, hashtag #negc2014.
All links in this post on delicious: https://delicious.com/dougvdotcom/new-england-givecamp-2014-this-weekend
Part 3 in a series on working with WordPress XML-RPC in 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 WordPress XML-RPC
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.
Part 1 in a series on WordPress XML-RPC
Lately I’ve had cause to work with WordPress’s implementation of XML-RPC, which is basically a kind of SOAP service that lets you view, add, edit and remove content from outside of your WordPress install.
XML-RPC has been part of WordPress since its initial public release some 11 years ago, but is usually scorned as little more than an efficient attack vector. Which is a fair assessment; few end users need the ability to remotely publish content.
But over the years — especially the last two — as WordPress has melded into a turnkey content management solution, XML-RPC has been improved, both in terms of its base security and its functionality.
Today, it’s perfectly positioned to be a great way to manage content from outside of WordPress itself; that is, to bring in content from third-party systems (which is how I am doing it) to automating virtually any task you have that involves the actual content of your blog.