WordPress 3.8 Released

colorsWordPress 3.8 has been released. This release is packed with tons of new features, including a completely redesigned Dashboard, which features better readability, is fully responsive, and comes in eight different color schemes. The new Dashboard is the final version of the MP6 plugin project (don’t use the plugin with WordPress 3.8), and you can read more about the design process from project lead Matt Thomas.

Along with the redesigned Dashboard, WordPress 3.8 includes a new theme management menu and the new default theme, Twenty Fourteen, a premium theme formerly known as Further from Automattic which has been updated and made free for every WordPress user.

All users can now safely update from Dashboard -> Updates or download and update manually, though you should probably backup first just in case, unless you’re already using VaultPress, which you really should be.

If you’re a WordPress.com blogger, you have nothing to worry about, as you’ve technically been running WordPress 3.8 for a while now and can activate Twenty Fourteen from Appearance -> Themes in your blog’s Dashboard.

WordPress 3.7 Released



Photo credit: borkazoid

WordPress 3.7 has been released. I know I’m getting to this a bit late, especially since over half a million of you have downloaded it so far, but I feel a need to point out why WordPress 3.7 is so awesome.

WordPress 3.7 includes a ridiculous amount of under-the-hood things which might go unnoticed, but I really want to highlight the new automatic updates. From 3.7 onwards, WordPress will automatically apply all minor updates (anything that’s 3.7.x), which means that you’ll immediately receive all security and stability updates. That’s a big deal. As long as folks upgrade to 3.7, and the WordPress team continues to be awesome about security fixes, there will never again be an insecure WordPress installation (unless the blogger disables automatic updates, which is just silly and negligent).

All users can now safely update from Dashboard -> Updates or download and update manually, though you should probably backup first just in case, unless you’re already using VaultPress, which you really should be.

If you’re a WordPress.com blogger, you have nothing to worry about, as you’ve technically been running WordPress 3.7 for a while now.

I Don’t Use Ad Blockers

No adblock 250I don’t use ad blockers, because there are some sites I rely on or enjoy reading, and those sites rely on ads to stay in business (servers are expensive, the staff needs to eat, etc). If they offer a paid option to remove ads, I pay it. If not, I want them to stay in business, so I don’t block their ads. With that said, there are plenty of “good” sites out there which are simply flooded with ads. I simply choose to not follow or frequently visit those. I can get my reading in elsewhere. For example, the news sites where and advertising sidebar (sometimes even multiple sidebars) take up the entire right half of the screen. I mean, how is that even a thing?! I just refuse to read anything on those sites, it’s distracting, and simply crazy.

There’s a lot to hate and a lot to love about advertising, and so many factors that have contributed to a rather rapid shift in the industry. In the early days, contextual advertising used to be the leader. Are you reading a post about camping? Great, here’s an ad for a campground in your area, or maybe you want to buy this tent from Amazon. Those were great times, as the ads kind of contributed something to the article, sort of a “related content” experience. It turns out, that doesn’t pay well anymore, at all, to the point where it may not even worth it. Simply put, advertisers are willing to pay good money for their ads to be seen, not to simply wait around for the chance that someone will write about a Fiat, Chromebook, or whatever product they’re selling. In a way, that’s nice because you could run one unrelated ad and make the same amount as you could with four contextual ads. I’m not saying I directly recommend one over the other, but one unrelated ad could make a site owner a lot more money than beating me senseless with contextual ads ever could.

There are lots of other ways to advertise now too, which is also contributing to a rapid price shift. Some site owners will go to where the money is, and some will go with whatever doesn’t inconvenience the reader. Site owners can make a killing off of interstitials (those “click here to continue to the article” ads), but those make me close the window and look for a similar article elsewhere. Others can still make a killing off of related affiliate links, like Uncrate. Others thrive off of sponsored content, like Quartz, where whole posts can be advertisements, but are easy to identify and therefore easy to ignore, or they actually could be well-written articles. Others have struggled with income from time to time, but do their best to stay afloat on a very minimal ad-to-content ratio, like The Verge.

In short, I don’t use ad blockers, as I value the sites I read which need ads to stay in business. In turn, I don’t bother to read sites which are insanely cluttered with ads. There are plenty of non-obtrusive ways to advertise. Sometimes that means you’ll make less money than if you had provided a Whac-A-Mole-like banner ad experience, but maybe it’s worth it? I don’t use ad blockers, but I don’t have to follow your site either.

This post was inspired by What’s Your Take on Advertising on Blogs? by WordPress.com support forum superstar, timethief.

(Disclaimer: To anyone who read this post, thank you. The words above are not necessarily indicative of the views of Automattic, WordPress.com, WordAds, or any of their affiliates. If you feel like quoting me for any reason, please know that this is simply my personal opinion. k thx bye)

Give iOS 7 Time

iOS CompThe day iOS 7 was released, there was a great disturbance in the Force, as if millions of iPhone users suddenly called out in terror and were actually not silenced at all. The change in the design direction of iOS came as a bit of a shock in iOS 7. It surprised me too, but it grew on me after a few days.

The shock brought out some colorful comments from folks, my favorites being the ones who claim that iOS 7 is so different, they’re moving to Android. Something in their minds struck on first impression, telling them that a simple change in design direction (not functionality) was so far different from the iOS they had loved that it would be easier to switch to an entirely different phone with an entirely differently operating system, like being so upset with this year’s model of your favorite car that you switch to a bicycle.

If the professional industry operated on first impressions like so many of these outspoken critics want them to, you would have no clue what a graphical user interface was, and you would instantly mock the concept of any device used to interact with a computer beyond a keyboard, like a mouse. Both of these ideas where on the chopping block at Xerox in 1979 before they were practically given to Steve Jobs. First impressions stifle design and development, whereas time nurtures them.

Apple spent almost a year on iOS 7, sketching concepts, finalizing designs, and constantly adjusting the finest of details, even after it was unveiled last June at WWDC 2013. At some point in that year, Apple employees began using iOS 7 in the real world on their devices, and soon after, thousands of beta testers were able to join the fun. iOS 7 wasn’t built in a day. It took time, patience, and an awful lot of revisions.

Extend to iOS 7 that same courtesy of time. You don’t need to give it a year, just a few days. Soon, iOS 7 will seem perfectly normal, and iOS 6 will seem worn and outdated.

Back on WordPress.com

WordPress MoveAfter ten days of blogging on WordPress.org, here I am, back on WordPress.com. It’s a decision made with both hope and regret, but one that I need to make in order to continue the work I started.

Over the past three years on WordPress.com, my ability to write code (PHP and JavaScript in particular) had degraded quite a bit. I had thought that by self-hosting my blog, I’d be more motivated to try new things, and force myself to learn as I inevitably broke things on my own blog. It turns out that such a tactic had the opposite effect. I had every intention to break things and learn, with daily plans even, but I was too timid to put my rusty skills to the test on a live blog.

Considering that, my main blog is now back on WordPress.com, but I’m keeping a few self-hosted test blogs around so I can break things and learn without fear. I still learned quite a bit in just ten days, like how to have a similar setup to WordPress.com, working with caching, choosing a stats program, and how to work with Genericons (which you can do on WordPress.com with certain themes). I even helped fix two bugs in the Authy plugin.

As for the rest of you still on WordPress.org, if you use Jetpack, I submitted a few bug reports and feature requests you might like. One of those might even be my first patch one of these days.

Finding Stats

Mint BarsAfter three years of blogging on WordPress.com, I moved back to a self-hosted WordPress.org installation so I could re-learn what I had forgotten and tinker with things that I had never tried before, like caching. When you’re on WordPress.com, you can only use WordPress.com’s built-in stats program, but now that I had a chance to tinker with many of the available stat services and software, I found that I wasn’t missing much (or didn’t need what I was missing).

Obviously, I’m running Jetpack, which gives me the same stats that I had under WordPress.com, but I was on my own now, and I wanted more. The first thing I went to was Google Analytics, but I stopped just short of installing it. Everyone knows what Google Analytics is, and so do I, but if part of running my own WordPress installation was about being on my own, why did I want to dive head-first into a hosted stats program? So, I moved on to what seemed to be the next best thing, Open Web Analytics, an open source and self-hosted direct competitor to Google Analytics. It wasn’t all that great. It has a lot of data, almost too much, but it has no way to filter out my own views, which I consider to be major failure in any stats program. Jetpack stats block your own views as long as you’re simply logged in to your WordPress site, it’s a great feature. If I visit my blog 80 times, and I get 84 visits in the day, I want to know that I actually got 84 visits, not 4.

Moving on, I found Piwik, and I loved it. It provides far more data than I could ever find under Google Analytics, it’s free and open source, it’s hosted and controlled entirely by me, it has a free iOS app for both iPhone and iPad, and best of all, I can block my own visits from being recorded! Piwik is great, and I really wanted to love it, but it’s just too much. At the very least, it reminded me that I really didn’t need all that data.

I wanted more than Jetpack’s stats, but not that much, which brings me to Mint. I had used Mint before moving to WordPress.com, and it’s still here and just as lovely as ever, and I can still block my own views with it. Mint starts off as a simple bare-bones stats experience which you can extend with Peppers, like plugins for WordPress. Just by adding the User Agent 007 Pepper, I had all I needed in addition to the stats provided by Jetpack.

You may notice that there’s a lot of feature overlap between Jetpack and Mint, but that’s a very good thing. No stats program is perfect, not even Google Analytics. Each one filters out bots and bad visitors to a certain degree, some “security” browser add-ons block certain stats programs, and the occasional bug or glitch can foul anything. You will never find two stats programs that agree with each other, and that’s why it’s nice to have more than one to average things out a bit.

In summary, if you have a huge site and love data, I highly recommend Piwik. It’s a gorgeous stats program that I wish I could justify using. As for myself, I’m sticking with Jetpack and Mint.

Caching with WP Super Cache

After three years of blogging on WordPress.com, I moved back to a self-hosted WordPress.org installation so I could re-learn what I had forgotten and tinker with things that I had never tried before. I figured the first thing I’d tackle would be caching, since I hate caching. Makes sense, right? Sure . . .

Now, before I continue, I’d like to point out that I’m not a scientist. I won’t include any specific numbers for three reasons. One, I prefer to do my own investigations and I encourage you to as well. Two, Dashboard Junkie already did this. Three, I lost my numbers in a catastrophic syncing accident, but I didn’t lose my overall findings.

I hate caching. I know it’s necessary, I know it does wonderful things, but especially on a dynamic blogging platform like WordPress, I can’t stop wondering if I’m looking at a current up-to-date page or an old cached page. When I first got started with WordPress eight years ago, WordPress was not as complex as it is now, and the web was just slow in general. In short, caching was only a requirement if you were a major news site. Today, the web is fast, and WordPress is a bit more complex. Gone are the days of grabbing a coffee while your page loads. Now, folks close the browser window or simply go elsewhere when a page doesn’t load in a few seconds. If you have a public-facing site, and your server can handle the caching engine (move to another host if it can’t), you should be using a caching plugin.

I’m sure you’ve already seen the Dashboard Junkie article linked to above, showing in particular the difference between a stock WordPress site and one with a caching plugin. The differences between load time and how many requests the server can handle is astronomical. In short, a stock WordPress site will take roughly twice as long to load as a cached site, and while a stock WordPress site can handle a large amount of daily traffic, a cached site can handle a flood of visitors when you’re mentioned on the front page of a major news site. In case you’re wondering, I saw the same exact thing.

There are a lot of caching plugins to choose from, but I went with WP Super Cache, because it’s simple, and it’s developed by a fellow Automattician. After trying almost every configuration over the course of five days, I settled on the following:

  • Use mod_rewrite to serve cache files: Yes, PHP is easier because you don’t have to edit .htaccess files, but PHP is already tasked with generating your site anyway, so why force it to also negotiate the cache? This is the type of thing that mod_rewrite was made for.
  • Don’t cache pages for known users: Less caching means lower performance of course, but then again, I still kind of distrust caching.
  • Don’t cache pages with GET parameters: Pretty much a necessity, unless you want to cache things like the panel that loads when someone shares your post via email, and other such things which really should never be cached.
  • Cache rebuild: This will still serve a cache file if a new one is being generated, probably good if you’re being hammered by millions of viewers.
  • Extra homepage checks: Occasionally serves a non-cached version of the homepage, which is good because sometimes caches miss things, and the homepage is where all the action happens.

It’s also worth noting that I did not choose “Compress pages so they’re served more quickly to visitors,” because Dreamhost already compresses page content on its way out to the viewer. I didn’t notice any notable performance or page size improvement when adding WP Super Cache’s compression, so I chose to spare the resources and left it off.

So, that was an awful lot of text, and thank you for reading this far! If you remember oh so long ago, I encouraged you to do your own investigations. I used Is My Blog Working? for the bulk of the data, Pingdom Website Speed Test as a secondary source of data, and Google PageSpeed Insights as an anecdotal third number which I’m sure will mean something to someone (higher numbers are better, and that’s about all that’s helpful there). Every time you make a change to the cache, clear it, wait about 15 minutes for it to catch up, then run the test three times at all three sources. If you’re on a shared server, your performance can be impacted by other sites on the server, so either average out the results or take the best from all three tries.

Back on WordPress.org

So, before I get too far into this post (or perhaps before I even start it), I should point out that there are essentially two recognizable types of WordPress. There’s the main one, WordPress.org, which is blogging software that you install on a hosting provider. You own it and manage it, so there are fewer restrictions, but there are more responsibilities. Then, there’s WordPress.com, a blogging service which offers you a free WordPress-powered blog with the option to purchase additional upgrades. Someone else manages it for you, so there are some restrictions, and additional features cost extra, but you don’t have to worry about anything (like features breaking, incompatibilities, downtime, etc). For a more in-depth analysis, please refer to this handy chart.

I used to blog with WordPress.org, but since joining Automattic about 3 years ago, I switched to WordPress.com, since WordPress.com is an Automattic product. It was great to get down in the trenches with our users and help to put out fires as I found them, but I found that my ability to code in PHP and JavaScript had degenerated quite a bit. There’s really no way to tweak a blog outside of CSS on WordPress.com, so no way eventually lead to no need, which lead to no want, which lead to a severe lack of practice and ultimately a loss of knowledge. Now that we have grown to 190 Automatticians, I figured there’s enough of us in the trenches on WordPress.com that I could go back to WordPress.org. Being back on WordPress.org frees me up to experiment with code again and break things on my blog, which I have been doing all weekend.

With the polite prodding of Mike Schroder over the years, I came back to my first-ever hosting provider, DreamHost. A lot has changed over the past nine years at DreamHost, all for the better. Resurrecting a nine-year-old dormant hosting account was no easy task, but Mika Epstein saved the day. It was like moving back into an old and much-loved home. Transferred a blog this size was rather rough and interrupted with frequent errors, but Michael Koenig of the WordPress.com Guided Transfer team had the magic touch and had my WordPress.com blog up and running on WordPress.org in a matter minutes. I don’t mean to sound like a commercial for one of our products, but the ability to sit back and let someone else who does this for a living (dozens of time a day) take charge of the whole situation is well worth the price.

There are a lot of handy built-in features on WordPress.com that are unfortunately left behind when you switch to WordPress.org, but it’s easy to either get them back or supplement them with something else. First, you’ll need Jetpack, which provides many of WordPress.com’s built-in features. Then, it’s just a matter of finding things to provide you with the security and reliability that WordPress.com is known for. Having talked with the folks behind Sucuri several times, I went with them for security. They’re good people, and you can trust them with the safety of your site. I also locked this down a bit more with Authy’s two-factor authentication plugin. Choosing what to use for reliable and automatic backups was an easy decision. I went with VaultPress, another Automattic product that’s well worth the price. Finally, you don’t have to worry about updates on WordPress.com, and you don’t have to on WordPress.org either, as long as you’re running the Automatic Updater plugin (from fellow Automattician Gary Pendergast).

In short, if you don’t like breaking things, stick to WordPress.com. If you want to experiment, WordPress.org is for you. DreamHost is great, and you’ll want to try Jetpack while securing everything with Sucuri, VaultPress, Authy, and the Automatic Updater plugin.

My Grandfather’s Flight Data Recorder

My grandfather, Elwood Jack Rosenbauer, passed away yesterday. What many of you probably don’t know, because it is sadly under-documented, is that he lead the team at Lockheed Aircraft Service Company which pioneered the reusable and highly durable flight data recorder that is still in use on commercial and private aircraft today.

The flight data recorder is always on for the duration of the flight, recording cockpit and radio conversations, as well as metrics like altitude, airspeed, and fuel flow. Able to survive the most extreme of crashes, the flight data recorder is invaluable in investigating and preventing aircraft accidents.

Regarding their advances in the field of flight data recorders, my grandfather published Modern Aircraft Accident Investigation Equipment and Techniques in the Winter 1981/82 issue of Lockheed Horizons. Considering that these were only printed once, and that I can’t find a single copy of this particular issue online, Sarah and I have transcribed his article for historical purposes. A copy of the original article can be downloaded from the same page.

“[T]he overall activity of accident investigation, and particularly the role of the airborne flight recorder, are of vital concern to aviation. The accurate recording of critical factors of aircraft performance has proven invaluable in aircraft accident investigation in helping to pinpoint the cause of an accident and in instigating measures to prevent future recurrences.”

So, the next time you’re on an airplane, remember that something my grandfather helped to design is watching over you, improving your safety on future flights, and avenging you should anything tragic happen (though I hope it will never come to that).

James and Grandpa Jack