Some handy functions I use to grab values from arrays and objects (especially $_REQUEST and friends), without having to constantly run isset or !empty checks everywhere (to avoid undefined index notices). You can specify a default value if the index doesn’t exist in the array or object. Also lets you sanitize the value(s) using a callback before returning them.
#hackTO the second happened this past Saturday (Sept 26, 2010), and like the first one, it was awesome. We got a fresh batch of APIs (though, somereturning) to play with, way too much sugar, and a lot of new faces, but the formula was the same: 6-7 hours to hack together an app using one (or more) of the given APIs.
The pressure was on: as former champion of #hackTO, I had to defend my title. I decided to go big with an ambitious idea, not totally sure if I’d be able to finish in the given time. I had originally come up with the idea at the first #hackTO, but didn’t really have time to implement so I put it on my projects-for-the-future list. But this time around figured I’d give it a shot and so the WordPress InstaPaywall plugin was born.
Sadly, I didn’t reclaim my title but managed to score a third place entry. The judges apparently had a tough time deciding though, because there were a lot of really great apps developed.
Now, onto the plugin!
In its simplest form, the plugin lets you paywall your blog posts and make money by charging readers for full access to them. Paywalls are the new hotness these days and Freshbooks’ billing API seemed like a perfect fit for accomplishing this.
I think it’s important to note that I hate paywalls. I hate freewalls even more (yes, NYTimes.com, I’m talking about you!). But, it’s a model that some people think will work (and are betting their futures on), and it clearly is working for some. So, while it pains me to build something that contributes to the paywall madness — I would much rather see everyone take a Guardian-like approach; the world would be a better place if we did — it doesn’t hurt to sip the kool-aid every once in a while.
The plugin basically takes a modified iTunes-like approach: 1-click buying that you’re billed for at the start of the month.
It’s a bit difficult to run a demo, so I’ll just use screenshots instead.
Note: The plugin is a bit rough around the edges and not quite as good-looking or elegant as I would like, but what do you expect in 6.5 hours?
WP InstaPaywall — Paywall Metabox
The plugin adds a new metabox to the Edit Post screen, which let’s you enable the paywall for any given post. Once enabled, you can specify the amount that you would like to charge for the post.
Users => Freshbooks
WP InstaPaywall - Clients in Freshbooks
All users in WordPress get an associated Client entry created in Freshbooks.
All users in WordPress also get a Recurring Invoice entry created in Freshbooks. This is central to the application billing service in Freshbooks. This invoice is set to go out at the first of every month.
Rack up charges
WP InstaPaywall - A Paywalled Post
Whenever a user encounters a paywalled post, they’re shown a message indicating they can view the full content by paying a given amount. If the user agrees to pay, the amount indicated is added as an entry to their Recurring Invoice.
WP InstaPaywall - An Unlocked Post
WP InstaPaywall - Upcoming Payments
Charges for any given month add up. Users can view upcoming charges as well.
WP InstaPaywall - Monthly Recurring invoice
On the first day of the following month, Freshbooks automatically emails the invoice to the user (Freshbooks has snail mail support if you want to go old school — though, this wasn’t integrated). Then, thanks to the magic of webhooks (and a just-in-case cron job), the user’s invoice entries are cleared so they have a clean slate for the next month.
And then the cycle repeats.
The Pipe Dream (aka Potential Improvements)
My origin scope for the plugin was way bigger, but I just didn’t have enough time to implement everything. My main goal was to provide a three-pronged approach to paywalling to allow content creators the maximum flexibility. Some other ideas I had for payment models:
The Subscription Model: Pay a single fee on an ongoing basis (weekly? monthly?) and get access to all content on the site.
The Debit Model: Load up your account with money up-front and charge on a per-use basis
The (FB) Credit Model: Similar to The Debit Model, but using Facebook Credits instead of money.
The (True) Micropayments Model: Let users decide how much they want to pay, and allow content creators to set “suggested amounts”.
Other improvements and crazy ideas:
Various Payment Periods: Options to select how often the user should be billed: Weekly, Monthly, Instantly?
Auto-billing: Rather than waiting till the end of the month for people to pay, integrate with Freshbooks’ autobilling support to charge their credit cards instantly.
Track and Suspend Deadbeats: If working with the “Pay me at the end of the month” model, add safeguards to monitor, suspend and harass people who fall behind on payments.
Authenticated RSS Feeds: This would only work with the subscription model.
Analytics: Probably the most important thing next the actual payment piece. Graphs and other metrics that tell you what content is being paid for, when, where, why, by whom, and so on.
Ditch Freshbooks? I love Freshbooks, but it’s way too expensive for Joe Blogger. For this plugin to work effectively, you’d need to get one of the higher-priced accounts which start at $30/month, which means you’d have to “sell” at least $30 worth of blog posts per month just to break even. It might be easier just to integrate directly with something like PayPal. But then again, Joe Blogger probably shouldn’t be paywalling his posts anyway…
Like most of my work (e.g. WordPress projects), I’m always happy to openly release the course code. However, the code for InstaPaywall in its current state is way too “unclean” to be release-worthy. When I get a chance, I’ll clean it up and open it up to the world.
Update (2010-04-20): These Gleeks are crazy. Since being released, the clock has been viewed over 200,000 times. Insane.
If you like Glee, you’ll like this. If you like image processing using PHP, you’ll like this even more.
Don’t have code yet, but I’ll post it when I get a chance.
Update (2009-12-21): So, the original technique that I had posted is a bit hacky and kinda gets annoying when you have lots of categories and category templates. There’s a better approach that can add to your functions.php file to make everything work magically, which was inspired by Justin Tadlock‘s comment on a post by Elliot Jay Stocks. Code below:
Add to your theme’s functions.php file and edit as necessary. For example, to redirect to categories with IDs 1 & 5 to a template called gallery.php, change the if statement to:
Note: the stuff below is old, crappy, “legacy” code. Still here for posterity…
WordPress has an amazing theming system. It’s not perfect, but if you know the right things you can bend it to your will and do a lot of cool things. One great thing about it is the template hierarchy; WordPress basically allows you to create custom templates for categories, tags, authors, etc.
For example, if I add category.php to my theme, all category pages will now be styled according the structure within the category.php file. Now, let’s say I have a category called “Photos” that I wanted to look a little different from the rest. (Let’s assume the category ID for “Photos” is 6). All I have to do is add category-6.php to my theme, modify it to whatever, and the “Photos” category page will switch to this new template. Cool? Definitely.
With a system like this, you could technically customize your site to the point where the every category, author, tag, etc. page has a unique look and feel. But, that’s quite a lot of work and in most cases unnecessary. There may be cases though, where you want a small subset of categories to have a unique look, and you want these pages to share this look. Unfortunately WordPress doesn’t allow different pages to share templates. (Intuitively, I would think that something like creating a file called category-6,7,8.php [or similar] would apply this template to categories 6, 7, and 8). You could technically set up separate files (category-6.php / category-7.php / category8.php) and just copy and paste the code across all of them, but that’s a maintenance nightmare. A single change will have to be copied over multiple times, and that’s just annoying.
There are a few ways around this. One of easy ways is to use Idealion’s Category Enhancements plugin. Alternatively, if you want a more theme-level solution, follow the steps below. This is something I discovered while building out the image gallery pages for The Boar (links of what I came up with are at the bottom).
1. In your theme folder, create the category files for the categories you want to apply the custom template to.
Let’s assume we want to apply it to the categories “Portrait Photography” (ID: 5) and “Nature Photography” (ID: 12).
In this case we’d create category-5.php and category-12.php
2. In the category template files (category-5.php & category-12.php), add the following:
<?php require_once('common_template.php'); ?>
3. Create a generic category template: common_template.php
4. Then in the common_template.php, add the following:
<?php get_header(); ?>
<?php echo 'Hello World!'; ?>
<!-- The rest of your custom template goes here -->
<?php get_footer(); ?>
5. Now, if you navigate to http://your-site.com/?cat=5 and http://your-site.com/?cat=12, you’ll notice that their look will mirror what you included in common_template.php
I should note that this approach isn’t limited to category templates; you can use this with author and tags templates as well. Technically, with this approach you could combine multiple categories and tags, as well (though if you do, be wary of category- and tag-specific functions and make use of conditional tags).
You can see an example of this in action at the links below:
Today, I released the first public version of the Co-Authors Plus plug-in for WordPress, which allows multiple authors to be added to Posts and Pages. The plug-in is an extension of the Co-Authors plug-in created by Weston Ruter.
The plug-in is a result of a this conversation, namely how to deal with users as your userbase grows, a genuine problem facing newspapers, magazines, and community sites using WordPress, and a problem I’ve been toying with for a while now while working on website for The Boar.
Currently, WordPress allows only a single author per Post/Page. Weston’s plugin fixed that problem. However, the other design problem it failed to overcome was the usage of drop-downs to assign users to Posts/Pages. Once you scale up to 10+ users, this starts to become unmanageable (and when you start pushing 100+ it really becomes a problem).¬† Granted, the typical blog would not deal with this problem. Granted, the design is only a problem when you dealing with a large number of users, and therefore not something the average blog would worry about.
So, what’s the main difference between Co-Authors and Co-Authors Plus?