Category: How It Is

Making philosophy about the why behind technical things.

Professional Utility
It’s well known I hate themeing. I can’t really design and I don’t know how to change thoughts to form like that. Words are my gift.

A year back, I changed this site to using the Utility Theme by Carrie Dils. Since then, I’ve moved on with another theme, for various reasons, but I still found Utility to be one of the nicest, cleanest, themes out there.

Recently, Carrie came out with Utility Pro and as she’s one of the nicest people out there, offered me a discount. The new theme costs more, starting at $69 and going up to $199 for a professional version with a Gruntified theme and source files. It’s a lot more than the $45 Utility cost, but I went ahead and bought the theme, not having a home for it quite yet.

After fifteen minutes looking at it and the code, I knew I wanted to use it.

What Carrie did “differently” with this theme is she made it mobile first. That means the entire site is designed to look good on a mobile device and the breakpoints are used make it look better are larger devices. This is the opposite of what many themes do, designing for large screens and adjusting for smaller. Her ‘media’ section is surprisingly small because of that, and the site resizes quickly and properly with no adjustments needed.

The next thing she did, and the thing that really was a selling point to me, was she made it accessible. One of the concerns I’ve been struggling with in the last year has been making my content accessible, and in specific my slides. I want everyone to be able to take my content and learn from it, and a theme that considers that means I have to worry less.

Finally, and here’s where she won my heart, she decoupled code from her theme. This is something that many theme devs and I agree on. A theme should theme, but code should be code. Which means that I don’t want my theme to include custom post types for example. But also she removed Font Awesome. I love it and use it, but by having it in the theme meant that every time the font upgraded, she had to upgrade the theme. We’re all used to upgrading plugins regularly, but themes rarely. By separating the two, she’s able to give the theme stability and the feature flexibility.

Am I using the theme? Today, yes.

Looks just fine in mobile (Google’s POV is jaded since I block them from scanning things).

It was the work of a few hours to convert a site from Going Green Pro over to Utility Pro. The only reason it took hours is that I picked up the non-developer version sans Grunt, which meant I had to split out the CSS into my desired sass files, fold in some of my custom functions, and finally fix the problem that had prompted the following comment:
```
/**
    This file has been modified by Mika to fit the needs of this.
    If you use it somewhere else, expect breakage. I hard coded
    some things in. Shut up, future me.
**/
```
Future me read that and sighed a lot. Finally I removed all the full calls, making everything relative or using the proper functions in order to dynamically add paths. Also I had to merge a Wiki, a Yourls Site, and a gallery into the look, and that meant some serious theme juggling. It didn’t help that with the new layout I decided to tidy up some of the sidebar content and optimize layouts.

I’ve done very little to rejigger the code. What I’ve messed with is unrelated to what Carrie’s design choices were and more with how Genesis approaches the few things I don’t fully agree with. I’m not yet using the welcome splash screen, since this site people come to for news first, but I plan to use it for major announcements.

Now, for $69, it’s a well made theme. Would I spend the $199 for the full version with the development tools and the Grunt files and the use on as many sites as I want? If I wasn’t me who liked to play with code and files, yes. If I needed this for clients, most definitely. StudioPress itself charges $59.95 for Genesis, and $399.95 for all themes in their repertoire, so from that aspect, this may seem expensive.

Chris Lema and I have some strong opinions on the cost of a WordPress theme. When you consider all the things you’re paying for, all the work of testing on mobile devices, accessibility, colors (which are also accessible), compatibility, plus a year of updates and support, that $200 is an amazing price to use on (say) a dozen websites out there.

I think it’s well worth the price to have this handy in my back pocket for anything I might need it for. And it’s a testament to Carrie how rapidly I realized I did need this and didn’t even know yet.

Check out Utility Pro. You won’t regret it.
4 February, 2015
Overreaction to Negative Reviews

I’ve long since held the belief that our reactions to critical judgement of our work hurts so much because it’s so personal.

This has never been more true than on the Internet. In the world of distributed and isolated development, we often end up writing in a sandbox. We sit down and tune out the world and write code. And then we just deploy it to the masses for real-world testing. Many people are unit testing, which helps a lot, but as we’re such a distributed development world now, we rarely get the sit-down feedback we might with a company.

With that in mind, perhaps the over-reaction of people to their bad reviews (codewise) is a function of this distributed environment.

You’ve seen it, I’m sure. You leave a low-star review on someone’s product, annoyed that it doesn’t do something you think it should, and you’re replied to with vitriol. You’re astounded! You know that a one-star review kinda sucks, but you didn’t expect name-calling or, worse, someone to find your personal contact information and tell you that you deserve to die and you’re an idiot for not understand what code is.

I didn’t make that up. That’s happened. And since it happens, the question is why does it happen?

It comes back to the way we both develop code and the way we share it. The easier we make it to share our code in things like Github or official, public, repositories like the WordPress.org plugin repository, the closer the connection we make between developer and user. If you consider how it ‘used to be,’ the person who wrote the code may never meet any of the people who use the code. I’ve used Safari for years, but I have no idea who wrote it. Conversely, I’ve actually communicated with many of the Chrome developers about issues I’ve see and unexpected results. And goodness knows we all just ‘cope’ with how terrible things can be in Microsoft Word.

We’ve made the world more accessible for people to communicate directly the issues they’re having with software. This is a good thing. It allows us to develop faster and iterate code faster. We make things better faster. At the same time, it opens us up to issues like handling negative reviews.

If you’ve seen the movie Office Space, there’s a character whose job it is to take information from the customers to the developers, because developers are bad with people. We all laughed at that because we all saw the grain of truth. That tiny nugget of truth was that people who can bury their heads in the sand for hours to invent things are kind of weird people, and they don’t always communicate the way the ‘rest of the world’ does. Of course, now it’s 2015 and we know that it’s just not so. We all communicate similarly. Some of us just have more patience than others because we’re used to working with people more often.

Sunday is the 17th anniversary of the term “Open Source” in how we use it today. There was a public call to use ‘open source’ instead of ‘free software’, and we heeded the call. But open source has changed a lot from that day. We’re not just talking about free software that anyone can take and develop but the open lines of communication that allow us to develop it by working with the users in a closer relationship.

While many of us develop in isolation, writing and testing code by ourselves, the moment we release it to the masses we’re terrified. What if it breaks? It will. What if it sucks? It does. What if people hate it? They will. But we do it anyway, and when we, the developers, get that one-star review, it hurts. It punches us in the gut and makes us want to walk away.

Except… it shouldn’t. Certainly some reviews are made by absolute prats who demand the unreasonable. We don’t reply to support tickets for our free software fast enough, or maybe we didn’t refund their money when our store clearly says ‘no refunds.’ Maybe they hated it because we declined to add a feature. Maybe they just wanted to rant at us for 500 to 1000 words.

Yes, those reviews that are clearly full of anger should be ignored. And yes, those will make you feel like total shit. But the other ones, the ones where someone says “I wanted to like this, but the developer pushes an update every week and it really isn’t adding anything useful. This plugin has become bloatware and I’m not using it anymore.” Well hey, that’s actually a very nice one-star review. It’s a sucky one to get, but it’s fair and just.

So why do people often demand we delete those one-star reviews, or reply back that the user has no vision and cannot see how the plugin develops, or that the code is the dev’s and you should thank your stars it’s free? It goes right back to how we develop. We’re not used to the feedback and constant communication with others about our code. We don’t present our code to the masses until it’s at a usable or workable stage. And there are practical reasons why, but it means we just don’t know what it will be like to work with others to develop until it happens, and it seems to always happens in bad way.

What should you do? Keep in mind that the people who hate your code may have a point. Try to be objective and see it fairly. But don’t be a pushover and don’t let the people who are legitimate mean people get you down. It’s not easy, though. It helps if you have other people to work with on your code projects. Trusted beta testers, or even developers who are willing to take a look. Get yourself out of your isolation and you’ll find it’s a whole lot easier to deal with the crazy, if only to have someone to laugh with.

2 February, 2015
Beta Testers
There’s a weird aspect to open source that can be hard to explain, and that is the ethos and practicality of Beta Testing. Beta Testing is one of the most important aspects of open source, because it’s only with the beta that we’re able to real-world test products. No matter how much planning and testing and automated tests you write, there is nothing quite as powerful as the real-world. We just can’t reproduce it well enough because, among other things, we can’t yet predict humans very well. Sure, cold reading is a thing because humans can be predictable, but that doesn’t mean we know how a tool will be used 100% of the time.

And being a beta tester is hard work. You have to be both a user and a developer, which are really two totally divergent mindsets. Testing as a user versus testing as a developer is as different as how you and a formula one racer drives a car. Input from both the users and the developers is critical to the growth of a project and the end results. But before we get into how one really betas, we have to ask a very important set of questions.

Should I be a Beta Tester?
- Are you brand new to the project?
- Do you use the products daily (or close enough)?
- Do you know how to manually clean up a bad install without losing your data?
- Do you make regular backups?
- Do you know the basic troubleshooting steps for the product like the back of your hand?
- Are you willing to test on your live site?
If you answered ‘no’ or ‘maybe’ to any of those questions, then you’re not yet ready to be an effective beta tester.

That last one may catch people by surprise. Testing on your live site is something we actually tell people not to do, but I’m here to tell you that the best beta testers are either testing on their live site or on a site they use every single day. Since I have multiple site I use daily, I picked the one I can live with if it dies and I use that for my live-beta.

Guess what? You’re on it right now. It’s a hallmark of how much trust I have in WordPress. I can count the issues I’ve had on one hand since I started this a few years ago. I make a backup every day, twice a day, and I have it in three locations. If my site goes down, I lose at most 12 hours of content, and for what I’m doing here, that’s okay. My other sites, I could not deal with that loss and thus I use stable. But I test with live because… well let me explain.

How do I test?

If you’re going to be a beta tester, then the you install the beta and you use the product.

You were expecting rocket science?

Most projects have a lot of automated tests and they’ll test what they know about and what they can. But absolutely nothing replicates real world use. The whole reason I test with a live site, and why I feel it’s important, is that this is as real as it gets. This site is updated regularly with plugins and theme changes. I add new content five times a week on the same Multisite installation. I add new content multiple times a day on another site. One is on trunk, one is not. This lets me constantly compare the experience between the two and makes me immediately aware that something is different. If it gets my attention, that’s important.

What I do with my site is equally important. I’m writing content, constantly, which means I’m using some of the fundamental, day to day features that WordPress absolutely must have. That kind of user testing cannot be scripted. There is no AI yet that can reproduce what machinations a human gets up to.

I like to tell a story about the time my coworker John and I were testing some tax software for the bank. We ran it through it’s paces, putting in data, and every time we tries to save at a certain point, the software crashed. It crashed hard. We called the vendor and talked to them about it, walking them through what we did, and lo, it crashed again. They couldn’t reproduce it, so we screen-recorded it and sent it over. They were astounded and sent out a tech from New York to Chicago to work on this. He couldn’t solve it, but he did see how we crashed it. Then they sent in their big guns, their lead developer, and he sat down and watched us. As soon as it crashed he said he knew what the problem was.

We were doing it wrong. We were entering bad data in a way no tax professional ever would, the system was trying to process the math and, because the logic was bad, it crashed. I pointed out that people would make mistakes and he agreed, saying it should have alerted us to an error in the form, not try to process anyway. A few days later, he sent us a new version which properly trapped the error.

While a scripted test might have caught that by looking for bad values before mathing, they were doing the obvious check. They checked if it was a number. They neglected to check if it was a permitted number. If you’ve ever heard me nag someone about proper data sanitization and validation, this is why. They made a code change, added it into their scripted tests, and learned and grew. But they couldn’t have done that without a real human thinking in a different, and unexpected way.

We can, and will, improve scripted tests, but they will never improve to perfection because humans are pretty crazy. Which leads us to the next step.

How to I report a bug?

This is generic for a reason.

First, make sure you can reproduce the bug. Get a clean build to test on and go through the steps again. If you’re not sure about the steps, make a note to yourself about generally what you remember and try it again. If you can’t reproduce it, call it a one-off and let it go (and debug for yourself, but that’s different). Once you can reproduce it on a clean build, document those steps.

You’re going to want to answer these questions:
- What were you doing?
- What did you expect to happen?
- What happened?
- What research did you do into the error?
- How do you reproduce it reliably?
Include any error messages. Explain what you did. Don’t say “It didn’t upload.” Instead, say “The upload hung, making no further changes on the page. I waited 15 minutes before hitting refresh. When I checked the media library, I saw the image was uploaded however when I looked at the file server, none of the thumbnails were there.”

This is why you need to know what you’re testing. With a failed image upload on WordPress, you should know that the image uploads and then it makes the resized images. Even if you don’t know that, you should know your images are in wp-content/uploads/2015/02/ and you should look there to see if you can find them. If you have a failed post, you should know to look at the post list page in WP Admin and see if the post is listed there.

You’ll get extra bonus points if you can find your PHP error logs and share pertinent information, but that isn’t always easy. When you reproduce the error, make sure you specify if anything special has to happen. Like if the image upload only fails if you’re uploading a PNG, note that. Or maybe it only fails on pages, but not posts. How weird is that, right? Note it.

Don’t worry about being technical here. Be accurate, be clear spoken, and assume the other person is relatively new at whatever you’ve broken. Don’t assume they know exactly what you mean when you said “Upload an image…” Be specific and say “Create a new post and press the ‘Upload’ button…” If you know there are multiple ways to upload an image, test those other ways. It’s a due diligence thing.

After you’ve reported the issue, keep informed. Make sure you get email alerts for it, make sure you reply to those emails for it. You can’t just report it and walk away, you have to keep tabs and pay attention. People may need you to clarify information and explain problems in different ways. Remember people can’t actually read your mind. What’s clear to you, because you did it, may confuse them.

And finally … be prepared to hear that it’s just not that big of a deal. Sometimes a bug isn’t a bug, but an intended change. You may not like it. Heck, you may despise it, but that doesn’t make it wrong.

What else?

What are your takeaways from beta testing? How do you do it?
28 January, 2015
MailBag: Why Do You Do It?

Zaman dropped me a year end note. He’s been asking people, interviewing them, for a site, and had three questions about why I do what I do (and a little bit of how). It deserved a public reply.

1.You have been actively volunteering at WordPress support forum and with your solutions individuals and companies save big chunk of money. Your family and Job at DreamHost are your top priorities. Then your priority becomes the website you run (halfelf.org). You still manage to take out couple of hours to hit WordPress forum. You mention in one of your blog that some people volunteer because they enjoy it and some do it to master skills. What drives you to volunteer at WordPress?

What drives me to volunteer at WordPress is little more than a bit of technical socialism. I give back because I get back, and it seems only logical and fair and just to make the time to do these things. Admittedly, having my job actually be know WordPress’ ecosystem and keep a good relationship between WP and DreamHost makes this far easier for me than most. But at the same time, I was doing this before it was my job. And I did it because I could.

I have a hard time explaining the need to give back to people, because it’s something you either understand in your heart or you don’t. Call it a random act of kindness to the universe, I help with WordPress because I can, because I enjoy it, and because it makes me feel good to do it. I won’t deny I get awesome emotional props from doing it, a feeling of absolute satisfaction and pleasure knowing I can help people, but it’s really just that. I like doing it. I make the time for it.

2.Your insights on halfelf.org are remarkable and the blog “whose responsibility is it” in particular draws my attention. You convey it is the business owner responsibility and not the WordPress core or Webhosting Company to perform due diligence before they install plugin’s. You also call out there is a need for more security experts. Is there a shortage of wordpress security experts in general or in wordpress public support forum?

Do I think there’s a shortage of WP security experts? No, I think there’s a shortage of security experts in general. I think the masses of people would rather do awesome and create awesome than study security and delve into things. The fact that I can think of a hundred ways to socially engineer going to see a movie for free without breaking a sweat, the fact that someone like Frank Abagnale was able to pull off what he did underscores the issue.

At our heart, humans want to trust. We want to believe people won’t screw with us. And when you factor in just how complex computers and code can be, of course we have faith that the people who write code are writing the best code to their ability and know what they’re doing. And we have faith that, when a bug or a security flaw is reported, people will fix it as fast as they can.

WordPress complicates this, since there are so many plugins and themes out there that there isn’t a centralized place to reply a problem. Even if there was, there’s no way to enforce the bug is fixed, and there’s no way to be certain everyone will upgrade. Just look at the nightmare from the RevSlider situation. Once you add in the world of non wordpress.org hosted code, it’s impossible to maintain any control.

If more developers were security conscious this might be less of the case, but it’s a problem in Open Source. The Heartbleed vulnerability is a prime example of that. One change, missed by many. It’s not just WordPress, it’s how we develop in Open Source. The speed of our work makes issues like this sadly more common and possible. So we need more people who love hacking into things and breaking them and then responsibly passing on fixes to make things more secure. I do feel that Github and sites like it are actually a great step forward. I can file a pull request with a fix and pass on the help in that way.

This does require hobbyists to step up and be a bit more of a true developer, but they have the most to gain from it in the end.

3. Examining and reviewing the plugin software may not be possible for small businesses. Do you have a list of plugins that should be avoided or a checklist that should be considered before installing the plugins? I am not asking if you to list here. May be an article in halfelf.org will be very useful for WordPress community.

I don’t have a list. I can’t have a list. It’s impossible, given the rapidity with which plugins are updated, fixed, released, and closed. It’s just not feasible. I tried, at DreamHost, to keep tabs on plugins like that for about a week. Then I gave up. It would be a full time job.

And I disagree it may not be possible for a small business to have an audit done on their plugins and themes. They can hire someone. It would be expensive, certainly, but frankly I find the alternative untenable. If you had a physical store, you’d pay to have a security audit once in a while, if only by your security company. This too is a part of running a business. Period. You just can’t dismiss it as ‘not possible’ when it’s your career on the line. Complicated, expensive, and annoying I will grant you. But you have to do it. Even if it’s just once a year, you’re a step or ten ahead from where you were before.

I’ll say this, however. I would expect someone like Pippin over on Easy Digital Downloads to be reviewing all add-ons he lists on his site. Anything he sells, certainly, but also this big list of free add-ons should be checked for basic security before being listed. In this way, a small company can know they’re reasonably secure with that suite of plugins.

Are there plugins that should be avoided? Sure. I suggest you avoid anyone you can’t figure out how to contact in case of a security issue, anyone who encrypts their code so you can’t read it, and anyone whom, when you do contact them, blow you off.

9 January, 2015
The Road to PHP 5.x

If you use WordPress, you may be surprised to see that WordPress still supports PHP 5.2

PHP 5.2 was released in 2006, which is nearly a decade ago, and in the way that the internet ages, an impressively long time. In 2010, only five years ago, the last version of PHP 5.2 was released: 5.2.16. At that point, PHP no longer supported 5.2, but did apply security patches. True end of life hit in January 2011.

But back in 2006, when WordPress was getting off the ground, a lot of people were still using PHP 4. Not 5, 4. It wasn’t until mid 2010 that WordPress itself dropped support for PHP 4 (and MySQL 4). At that point in time, roughly 11% of WordPress installs used anything lower than 5.2 and this made it a pretty safe bet.

So why does WordPress still support PHP 5.2? Today if you look at the (not very accurate) WordPress stats, you can see that over 30% of people still use PHP 5.2

Back in 2010, WordPress was about 10% of the entire web. It’s double that today, so 33% of people on 5.2 is significantly larger than 11% back on pre 5.2, and with those numbers, it’s easy to see why it has to keep supporting PHP 5.2 … for now.

But the next obvious question becomes why is PHP 5.2 out there? And the answer is that WordPress is only 22% of the internet. Flip that around and remember that 78% of the internet is not WordPress. WordPress is not everything, nor should it be, so the webhosts of the world do have to consider than when they begin to upgrade.

Most major webhosts are in some state of killing PHP 5.2 with fire (seriously I am very excited for when it’s finally gone from DreamHost). When we upgraded people to 5.4, we found a lot of people who had very odd code out there that just didn’t work on 5.3 or 5.4, and upgrades broke them. We also found a number of people using WordPress who broke, mostly because they’d customized PHP 5.2 and forgotten, but also some who were on things like WP 2.x and were shocked, just shocked, it needed to be upgraded.

As developers, we want to be able to force everyone into a place where we can upgrade PHP (and WordPress) and have no compatibility fears. We want to use the new features of PHP to allow us to craft better, faster, more efficient code. We want to give users the features they ask for. But we can’t until everyone upgrades. And thus the vicious circle begins.

Would WordPress dropping support for PHP 5.2 speed up it’s demise? No. Not at all. Because WordPress is a drop in the ocean of the hassle that is upgrades. Do I think WordPress should drop support for PHP 5.2? Yes, but not the way you’re thinking. I would love to see WordPress stop supporting 5.2 in the sense that it should stop testing against it and worrying about backwards compatibility with PHP 5.2. It should check, on upgrade and install, that PHP 5.3+ is used and go from there. Heck, if it had a big alert “Hi, you’re on PHP 5.2, please upgrade!” on the admin page, that would be awesome.

But I don’t know that there are any PHP 5.3 (or 5.4 … or 5.5 or 5.6) specific features that absolutely require WordPress to be on 5.4 at this time. Frankly, that doesn’t matter at all because the issues with upgrading are far less related to where WordPress is going and more directly the cause of where servers have been. Most hosts grow organically, servers being built following a process and then (eventually) via an automated tool. But because of that, a lot of old servers and operating systems don’t lend themselves well to upgrades because they’ve been built rather … higgeldy-piggeldy one might say.

It’s that history, the drama of people not seeing the future 10 years ago, that puts many hosts in a position where upgrade is actually going to mean moving users to a new server with new features. And that is not something to be done lightly. We can’t just pick people up when we want and move them. There will be downtime, there will be outages, there will be delays. And because of all that, these moves take longer than you want.

This is not to say the hosts aren’t doing the right things, just that they take longer than anyone (especially the host) would like. And believe me. No one wants PHP 5.2 gone more than a web host.

5 January, 2015
Mailbag: Where Do I Start Learning?

Kenny flatters me (though I think have better hair than Trump) asking this:

If I wanted to be a millionaire, I’d ask Donald Trump, which is why I’m asking you…What would you recommend as a learning path or in specific resources to gain foundational knowledge and expertise in WP/ hosting? Knowing what you know now and if you had to start from the beginning today, what would you do? Thank you.

The same place I did when I started.

I would download WordPress, install it, and use it every day for a while. Understanding how to use the product tells you more about how it works than almost anything else. All problems you have will, eventually be traced back down to code if that’s how your inclined, or documentation, or just plain understanding.

See, how I got good at WordPress was because I used it, I had problems, and I decided to learn how to fix it instead of relying on the kindness of strangers. If I had to do it all over again, I’d do it the same way because it let me learn at my own pace and in my own way. WordPress was a place where I could (and still can) sit and study how and why things work, ask questions, get answers, and learn from them.

How did I learn about hosting? Same way. I had problems and I asked my host. “This code I want to use says it needs PHP 5 and my server is PHP 4. How do I change that?” It was really that simple. They moved me to a new server for PHP 5 and I looked up why that was necessary. That was how I learned what a nightmare server upgrades are and why they’re so complex.

The secret to it all is I never said “It should be easy to…”

Weird secret, right? Well, how many times have you heard someone say “It should be easy to fix this problem!”

It’s not. It never is. If it was, we’d be done. It’s always hard or weird or prone to conflicts, which is why that wasn’t a statement I made. Instead I asked myself “Why isn’t this easy?” I wanted to know what made things hard.

But I’m blessed with a natural curiosity about the world and I want to dig into things to see why they do what they do. This is especially true when I’m trying to use them and they, for whatever reason, don’t do what I want. That spurs me forward into research and reading and understanding and then writing. Eventually I get to the coding part. Because isn’t that how we all learned in the beginning? We wondered and we played and we learned by doing and experiencing.

If I did it all over I’d do it the same way and use the heck out of WordPress.

2 January, 2015