In early 2013 the White House released an API for their We The People petition site. In the spring they announced the National Day of Civic Hacking, set for June 1, 2013, and to celebrate were accepting applications to attend a hackathon on the grounds of the White House. I submitted a proposal for a WordPress plugin to embed petitions via shortcodes and widgets. To my surprise my plugin was approved and I was invited to attend the hackathon in Washington D.C.
Tag: WordPress
For those of you in the Columbus, OH area I’ll be presenting at this month’s Columbus WordPress Meetup on June 18, 2013 (a.k.a. tomorrow). The presentation is based on my latest blog post, WordPress Security Basics, and should be a good high-level introduction to WordPress security.
This past weekend I was invited to attend the second-ever hackathon at the White House as part of the National Day of Civic Hacking. The goal of the hackathon was to build cool applications and visualizations around the recently-released We The People API. As a result I built and released the We The People WordPress plugin, which enables WordPress users to easily embed petitions from We The People using shortcodes and widgets.
You can read all about my day at the White House on the Buckeye Interactive blog. The plugin source and my presentation from the hackathon are both available on Github.
For those of you in or around Central Ohio August 2-3 I’ll be presenting a talk based on “Keeping WordPress Under [Version] Control” at WordCamp Columbus 2013 in the Ohio Union at The Ohio State University. There’s a great line-up of speakers including Pippin Williamson (Pippin’s Plugins) and Samuel “Otto” Wood (if you’ve been developing with WordPress for any amount of time you’ve almost certainly read his blog).
The conference is trying something new this year and dedicating the entire first day (Friday, August 2) to a day-long WordPress beginners’ course with the second day (Saturday, August 3) focused more on WordPress awesomeness. If you work for a company that uses WordPress (as a client or as a vendor) now’s the time to beg your boss to send a group of WordPress newbies to WordCamp – learn how to use the world’s most popular content management system and get out of the office on a Friday in August? That’s one helluva deal for just $40!
When building WordPress themes, I typically try to keep as much code as possible out of the head section of my template and instead rely on the wp_head() action hook. By putting all of my wp_register_script() and wp_register_style() calls in one function I have a single place to manage (theme) assets and their dependencies. At the bottom of the function I usually like to enqueue my global scripts and styles (ones that will always be present) but am careful to keep them from appearing in the WordPress administration area.
I wrote about Elliot Condon’s Advanced Custom Fields plugin a while ago (see “Using Advanced Custom Fields for WordPress“), but I thought it might be helpful if I spent some time discussing how to overcome one of the most frustrating tasks related to the plugin: preserving custom field structures across WordPress environments.
The average WordPress developer may edit the custom fields in his or her development environment, write the code to display those fields, then manually re-edit the custom fields on production. Misspell a field name? Congratulations, you’re going to spend some time trying to figure out where you went wrong. The smart developer takes advantage of the Advanced Custom Fields export methods and doesn’t waste time doing the same thing over and over again.
Over the last year or so I’ve been deploying my sites and applications almost exclusively through Git. It took a while to get used to, but pushing all of my code through git has forced me to think through my code before committing (lest I get git blame’d), kept me concentrated on the task at hand, and has made collaborating with other developers so much easier. Deploying WordPress sites through Git require a little configuration; this article outlines my personal Wordpress-Git workflow.
I started work on a new WordPress site this morning and, after creating a couple of users, quickly got bored manually setting each user’s nickname and display_name properties in order to display authors as “firstname lastname.” I found a few forum posts in the WordPress support forums for “how do I automatically set the display name for WordPress users?” that had partial answers but no real solutions. Then I stumbled on this article by Rares Cosma that had just what I needed.
Rares’ solution uses the user_register WordPress action hook, which gets triggered when a new user account is registered. I modified his original version, streamlined it a bit, and applied the ‘firstname lastname’ pattern to both the display name and the nickname attribute.
I’ve been having a lot of fun with the new, open-source version of this site and have been looking for opportunities to experiment with things I’d have little reason to do on client sites. For instance, I wanted to see if I could get the current git checksum as a string using PHP (without resorting to shell commands) so that I could display it in the comments of my WordPress template. Once I was able to achieve that, I took it one step further and used it to invalidate browsers’ cached versions of my scripts and styles anytime I made an update to the theme.
