This weeked at WordCamp Vancouver I gave a talk called “Customizer-ing Theme Options: A Visual Playground”. I covered the basics of the Customizer API and did a case study with Nubrick, a Twenty Twelve child theme I built last year to learn about leveraging the Customizer API. Here are my slides:
Today is my first day as a Web Engineer at 10up!
I’ll be doing WordPress development full-time (eventually), and as if that wasn’t cool enough already, they’re generously going to donate the balance of my time (see: a lot) to contributing back to the WordPress project. So all that contributing I was doing on the support team, the docs team and in core I get to continue doing as part of my job. I’m totally pumped.
If you’re interested, I also wrote a blog post about it over on the 10up blog.
Just released v1.1 of Download Shortcode, with added support for subdirectory WordPress installs.
Thanks to a report from Stuart Sequeira, I realized I’d forgotten to re-add subdirectory support when I rewrote it in v1.0. I also regenerated the pot file to make sure the strings are included.
In short: Download Shortcode provides a shortcode for wrapping media links that forces them to download. It’s great for providing easily-downloadable MP3, jpg, mp4 or other media file types.
Want to contribute?
Download Shortcode is in active development on GitHub too, so if you’d like to contribute, pull requests are welcome.
In rewriting one of my plugins recently, I decided to try an experiment I like to call Filters, not options (a play on the oft-repeated WordPress mantra of Decisions, not options).
I think whenever you conceive a plugin, you’re aware that it has an express purpose and is meant to be used in a specific way. That purpose should be your guiding light.
The plugin, in case you’re wondering, is the recently-released 1.0 update of my Download Shortcode plugin, which allows users to output force-download links for files via a shortcode.
Out of the box, the Download Shortcode only supports files that live in the uploads directory. If you don’t have ‘pretty permalinks’ enabled on your site, the full URL including the download-script endpoint are exposed. If you do have ‘pretty permalinks’ enabled, the URLs will be rewritten to mask the endpoint, which is better for security. And none of this requires configuration outside of the normal WordPress site setup. Easy.
OK, so what if I wanna change it up?
Use the filters supplied in the readme. If you’re a developer or adventurous user, the examples should be more than enough of primer to get you started.
Example filters include:
- Ability to change the rewrite endpoint
- Change the supported directory
- Disable rewrites regardless of ‘pretty permalink’ usage
- Hiding the shortcodes after the plugin is deactivated or removed
Why do it this way?
Simple, it’s all about the 80/20 rule. 80 percent of this plugin’s users expect it to work in a very specific way. The remaining 20 percent might want to fudge with things a bit to fit their needs and that’s fine, but I’m inclined to cater to the majority.
Inevitably, this begets the discussion of whether filters can serve equally as well as options. I think they can and I’d go even further to say that I don’t think that extra options suit every plugin. Returning for a moment to the 80/20 rule, if 80 percent of your users won’t need the options, adding them is unnecessary overhead. It’s supposed to do a thing and it does it. If you want more out of it, you can use the filters or fork it and modify it however you want. The beauty of open aource.
Is this a perversion of the spirit of using filters in plugins? Is this even a good idea? I’m curious to hear from other plugin authors and welcome the feedback.