#phppdx: WordPress as an Application Platform

Last night, I presented to ~25-30 people at the PDX PHP meetup on “WordPress as an Application Platform”. Even though I’m no longer with Human Made, I think what they’ve done with WP Remote (and Happytables) is the bleeding edge and worthy of sharing.

Ultimately, the point I wanted to get across is two-fold:

  • Many applications you could think of building are easily doable with WordPress.
  • WordPress-based products are even more interesting when you have a few, and durable components to share between them.

After the talk, I asked Zack for his feedback:

  • Went well: introduction via Freshbooks example really set the stage for what we were talking about. Avoided misunderstanding / different opinions of what a web application was.
  • Next time: Challenge people more. Explanation of how HM built WP Remote was a bit surface level. Could’ve gone deeper into the architecture as a frame of reference for people when they run into it.


All of the references I mentioned in the slides are available at the following links.

WP Remote components:

  • Job Agency - Asynchronous jobs system for WordPress, built on WP-CLI.
  • HM Rewrite – Wrapper for the WP Rewrite API.
  • h-api – Simple, descriptive API pattern. Needs work for public consumption.

Object cache drop-ins:

Future of WordPress:

Paid feature development of open source plugins

On Twitter this morning, I asked: How do you feel about having clients sponsor development of specific features? Good idea or fraught w/ problems?

Apparently this dilemma resonates with developers:

  • Rarst: “sounds better in theory than works in practice, from my limited experience”
  • Boone: “Generally a good idea, as long as the client’s needs aren’t so wacky as to make the feature awkward for general release. You might also include something in the agreement about post-contract support of the feature. Transition from ‘I’m paying you to implement my wishes’ to ‘I’m a regular user making feature requests’ is the tricky point”
  • Eric: “If you properly vet these specific features (as opposed to blindly accepting cash) I think it’s a good idea. Biggest drawback is when the sponsorship dries up and you still have to support said feature in the plugin.”
  • Brad: “great idea, not only features but full plugins. Easy to sell them on it knowing you’ll keep it up-to-date with current WP”
  • Brady: “I’d say it’s a great route if the feature makes sense for general use, otherwise an extension/add-on might be better.”
  • David: “good idea, as long as client understands the difference between customization and configuration. Oh, and proper contracts.”
  • Nick: “As long as they understand they don’t own that feature and you may need to implement it in a more general way, it can work. One approach is to make it an addon and add the necessary hooks in core plugin. Allows you to EOL the feature if needed.”
  • George: “don’t see anything bad in developing add-ons for side income, plus you might never developed for your use.”
  • Jake: “as others said, it’s all about good expectations upfront, and not compromising the rest of the plugin’s audience”
  • Travis: “Personally, I think it is a win-win, but it heavily depends on the “strings attached” mentality of the sponsor.”
  • Ryan: “I’ve done that many times before and have encouraged it. I usually gave a big discount for open source stuff. I used to provide two prices, one for open source, one for closed source. Everyone chose the cheapest option.”

My takeaways:

  • Make sure you’re explicit about the business relationship upfront (including support scope), probably in contract. If you aren’t, it can get complicated.
  • If it fits within the scope / roadmap of the plugin, it can be a nice way to bootstrap open source development. Otherwise, it probably makes sense as an add-on.
  • Pay attention to what users want as add-ons, as you can potentially turn those into premium plugins.



In 1972, sociologists Richard Nisbett and Edward Jones hypothesized that perceptual asymmetry lay at the heart of most conflicts. They further suggested that bridging this asymmetry would assist in most conflict resolutions. They were right. Their key observation was this: People view their own behaviors as originating from amendable, situational constraints, but they view other people’s behaviors as originating from inherent, immutable personality traits. The classic example is the job candidate who arrives late for an interview. The candidate ascribes his tardiness to situations beyond his control (being caught in traffic). The interviewer ascribes his tardiness to personal responsibility (not taking traffic into account). One invokes a situational constraint to explain being late. The other invokes an insult.

John Medina – Brain Rules for Baby