Part 4 in a series on working with the WordPress XML-RPC API with PHP.
Previously I discussed the reasons for creating a data model (aka a class), that looks like a WordPress post, in order to streamline and simplify working with the WordPress XML-RPC API.
In this post, we’ll create the properties, or data, that goes into that model. This will help us make heads and tails out of what we need to send to the XML-RPC API, and what we’ll get back, when working with posts.
Captain Hook twirls his moustache at Breakfast in the Park with Minnie & Friends at the Plaza Inn by Loren Javier, on Flickr
So you’ve developed a plugin, or a theme function, in WordPress that needs to know when a taxonomy term — in a category, tag or custom taxonomy — is added, edited or deleted.
Unfortunately, the WordPress Codex barely mentions how to do this, and the examples you see out there on the Web basically regurgitate the same odd instructions, which boil down to passing in some integer parameters that can’t possibly be correct for every example.
add_action('create_stores', 'my_create_stores', 10, 1);
That’s unfortunate. So let’s clear up the mystery of how WordPress notifies plugins and theme functions of a taxonomy change, and how we can go about writing a sensible treatment for those events.
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.
In an upcoming post, I’m going to describe how one goes about hooking taxonomy changes in WordPress when building a plugin, widget, theme function or other modification.
To support that post, this post will review how taxonomy — categories, tags and the like — work in WordPress.
Prior to WordPress version 2.3, there were only two WordPress taxonomies: categories and tags.
A category dictated the “section” of a website to which a post belonged; a tag allowed one to quickly interrelate posts, usually within the same category.
That’s the way this blog uses taxonomy. I have categories which group together posts by the programming language, technology or content of the post, such as PHP or WordPress. I use tags to quickly tie together posts that have a common theme, such as latitude / longitude or DOM images.
Since version 2.3, we’ve been able to create custom taxonomy. That’s resulted in two big changes: Effectively eliminating the distinction between a tag and a category, and allowing us to create additional taxonomies, to even more narrowly define a subject.
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.