Design Programming Uncategorized WordPress

Color Is Based on Surrounding Color

“The redness isn’t a property of the apple. It’s a property of the apple in combination with a particular lighting that’s on it and a particular observer looking at it.”

via These X’s Are The Same Shade, So What Does That Say About Color? : Shots – Health News : NPR.

Next to typography, color is the most important part of the visual design of your website. Yet, color is also very misunderstood. Color more than any other part of web design, does not live in a bubble. Color is about how things relate to each other. Saying that #990000 is an easy color to read can change if your background is black, white, or pink

Ensuring that colors contrast correctly means both ensuring that there is enough luminance contrast, but also so that there is enough simultaneous contrast. And if that isn’t enough, we also need to remember to take into account the psychological effect of different colors and the cultural meanings that our color can have.

These four factors combine to make color selection a non-trivial problem.  What makes color an even harder problem is that we are only at the type of the iceberg for color perception.  What else effects color display? Our screens calibration. The tools we use to change how color display based on the time of day. The cones in our eyes. The lighting in the room.

Color is far from a simple problem. All these factors combine to show why we can’t rush color decisions. They need to be thought out and considered from many angles. As Josef Albers wrote in the seminal Interaction of Color, “In order to use color effectively it is necessary to recognize that color deceives continually.”

Design Uncategorized WordPress

My Favorite Photo from WordCamp San Francisco 2014

One of my favorite parts of WordCamp San Francisco was seeing Mel Choyce wearing a bow tie. It’s great seeing more and more people wearing bow ties, especially when they are incredibly talented members of the WordPress community.

Programming Uncategorized WordPress

Changes should happen in Code, not in UI

If you are deploying your WordPress site, it generally doesn’t make much sense to have to go in and setup changes when you push the newest version live. When you push to production, production should have all your changes.

One more benefit of this method is that you never need to be signed in with a user who can change settings, change plugins, or change themes. Being signed in as a user with as few capabilities as possible is a one part of limiting your vulnerability in case of attack

This is what I use to stop the majority of activities from happening in the UI.

tl;dr; Don’t Update Options in the admin, update them in the code.

Uncategorized WordPress

The one article every WordCamp organizer should read

Too many conferences focus on the mechanics and skimp on the up-front editorial strategizing, shaping, and planning. It is not enough to simply hire people because they are respected in the industry, or because they are in demand, or because their name sells tickets, or because they are available.

via On Design Conferences | Jeffrey Zeldman Presents The Daily Report: Web Design News & Insights Since 1995.

I think too often as WordCamp organizers we forget that we are curating an experience and as such we need to think about what we want the attendees to walk away with.  We need to strategize, shape, and plan.  Planning doesn’t mean figuring out where to setup registration tables (though that does matter), it means planning what people will be talking about when they walk away from the event.  If they aren’t talking about something they learned, or some new way to think, the event wasn’t a success.  Go read the rest of Zeldman’s article so you can understand that “A trained ape can invite the same speakers who speak everywhere else.” and why you can do better.

Uncategorized WordPress

Show a notice when changing a multisite’s site admin email. props jorbin

Four years ago today, change set #13446 landed in WordPress core. It was a day that changed my life. The patch landed while I was sitting at Java Shack in Arlington, VA. I went back to my then girlfriend’s place and exclaimed “You won’t really understand this, but I just had a patch added to WordPress”. From that day forward, my code was going to be used by millions of people. Yes, this change wouldn’t affect most of them. It was a small incremental improvement. But it’s small incremental improvements that make good projects great.

My first Code Changes in WordPress

In May, I celebrated WordPress’s 10th Anniversary and noted all the friendships I made because of WordPress. That remains even more true today. I moved to NYC late last year and the person here who I’ve become closest with is someone I first met at a WordCamp. I found my apartment because of a friend that I made at a WordCamp. My involvement with WordPress even got me the job that I have.

WordPress isn’t a perfect project. If It was, I wouldn’t want to work on it as much as I do (that is a somewhat paraphrased quote I originally heard Andrew Nacin say). We have a lot of code to improve. The diversity of our contributor community needs improvement. We also need to do a better job of going outside of our community and bringing others into it. But hopefully in the next four years, I’ll have a chance to help improve all of it.

Uncategorized WordPress

I’m Speaking at WordCamp Lancaster

This coming weekend I’m presenting at WordCamp Lancaster. This is where I proposed the crazy idea of doing back-to-back-to-back lightning talks that are voted upon by the audience. It’s a challenge to myself (which is the theme of my introduction talk). I’ve built a little node app to handle the voting and selecting of my next set of slides for me. This is the first time I’ve been nervous about a presentation this far in advance as far back as I can remember.

There are about 30 tickets remaining right now. You should go and snatch one up before they are all gone. You might just see me make an idiot out of myself.

Uncategorized WordPress

Thoughts on Contributing to WordPress Core | Jeremy Felt

But that doesn’t happen. There’s always a place to contribute. Nobody comes out to bite when you create a ticket, nobody slaps your code down. In fact, the community loves when a new face appears on Trac with any type of activity.

The patch was eventually committed and I felt amazing. On the contributors list for 3.4!

Freaking stellar.

This is where the train starts moving. Once I was past that hurdle, a whole new world opened up. I wanted to contribute!

via Thoughts on Contributing to WordPress Core | Jeremy Felt.

Great post by Jeremy Felt about his path to contributing to WordPress, joining the community and how you too can do the same.

Programming Uncategorized WordPress

Profiling WordPress made easy with Varying Vagrant Vagrants

Varying Vagrant Vagrants provides a setup of WordPress that is ripe for you to start profiling the PHP WordPress and your themes and plugins runs. The combination of xdebug, Webgrind, and a simple chrome extension will have you looking at the PHP performance. Let’s take a look at what you’ll need to get going.

To start, you’ll want to clone the Varying Vagrant Vagrants (VVV) git repository if you don’t have it already. VVV comes with xdebug ready for you to turn on and Webgrind for you to view the xdebug output.

Once you have VVV installed, the next step is to enable the profiler. You have a couple of options for this. You can turn it on for all page views (which slows page views down considerably), or you can just enable it in “trigger” mode, when you pass a get/post parameter or have a specific cookie set. I like this option since it enables me to easily switch between profiling and not profiling. I also make use of the Xdebug Helper chrome plugin to turn the cookie on and off. It’s also enabled by default in VVV, so you don’t need to do any work. You do need to turn xdebug on, but that is as easy as connecting to your vagrant box and running [bash]xdebug_on[/bash].

Now that we are setup, we can turn on profiling in our browser.

In the browser bar, you’ll find a nice bug. If you click that, you’ll see a simple menu.

By default, disabled is selected. We want to select Profile.

Now that profile is selected, we will see a clock.

That’s all it takes to start generating the profiling information. You’ll need to do this for each site you want to be generating profiling data. You can also select disable at any time to turn off profiling. Once it’s on for one of our VVV sites, head over to webgrind at and you’ll be able to start seeing your data.

When you first load webgrind, it’s going to look kind of empty.

After you select a profile file (from the dropdown with “Auto (newest)” pre selected) and click “update”, you will see your profiling information.

And that is all it takes to get started with profiling on Varying Vagrant Vagrants with xdebug and webgrind. Happy Profiling.

Uncategorized WordPress

The Twenty Fifteen Theme

Since the decision was made to update the WordPress default theme every year, I’ve contributed to all five new WordPress default themes. My contributions have varied from inline documentation, to accessibility testing, to refactoring PHP to cleaning up some JavaScript (and many things in between). Since Twenty Fourteen had it’s spectacular debut, the talk has already begun on the next one.

Konstantin Obenland proposed the idea that Twenty Fifteen should be a simple theme. Take _s and just add CSS. While that is a noble idea, I think we could also challenge ourselves to rethink themes completely for Twenty Fifteen. Since Twenty Fourteen was released early (Before we even hit Twenty Fourteen!), we have plenty of time to be experimental.

I would like to propose that Twenty Fifteen be a single page app largely done in JavaScript. This will require the addition of the Rest API the WP API team is building, but would enable us to demonstrate what is possible for a theme with almost no PHP. Imagine a theme where the only PHP is functions.php and index.php.

Maybe this is just a crazy idea. I don’t know. But I do know that we as a community can challenge ourselves to build something amazing.

Uncategorized WordPress

The Difference a Cache Makes

I decided to run a quick test to see just how much caching matters in a WordPress. I ran this test against a stock WordPress 3.8 install running Twenty Fourteen using Siege. I used the base nginx config from Varying Vagrant Vagrants. The site was loaded with the Theme Test Data so it had more than one post.

I did three test runs, all of them using 100 concurrent users requesting the homepage 100 times for a total of 10000 page loads.

The first test run was a completely stock WordPress install.

Transactions:		         569 hits
Availability:		       34.19 %
Elapsed time:		      499.20 secs
Data transferred:	       30.00 MB
Response time:		       27.48 secs
Transaction rate:	        1.14 trans/sec
Throughput:		        0.06 MB/sec
Concurrency:		       31.33
Successful transactions:         569
Failed transactions:	        1095
Longest transaction:	       30.01
Shortest transaction:	        0.00

As we can see, it didn’t take long for the site to fail. Only 569 requests succeeded.

Next I enabled the memcached plugin and setup memcached (with the stock VVV memcached config).

Transactions:		        1047 hits
Availability:		       49.76 %
Elapsed time:		      629.86 secs
Data transferred:	       58.56 MB
Response time:		       28.51 secs
Transaction rate:	        1.66 trans/sec
Throughput:		        0.09 MB/sec
Concurrency:		       47.40
Successful transactions:        1047
Failed transactions:	        1057
Longest transaction:	       30.07
Shortest transaction:	        1.04

Almost double the number of transactions succeeded, but we still brought the server down.

Finally, I enabled batcache as a full page cache.

Transactions:		       10000 hits
Availability:		      100.00 %
Elapsed time:		      110.76 secs
Data transferred:	      593.44 MB
Response time:		        1.10 secs
Transaction rate:	       90.29 trans/sec
Throughput:		        5.36 MB/sec
Concurrency:		       99.56
Successful transactions:       10000
Failed transactions:	           0
Longest transaction:	        3.26
Shortest transaction:	        0.54

100% Success! You will also notice that this run took less than 20% of the time as my previous attempt where only ~1/10 of the requests succeeded.

Moral of the story: WordPress + Memcached + Batcache = Win!