Steve Grunwell

Open-source contributor, speaker, and electronics tinkerer

Page 13 of 14

WordPress Security Basics

Each year thousands of websites are hacked. Sometimes it’s by way of a crafty social engineer (someone who tricks someone into giving up information without realizing it) conning some unsuspecting user out of his/her login. Other times it’s a backdoor in some code that grants a malcontent access to a site.

If your site is running on WordPress you can rest easy – WordPress core is considered to be a very secure application. The downside to WordPress core being secure is that if someone breaks into your site you likely have nobody but yourself to blame. Never fear: these tips will help keep your site safe and sound.

Continue reading→

We The People WordPress Plugin

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.

Continue reading→

National Day of Civic Hacking at the White House

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.

Continue reading→

Speaking at WordCamp Columbus 2013

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!

Continue reading→

Quick Tip: is_login_page() Function for WordPress

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.

Continue reading→

Quick Tip: Troubleshooting /etc/hosts issues

I ran into an interesting error this evening: I was working on a new WordPress site for a freelance client when my local server (I use MAMP) would start hanging. Now my MacBook Pro is certainly past its prime (spring 2008, to be exact – I can still remove the battery) but there’s no reason a bare-bones WordPress theme running on my local machine should be slower than most of the external sites I’m visiting so I decided to do some digging.

Continue reading→

Using WordPress Advanced Custom Fields Exports

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.

Continue reading→

Automatically Recompile Sass upon Deployment Using Git Hooks

When I’m the only one working on a site, compiling my Sass files locally and committing the generated CSS isn’t the worst thing in the world. When you’re working in a team environment however, it’s necessary to consider that several developers of different experience levels may touch a site throughout its lifecycle. What would happen if a developer who had never used Sass needed to make an update to a site? How long would it be before someone starts complaining that the change they made to the CSS file was overwritten after the next compilation of the corresponding .scss file?

This technique has one goal: keep generated CSS files out of the git repository. In order to do this, we’ll need to make sure of a few things:

  1. Generated files are explicitly blocked from the repo (to prevent someone who doesn’t know any better from committing them)
  2. Automatically recompile our SASS files into CSS upon deployment.

Continue reading→

An Introduction to Sass in Responsive Design

I’ve been wanting to explore CSS pre-processors for several months and re-building this site seems like a good chance to get my feet wet. I’ve been following the debates between the two most popular pre-processors, Sass and LESS, and decided that for my purposes and experience, Sass would be a better fit.

Using a workflow that I learned in the Build Responsively Workshop, I wanted to create separate .scss partials for each of my breakpoints, then import them into my main stylesheet using media queries and @import statements within my main Sass stylesheet (style.scss). Normally I avoid @import statements in my CSS files (which would prevent stylesheets from being downloaded in parallel), but the compiled nature of Sass means that the only time these files are actually imported is when the actual CSS files are generated. Importing multiple Sass partials also a) keeps my styles organized better (with no performance hit) and b) allows me to easily re-use partials for alternative stylesheets.

Continue reading→

Quick Tip: Override WordPress Toolbar Styles

I’m working on a project right now that uses the WordPress Toolbar, that dark-colored bar at the top of the administration area (and optionally your site) since version 3.3, as part of the site template. Unfortunately the default styles didn’t quite cut it for this project, so I needed to come up with a way to override these styles with my own.

Continue reading→

Page 13 of 14

Be excellent to each other.