Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: essay

  • Say Thank You Publicly and Be a Better Coder

    Say Thank You Publicly and Be a Better Coder

    Takayuki Miyoshi is one of the best developers for WordPress you probably don’t know about. Miyoshi-san is quiet, thoughtful, and had written a handful of plugins you probably do know. Like Contact Form 7. He’s also written a wonderful multilanguage plugin called Bogo.

    He gave his very first presentation in English about why he uses free plugins. Miyoshi-san’s reasoning is plain and simple. By giving back to WordPress and open-sourcing the code, you have a greater chance of people helping you make your code better. More people will find bugs, more people will help you fix, more people will use it, and things will be made better for everyone.

    This is much the same idea as Pippin Williamson has about his open source philosophy. Now Pippin is pretty upfront that he thinks you should open source your plugins. And he’s got some strong views on supporting your site projects (and the responsibility there in). But he also mentioned once that he supports putting premium (i.e. paywall’d) products on Github.

    For free.

    That’s right. He said you can totally put your code up on Github for anyone to download or edit or fork.

    I thought about it for a moment, and how open and honest Pippin has always been with his code, and how some of his early WordPress code was not the greatest. Yes, I have been around WordPress long enough that some of the people I think of as being ‘The Real Shit’ about coding for WP were pretty bad. Maybe not as bad as I was when I started, maybe they were. My point is that Pippin, like everyone else, started out as a beginner. And some of his beginner code was bad, like everyone else’s.

    Would Pippin be as good a programmer as he is today without open source and without people giving him code corrections and suggestions?

    I think not.

    Furthermore, I don’t think that you’re going to lose any money here. The intersection of people who would both buy your plugin and are technically capable of using Github to install plugins is pretty small. I say this as someone who understands well the desire of people to get things ‘free’ from the internet and the seriousness of customers. If you make it easy for someone to buy your products (and in the case of WordPress, get updates for it), people will pay you. Because they like convenience. Remember the tale of Oatmeal vs HBO. If you stop people from being able to get your product easily, they just won’t.

    Most people are afraid of monetary loss, which I get. But you have to rethink things. First of all, most people won’t use Github. They won’t like not getting security updates, for one. And if you present Github as a technical place, they won’t use it. Done. Secondly, I happily bought the Person of Interest DVDs once Netflix got punched by (I presume) WGN on re-broadcast rights and couldn’t show me Season 4 before Season 5 airs. I get the added bonus of watching it on my Blu-Ray player, in super ultra HD. This behavior is NORMAL. Amazon made it easy for me to get what I wanted, and now I own it and if the Internet is out, well I’ll watch Root and Shaw and the Machine all day.

    And there’s something else to consider. The people who would use Github to get something for free are the folks who wouldn’t have paid in the first place. You’re losing money that you’d never have. To help explain this, I’ve made a little Venn Diagram for you, to show you how small this intersection is:

    percentage of people who would both buy your plugin and are technically capable of using Github to install plugins is pretty small

    I’m serious here. This is non-mathematical but based on my allegorical experiences of years in support be it free or paid. This is coming from someone who lives and breathes WordPress plugins. If you make it easy for them to pay, you will not lose money by putting the code up in a way for other developers to submit pull requests. That small sliver of green, the people who can use Git and would still pay you, those are your contributors. Those are the people you want. Because Open Source Code means more eyes, and more eyes means more reviews, and more reviews means better code.

    Everyone wins.

    And like Pippin and Miyoshi-san, I think that having your code available for others means I may learn new things and become a better developer. When I say ‘pull requests welcome’ what I mean is ‘teach me what you know, I love to learn!’ Even if I say “No, I don’t want to add that feature” trust me that your lesson was welcome and absorbed.

    When I went to WordCamp Tokyo, I had the intention of seeking Miyoshi-san out to tell him how much I like Bogo. That it solved a problem for me. That it just worked. That the code was good. Miyoshi-san also wanted to tell me thank you for the things I’ve done for him.

    It’s possible we both got a little teary eyed.

    And he and I agree on the big things. Make your code available for others to review and comment on and get pull requests. It will make you better.

  • Arbitrary Component Upgrades Are Not Helpful

    Arbitrary Component Upgrades Are Not Helpful

    Often WordPress gets shit for still supporting PHP 5.2. In fact, while they recommend 5.6 or up, WordPress still works on 5.2 and probably will for years to come, even though everyone knows PHP 5.2 is buggy, insecure, and not supported. No sensible webhost still uses it if there’s an alternative, but sadly there are reasons why some hosts are stuck on it.

    Why does WordPress still work on 5.2? Because there’s little benefit to be had in upgrading, and only harm. As I’ve said before, in the name of progress we run the risk of running ourselves right off the cliff. There’s nothing in 5.4 that WordPress needs. Please remember that I am a stickler about needs vs wants, there’s a lot we want, but nothing that is critical and that cannot be accomplished in a PHP 5.2 world. One day that will change, and when it does, we’ll rethink this whole argument. But right now, there is no need.

    My fear with a PHP 5.2 upgrade is that the people we would hurt with it are the ones least capable of resolving the problem. If we showed users an alert on their admin dashboard saying “You’re using PHP 5.2, please contact your hosting administrator and ask them to upgrade to a modern, secure, version of PHP” then we’re telling the wrong people something. It’s not the users who need to hear this, it’s the webhosts. And speaking as one? We know. Not only do we know, we actually care more than you do, and we’re working on it for everything not because of WordPress and it’s 25% market share, but because we know it’s the right thing to do.

    But this is not a PHP version debate. This is actually a reflection on something happening today. You see, WordPress still uses the 1.x branch of jQuery. Why? Again, it works. There’s no reason to upgrade to jQuery 2.x and doing so would break things. Among other reasons, WordPress still supports IE 8 which is used by 11% of computers out there. That’s not a small number. In fact, 11% of WordPress sites still use PHP 5.2! You see the situation? 11% is not insignificant.

    This comes up because Bootstrap 4 has decided to drop support for the jQuery 1.x branch. As far as I understand, they don’t want to support IE 8 and it’s 12% smaller. There isn’t a single code benefit that is included in jQuery 2.x that Bootstrap is using and, since jQuery 2.x is compatible with 1.x, you can switch back to it right now without any loss. But they don’t want to support IE 8. In fact, they don’t support it, and from that perspective it sounds wise, doesn’t it?

    It’s not.

    WordPress includes its own version of jQuery (still on the 1.x branch) and many other similar JS files, which have all been rigorously tested with both WordPress and many of the most common plugins. In order to provide the best compatibility and experience for users, WordPress asks that you not package your own (especially not an older version) and instead use wp_enqueue_script() to pull in WordPress’s version. There are many reasons for this but the simplest are as follows

    1. WordPress has jQuery. Save diskspace and leave your own out.
    2. If every plugin and theme removes WordPress’ jQuery and uses their own, there’s a potential for conflicts. Who’s jQuery wins?
    3. Using your own jQuery changes the way WordPress plugins and themes may work in unexpected ways.

    Can you remove jQuery and use your own? Of course! You just can’t host your code on WordPress.org if you do that.

    Now, there’s a missing metric here. What the percentage of sites using Bootstrap are on WordPress? For that I’m going to have to extrapolate. Looking at builtwith trends, it looks like 1.8% of the entire Internet uses a site with Bootstrap. Joomla 3.x uses v1.11.3, Drupal 7.x uses jQuery 1.4.4, and Drupal 8 will use 2.1.4. Remember this is a total rewrite of Drupal, though. They do not concern themselves with backwards compatibility when they jump to new versions, and that means you cannot measure the percentage of sites on the internet that will use Drupal 8. We can reasonably assume, since WordPress is fully backwards compatible, that the 80% of WordPress users who are on the 4.x branch will upgrade to 4.4 in December, and continue to do so for the future.

    Even if we cannot claim that 25% of Bootstrap sites are on WordPress, we can argue that with all major CMSs currently using jQuery 1.x, Bootstrap is about to kick a significant portion of their audience to the curb. Of course, not even 2% of the Internet is using Bootstrap. Will that be a great loss for the Internet? Not really. But it will incur a massive lost to Bootstrap.

    This real life example is precisely what I mean when I say that I worry about the user experience with our bold assumptions in our projects. Bootstrap’s logical assumption, that since they don’t support IE 8 there will be no loss by moving to components that don’t support IE 8 either, is a fallacy. They are thinking only on one level. They’re only seeing the ‘benefit’ (and I use this term loosely) of formally ending support for a user-base they never supported in the first place. This won’t impact their users, so it doesn’t matter.

    What they’ve neglected to consider is that their userbase actually encompasses other people who support IE 8. So while we know that no one using Bootstrap and WordPress supports IE 8, simply by dint of using Bootstrap, this new jQuery version actually forces them to exclude them, instead of passively. And by doing this, they will shortly find plugins and themes that use Bootstrap 4 rejected from the repository, which will only harm adoption of Bootstrap as a framework.

    This isn’t a threat. This is reality. This is the difference between “We don’t support IE 8” and “We would rather not support IE 8 than be compatible with 25% of the Internet.”

    Looking at it that way, it’s a simple call.

    Put jQuery 1.x back in. Make 2.x a recommended option. And move on.

  • I Am The 20%, And So Are You

    I Am The 20%, And So Are You

    We speak of innovation in WordPress. We present new features like post embeds and emojii, things not everyone wants to use on their sites, things that slow down sites, and we tout how we are making things better.

    But do we consider all the users when we do this?

    One of the tenets of WordPress, one of the core philosophies, is that we make decisions, not options. And we base these decisions on the 80% rule. We say if a feature will not be used by 80% of the user base of WordPress, we won’t add it.

    In early November, WordPress reached the 25% saturation threshold. We have, generally, taken that to mean that WordPress powers 25% of the Internet. A more accurate statement by W3Techs is this:

    WordPress is used by 58.7% of all the websites whose content management system we know. This is 25.0% of all websites.

    That means sites like my library (which is using Jekyll) or a site built by hand because it’s 5 pages are still considered. Jekyll and Github pages might skew the spectrum, but I’m going to give them the benefit of the doubt, that they know how to adjust for that. The statistics are really quite impressive.

    But with that volume of users comes a great responsibility.

    952,795,650 websites and counting. If we take away the 75% that are parked domains and redirects, we have 238,198,912 websites. Let’s call it 240,000,000. Of those, 25% are WordPress. 60,000,000 websites on WordPress. 48,000,000 users is 80% of that. Realistically, since we all have multiple websites, I’ll say 45,000,000 individuals.

    We are now trying to build websites and predict the behavior of 45,000,000 users.

    And you know what? I’m not excited about it. I was a little excited when we hit 16% but when we hit 18% and then 20%, I started to be filled with dread. The numbers of who uses WordPress are skyrocketing, and while I should fear the edge of the cliff, the day the inevitable WordPress killer steps out of the shadow and destroys us (by the way… that totally happened to Windows and Mac, didn’t it? They’ve been top dogs for even longer…), I worry that we’re now crossing a different line.

    When we start to propose things like embedding posts, or speeding up WordPress by shunting legacy code to a plugin, or dropping support for shortcodes, I fear we’re about to walk off the cliff ourselves.

    Let me paint you a picture of our world.

    We have spent a decade (close to 11 years) teaching people to use plugins. We explain that the exhaustive feature set of WordPress is best served by plugins. We have created a moderated, but not curated, repository of themes and plugins. We allow multiple plugins for innovation, for solving problems in new ways, and for demonstrating the myriad ways which one can use WordPress. Similarly we have taught them that themes are the right way to design and style a site, and themes can also be at the forefront of these innovations.

    That said, we have not yet managed to teach people how to pick a plugin or theme. They think it’s on WordPress.org, it must be safe. In general, the majority of themes and plugins on the WordPress.org repository are better written than their premium counterpart. Please note: majority – the minority of stunningly well written themes and plugins are not to be discounted, but let’s be real folks, they’re the minority. At the same time, the majority of plugins on the repository are crap.

    So let’s recap. If you take all the plugins in the world and round them up, more of the best ones will be on the WordPress.org free repository, but so will more of the bad ones. Following me still? Okay.

    Now end users, the majority of our 45,000,000 users, do not know how to pick a good plugin from a bad one. They don’t know how to read, or even skim the code to find out if it’s secure or not. They rely on maybe a quick search for reported issues, if that. They look, they find, they use. Of course they do. We told them to. We linked them to these plugins and said proudly we had found their solutions.

    On top of that, we’ve failed to teach them the importance of upgrades. WordPress core handles security updates, but since plugin and theme developers aren’t all as tenacious and consistent about their updates as WordPress core, we cannot always push updates of themes and plugins. WordPress is reliable. Not everyone else is. Not every one of the 50,000 plugins in the repository can possibly be.

    This means we don’t have the ability to just update everyone’s site with themes and plugins right away. We just don’t. There are some plugins and themes that will break when we do, or cause each other to break. Worse, there are some plugins and themes that don’t offer updates. Which means we have created a world where people don’t know they need to upgrade to be safe, or that they have to upgrade if they plan on using WordPress 4.6.

    And oh yes, we’ve taught them the importance of upgrading WordPress core very well. We’ve cajoled webhosts into upgrading WordPress core for them. We certainly upgrade WordPress core. That’s why over 80% of sites on WordPress are on the 4.x branch. We did our job well, but not fully.

    So when you talk about removing features from shortcodes, or dropping support for PHP 5.2, I think that the people who would be hurt by this would be the people least able to understand why.

    These people use plugins and themes and don’t know that Johnny Dev used old code. And if Johnny doesn’t update his code in time to meet the changes to the shortcode API, or there’s a bug that makes it not work in PHP 5.4, the user gets hurt.

    And when the user is hurt, they don’t blame Johnny Dev. They blame WordPress.

    They blame WordPress because we told them to install plugins and use themes. And they trust us. And in that one move, we have betrayed the trust.

    That’s the cliff I see us rapidly approaching. And that is the cliff I fear more than anything else. Our idealism and hope may drive us off the edge before we realize it.

    We developers, we builders of WordPress, are the 20%.

  • Mapping the Apple Watch

    Mapping the Apple Watch

    While in Japan, I had the chance to use my Apple Watch to get around and I figured out something.

    For walking or driving, the Apple Map app is the best to use with the Apple Watch. Not only do you get turn by turn directions with the haptic taps, but you can quickly see what’s next if you’re not sure what side of the street to be on. The haptics I love:

    A steady series of 12 taps means turn right at the intersection you’re approaching; three pairs of two taps means turn left…

    I use this feature constantly. It’s brilliant to be able to walk around and enjoy the area I’m in without worrying that I’ll get too terribly lost. As I walked through Kanda, my wrist tapped “tap-tap, tap-tap, tap-tap” and I turned left like a boss. The only time I used my phone was when I was at a five-way intersection. I can even use it to walk from my father’s apartment to his mother-in-law’s house a few blocks away. Or the 7-Eleven (which are awesome in Japan).

    For public transportation, the Google Maps app is brilliant. No. It’s phenomenal. Ueno station, in Tokyo, is one of the more complicated and confusing stations I’ve ever seen. It’s crowded, it has a damn shopping mall on top of it, and it’s where seventeen major train lines meet. The Google Map can, most of the time, tell me what track to be on and when for what train.

    Ueno makes Penn Station look tiny.

    But Google Maps can’t do ‘both.’ In fact, I’ve learned the Google Maps app is getting worse at things. You see, you go through Ueno to the Keisei Skyliner (the train to the airport) when you take the train from my dad’s apartment to Narita. It’s very simple. Takasaki line from Ageo to Ueno, exit Ueno via the South (not the Park) exit. Turn right. Pass the duck. Done.

    Instead of showing you a walking route, when I asked Google Maps to get me to Narita, it drew a straight-as-the-crow-flies line from Ueno Station to Keisei Skyliner. Yeah. Not so much there, Google-San.

    It only got worse when I wanted to take the train from Ageo to Kanda for WordCamp. You’d think that Google would be able to alert me, since they have an Apple Watch App, with taps “Hey, get off the train at the next stop.” But they don’t. In fact, the Apple Watch app just lists the directions, not very well, and doesn’t give me alerts. Even worse, you can’t easily track from the iPhone to the Watch. When I put in a direction on my Apple Maps, it automatically triggers the map on my Watch. Google Maps only shows ‘recent searches’ and Work and Home.

    It’s an absolute fail to use the technology properly.

    To make Google Maps ‘right’ for the Watch is pretty simple.

    1. Direction alerts. Tell me when to turn left or right. Steal it from Apple or make your own.
    2. Change train alerts. Tell me when I should get up. This will prevent people from sleeping through their stops.
    3. Give me easy directions to anywhere. Let me set up a path on my phone and immediately transfer it to my Watch.
    4. Use Siri. “Hey Siri, use Google Maps to get me home.”

    Four things. I’d settle for the first two, though I think the first three should be a priority for user experience.

    Until then, I’ll have to use my iPhone for transportation in a strange land, and my Watch for walking around the planet.

  • The Security of a Lifetime License

    The Security of a Lifetime License

    A few years ago, before I started working for DreamHost but after I decided I wanted to do WordPress all the time, I bought the StudioPress All Themes Package. For $500, it gave me a lifetime access to all their themes, all their future themes, support, and more. So I tucked away all my ad and ebook income for a while and bought it the day before a 50% deal hit. Of course, right? Brian being a wonderful guy, saw my amused tweet and credited me the difference.

    Since then, I’ve pretty much been a nothing but StudioPress shop. Almost every site I run on WordPress is using StudioPress themes. I’ve gotten free upgrades for all their themes, free versions of the ‘pro’ themes (all the HTML5 friendly ones), and it’s very much been worth it to me.

    But licensing is a strange subject. Chris Lema recommends charging annually (instead of monthly). And while I have a lifetime subscription, the unlimited free support will be leaving this world soon. From what I’ve heard, this only impacts support. To be honest, I’ve filed less than ten support tickets in five years. And it’s not because I’m savvy. There’s very little that I need help with to use Genesis themes. They have pretty darn good directions on how to reproduce their demo sites, they have code snippets, and they have a friendly self-help forum.

    Basically, this code is tight. Right now I’m using the Generate Pro Theme on this site, but I also bought Utility Pro theme from Carrie Dils (worth it). The child themes rarely need updating, and all I ever have to worry about is the parent Genesis theme being updated, which is easy as pie. They have their own updater.

    My friend Amanda Rush (also a StudioPress fan) wonders if this heralds the end of days of unlimited forever support and licenses. I suspect so. Will I be annoyed if I have to start paying for updates? Maybe, but mostly because I have a serious concern about security.

    Let me paint a picture for you. I get a free parent theme or plugin, it could be Genesis (the StudioPress parent theme) or WooCommerce (a popular ecommerce plugin), and I purchase an ‘add on’ of a child theme or an extension plugin. I pay for a year, and I’m happy. The add-on does what I wanted, I get my updates, and everything’s cool. Then one day, 370 days later, there’s a major issue. A massive security hole and suddenly my site is vulnerable!

    My license has run out.

    Do I get the update or not?

    Do I get notified of the update or not?

    I’ve seen this play out over and over again with sites like CodeCanyon and ThemeForest. How do people who have purchased a product get alerted properly and given the ability to update? We’re spoiled because if Jetpack or WooCommerce itself has a critical hole, those plugins are free in the WordPress.org repository. And I know, from working on that team, that if there’s a big enough issue, then the free plugins get updated and the update is pushed out to everyone. It’s rare, but when it happens, it’s for the benefit of everyone involved.

    The sad truth is most one-off shops can’t do that. WordPress.org can update all branches of your plugin. If you’re properly using versions for your plugins and themes, then you can release version 2.3.1 to fix a bug, but also fix that bug on 2.2.4 and 2.1.9 and so on. And yes, WordPress can push those branches (2.3 and 2.2 and 2.1) so even people on older versions can get fixed.

    To the best of my knowledge, no one else does that yet.

    And, perhaps worse, some won’t even consider letting you have the security update because your license isn’t up to date.

    All that said… Should you buy it, knowing you may not get support and updates forever? Yes. Right now, the StudioPress Pro Plus All-Theme Package is on sale. $262.46 for every theme plus third party themes. The sale goes on until the 16th, so grab it this weekend.

    It’s an investment I’ve never regretted.

  • Mailbag: Why Jekyll?

    Mailbag: Why Jekyll?

    Why didn’t you convert your site to WordPress? You said you had to import it from Mediawiki to WordPress already.

    I had this conversation with my wife, too.

    WordPress is awesome at being a dynamic website. To be a static ‘wiki’ style website, it sucks. It’s not meant to be static like that. It’s not intended to be static. Even if you turn off comments on your site, you mean for WordPress to generate index pages and categories and the like.

    With WordPress, all that work is done on the server. When you visit a page, it’s generated for the first time. I may have a cache that lets reader number 2 see that page, but always the page, the HTML, is being dynamically built on-demand. MediaWiki works the same way. In contrast, Jekyll is dynamically built on my laptop and deployed as an in-situ static site. Each HTML page is a real HTML page on the server. No extra work has to happen. It’s small, it’s light, and it’s fast, because all that processing was done by me on my laptop before putting it on the server.

    And that actually illustrates the problem with WordPress, and why we struggle with things like Varnish and nginx and caching. We want our sites to do more and be faster. We need flexibility and posting to Twitter and dynamic page generation when we make an edit, because we’re constantly making changes.

    Except I didn’t. I don’t. Not the particular site I was working on, anyway. The site has about 1000 pages (probably closer to 600 once I decided not to import some of the things) and they’re pretty static. At most I updated them once a week for half the year. WordPress would be overkill. Hell, the Wiki was overkill and the only reason I kept using it was technological debt. I didn’t want to add to the debt. I didn’t want to make things even weirder and harder to use. I didn’t want to put a site more at risk with software I didn’t want to upkeep (MediaWiki, not WordPress).

    So it was clearly time to dig myself out with a little sweat equity and decide what I really wanted. I made a list of what I needed, what I wanted, and what I could live without. When I did that, Jekyll started looking more and more like a viable option. I would have spent as much time removing the aspects of WordPress I don’t need as I would have learning a new theme system and language.

    Also in the end I didn’t use the WordPress import. I manually copy/pasted content. The content was what I wanted, and I needed it text only, and MediaWiki made that damn hard to get at. Of course the Jekyll exporter for WordPress was pretty freaking cool. If I was pure WordPress to Jekyll, I’d be fine. I guess there just aren’t a lot of people doing MediaWiki exports.