Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: wordpress

  • 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%.

  • Mailbag: Why Won’t You Help Me From Myself?

    Mailbag: Why Won’t You Help Me From Myself?

    I won’t name names here but I suspect people know who I’m talking about it. Please note, any comments naming names will be deleted. They deserve a chance to redeem their name and exactly who they are is not the issue.

    We never received any advice when we asked. Only warnings.

    A company made a new plugin, released it on WordPress.org, and then emailed a lot of people about it.

    It was brought to my attention first as a potential plugin violation. Was someone culling emails of the plugin install and using that to send email? A quick check of the code showed that was not the case and I informed the reporters as such.

    But then people said “I don’t even use this plugin and I got emailed.”

    At this point, I dropped them a note and explained that sending out spam email like that was going to piss people off. Lo and behold, their plugin was filled with one-star reviews.

    In the end, the asked the plugin to be deleted because they felt they could never recover. And I had not helped them, only warned them. This was true. I had not offered to help them make peace. I’d told them what was about to happen. And it did.

    Why didn’t I help them? Simply, I’m not their marketing department.

    As I said. Who they are doesn’t matter. They aren’t the first person to have this problem and they won’t be the last. And the question they’re really asking is two fold.

    First, why won’t I delete bad reviews based on people not liking getting spam. Second, why won’t I fix the problem.

    For the first, it’s because the experience of your plugin begins with how someone is introduced to it. If the first experience I have with a product is a racist or sexist ad, I will not use it. If it’s a product I was considering using, I might leave a comment or review saying “I would have used this but…” That was my experience. It doesn’t matter than I never used the product if my experience with it beforehand was strong enough to inspire me to leave a review.

    For the second, I can’t fix your problem. You did this to yourself. You had a poorly conceived of ad campaign and it shot you in the foot. You aren’t the first person to have this problem and you won’t be the last. You’re just someone else who screwed up and was hit by the social monster.

    And you know what? It sucks, and it’s not fair, but it’s something you did to yourself. Yes, you did it by accident, but covering it up doesn’t make it go away.

    We all screw up. We all have to apologize. If it was me? I’d reply to every single one star review and tell them I was sorry, it was a bad idea, I won’t do it again. And then I’d donate money in WordPress’ name to the EFF, explaining that while I can’t compensate them for the plugin without it approaching bribery, I can endorse the protection of our online privacy, which I flagrantly disrespected.

    It won’t be perfect, but it gets you started.

  • 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.

  • Mailbag: Delete My Account, Please

    Mailbag: Delete My Account, Please

    Becuase I’m active in the support forums, people find me and ask all sorts of questions. Like Charlie.

    I want to totally delete my word press account. I will PAY you to do this. Why? Because I worked for 15 minutes on the original word press website but found it too difficult for me and chose to go with a super easy Wix.com website, which is now published and works well. In searches I come up under wordpress only and my deleted wordpress website is still there. I want people to be able to find my wix site. I hope there is a way to TOTALLY delete my word press account. I will PAY you to do it.

    Sorry, Charlie, no can do. I checked his email and his domain that he put in his email and it was on WordPress.com so I sent him the link on .com for How to delete your site.

    I will note, I am sorry he wants to use Wix.com, but on some levels it is far simpler than WordPress (yes, I said it). It’s drag, drop, and done, and looks great on desktops. Mobile? That’s another story. But I had a paint-by-numbers GeoCities account back in the day, so I really don’t have room to talk about ugly first websites.

    The story doesn’t end here. Charlie asked me to do it for him.

    Even if he was a customer at my company, I would tell him no. I would send him directions on how to do it but I would not delete it for him. I don’t delete customer’s sites or data (unless the data is a Terms violation). Hell, even with hacked content, I back it up elsewhere first. Deleting someone’s data is an absolute, 100%, last resort. You should never ever do it. There’s no going back.

    Then Charlie asked me again.

    I suspect his issue was that he was really frustrated and wanted everything to die in a fire. Which I totally understand, but amidst all your anger, you need to take a deep breath and follow the directions. And, when someone tells you “I don’t work for that company, but I found out how to do it. Here you go!” perhaps you can say “Thank you.”

    Just a thought.

  • New Plugin: @Reply Two

    New Plugin: @Reply Two

    This blog has a cool trick in the comments section. The ‘reply’ link in comments will auto-generate your reply starting with “@person: ” and it does that with my plugin @Reply Two.

    The name is a pun because it’s a fork of the plugin @Reply (which has the slug reply-to), but it also has a ‘reply to’ feature (two … to … right?). I strip-mined the original and made sure it worked on the modern versions of WordPress. I made sure it looked good. And then I added in a feature I wanted, which was to allow for a way to see parent comments on the admin dashboard.

    That is, if you go look at a comment on the dashboard, you’ll see a little arrow that says “Show Parent Comment (15 words):” (or however many words). It strips out all HTML, so it’s a pretty accurate count. I wouldn’t want to use it on a site with a lot of really, really long comments where everyone was always replying to each other. It would make the comments page really slow to load.

    Stephen Cronin’s Show Parent Comment does the same thing there. His uses JS, and mine uses html5 with details-shim for fallback. Except for IE8. I hate IE8.

    I forked the plugin almost two years ago but I had it irregularly updated until Jeff posted about his experiences moderating comments on WP Tavern.

    The sad truth is that you can’t automate ‘enough’ of what makes moderating a pain in the ass. You can’t make it faster because it requires a human to read and pay attention to what they’ve read and process what it means. The part of the work that takes all the time is the part of the work that won’t be possible to teach a machine to do until we invent an AI.

    There’s a reason why spam-trapping isn’t perfect. While we have gotten pretty good about it, things will always get caught incorrectly, or let through when it should have been blocked. Why? Well we don’t yet have a way to scan someone for the intent in their heart. Metaphysics aside, we can’t find the answer in the soul of the person beside us.

    What we can do is make it easier for humans to look at a thing and go “Wait a second, that isn’t right!” Humans are generally good at that. We know what we’re ‘used’ to seeing and what we’re not. Hopefully that’s what @Reply Two does. Pun and all.