Tag: wordpress

The Fiscal Responsibility of 25%

“We’re going to deploy on December 20th.”

I winced.

I’m not Christian and December 25th is just another day when I binge watch Netflix. The 24th? Movie night! But I picked up a habit at the Bank and that was not deploying code for the last two weeks and first two weeks of the year unless the company was going to be fined if we didn’t.

I was brutal about that to people. I was harsh and mean and demanded lengthy justifications. I made them speak to senior management, who were hard to find around that time of year because every one was on vacation.

The reason for this was that the bank had a clear cut fiscal responsibility not to go down between Thanksgiving and a bit after New Years. That was when year end processing happened, and that was when many companies who used us were processing the most orders. For a lot of people, business booms right when everyone wants to take a break to be with their family.

WordPress runs 25% of the Internet.

We use it for blogging, for building Facebook-eqsue sites, for running ecommerce stores.

That means and we the developers of WordPress now have a responsibility not to break when we upgrade people. A huge responsibility. And it’s one we can never give with 100% assurance because of one simple fact.

We made WordPress open.

Anyone can make a theme or plugin. And while we do our best to test with core WordPress, we cannot test all of the 45k plugins in the repository yet. The best is maybe we could write a script to check for fatal errors on activation. But even then, can we test all 45,000 against all possible permutations of combinations?

That’s an incredibly massive number. All my factorial calculators, even Google, just said ‘Infinity.’ And we add about 9000 plugins a year. This is staggeringly huge and it gets bigger every year

But with this increase in share and use comes an incredible responsibility to 25% of the web. We cannot break their sites.

Of course I know that’s impossible. There will always be outliers. And even with the large user base that companies like Yoast have, the dearth of willing and capable Beta Testers for a free product is going to bite us. It’s part of what I asked what I did at the Town Hall at WCUS — Are we going too fast?

Speed cannot exclude us from a responsibility to our users. And with the increasing provenance of online stories and websites for everyone, pushing a change when we know that the majority of the world is celebrating something between Nov 15th and January 15th is reckless. Look at how many people want time off in those months to be with family. Look at how many businesses are running sales. Look at the amount of data transfer that spikes.

And then picture what happens when an update has a small bug that takes down one site in a thousand. 1/1000 of 1/4th of the entire Internet. If that didn’t make you shiver, do the math again. Imagine if Apple went down because they pushed an update right around Christmas?

The answers change sometimes, though. What if it was a security fix? Would that change your mind? It would change mine. A major upgrade around Christmas worries me. A minor one, not so much.

It may be time to call a year end moratorium on updates to our systems and apps. If they’re business and mission critical, test them as best you can, but consider if you have to update before that Christmas rush. Make people jump through hoops to prove they need the new shiny right now. If you know you’re understaffed or under heavy load, consider that as much as anything else.

1 January, 2016
Disclosure

One of the myriad reasons I push back on WordPress plugins is because someone didn’t disclose enough information about ‘phoning home.’ Phoning Home is simple concept that comes down to this “Don’t send data from the plugin users back to yourself (or anyone else), unless you’re a service. And if you are a service, make this clear in the readme.”

Simple, right? It’s totally easy to understand that we want you to tell people “Hey, if you use this plugin, it will report back to my servers…” Much of the time, this is obvious. A Facebook connection plugin, logically, contacts Facebook. Embedding YouTube playlists contacts YouTube. Those sorts of things we don’t worry about, though if you have your plugin say “This will pull data from YouTube” then it’s better. Sometimes this is less obvious, like if you use geoplugin.net to determine locations. Your plugin probably has nothing to do with that domain, but you still have to tell people about it so they know.

But why do they need to know?

First of all, this is the basic email I’ll send you if I see you’re not explaining the phone-home in your plugin:

Plugins that send data to other servers, call js from other servers, and/or require passwords and APIs to function are required to have a full and complete Readme so we can make sure you’re providing the users with all the information they need before they install your plugin. Our goal with this is to make sure everyone knows what they’re installing and what they need to do before they install it. No surprises.

This is especially important if your plugin is making calls back to your own servers. For the most part, we do not permit offloading of images or code, however in the case where you are providing a service (like Disqus or Akismet or Twitter), we permit it. The catch is you have to actually explain this to the layman in your read me, so they know where data is going.

Clearly there are some basic reasons, like we should know where our data is going for our own safety. There are also some surprising reasons to people who don’t think about these things, like legal ones. You’re calling out to other servers? What if my company legally can’t do business with them? Then we have the tin-foil hat reasons, like I don’t want to do business with Google so I don’t want to have Google JS in my plugin.

All that sounds pretty basic. And some of it is super obvious. If you’re making an app to communicate with Facebook, then it’s logically going to send data to Facebook. None of that surprises anyone, nor should it. With a service, one simply has to be up front about what the product does, what services it connects to, and why.

“This plugin pushes your comments from your Facebook page to your blog, matching users by email addresses with their Facebook accounts (if found).”

I just made that up. But it’s upfront, it’s honest, it’s direct, and it’s clear what’s being sent and where and why.

There’s another aspect to this, however, something that is far trickier and more complex. What happens when your existing tool adds a service?

The obvious answer is that you need to disclose this change to our users. As long as the users know what they’re getting into, then you are golden. The complex answer, the one I can’t really tell you a one perfect answer for, is how you might do this.

Why is this hard? It’s hard because there is no one right way to tell users about the change. There is no one perfect way to make sure users read the information. There is no one way to get all the data to all the people who need to know about the information.

And there sure as hell isn’t one way to make sure no one will complain about any of that.

When you make a change to the paradigm of what your tool does, taking a stand alone tool and adding in a service, you have to consider that a percentage of your users will rebel. This is simply because all those wonderful things you do about disclosing the service for new users have to be transitioned in a meaningful and logical way to existing users. And there is just no way to do that perfectly.

This doesn’t mean you shouldn’t try. This means you have to be creative and innovation and a little ‘in your face’ about the change. You have to give users an option, before the service kicks in, to say if they want their data shared.

21 December, 2015
Mailbag: Wasting Time

Today’s question comes from a Slack DM tossed my way about learning and possibly discarding Jekyll.

Don’t you think you’re wasting your time learning all these nonWordPress things?

Nope! Every single thing I’ve learned and discarded has improved my skill set.

Let’s take MediaWiki. Learning that taught me templating in a way that I never would have understood in WordPress. It also taught me about the perils of your ‘own’ language instead of HTML. While I’ve come to like Markdown, you still have to know HTML to make Markdown really work, because you need to understand what it is you’re writing.

And Jekyll? I learned a lot about importing and exporting data between ‘languages’ that don’t like each other. I also learned a lot about deployment of static content. Anything but FTP, right? Jekyll had me writing my own deployment scripts.

Now that I’m looking at Hugo, really not much has changed. I’ve learned GoLang, which is not all that different from things I already knew. But it’s expanding how I think about the logic structures. Hugo’s got an up on Jekyll in a lot of ways, like how easy it is to make loops for traditional blogs. Also it can handle remote JSON a little better, which sets me up for what’s next.

You see, all of this work, all this learning, is going to come back to WordPress.

What I want to do is manage my site in WordPress and have that output the JSON (via that awesome new JSON API I’ve been learning), which will in turn be dynamically called when I want to build my static HTML site.

For sites you’re not updating daily, or even weekly, this might be the magic you need. Everyone writes on WordPress. Someone has a command (or even a script) to run that collects everything from JSON and dumps it to Hugo, which generates the site for you to proof and then push.

Version controlling the content.

Let the users write in Wordpress while you bask in the glory of your static site that is, pretty much, unhackable as a CMS. I mean… what are you going to do to my HTML?

See?

It’s all WordPress.

18 December, 2015
Mailbag: Why did you ask that at the Town Hall?

Last weekend, at WordCamp US, I asked a question at the town hall.

At its heart, the question was that did Matt feel the rapid release cycle of WordPress major revisions was too fast? I asked this based on the concerns I hear voiced by plugin developers, generally the smaller shops (single person or under ten teams), who not only have to test their plugins with the new versions of WordPress, but also learn these new, rapidly evolving and changing, libraries like ReactJS and the REST API.

Matt’s answer was essentially no, and that he felt that things would only get faster. Also he said he didn’t think plugins should be one-person shops.

What did you think of the answer?

I was asked variants of this by many people that night and the next day.

I disagree with Matt somewhat.

This isn’t a shock. I’m sure he’ll read this and nod. But he and I both know that a health disagreement can be good for an ecosystem. I understand his point, and in many ways agree with it. A team project for plugins and really any development is what makes things improve faster. Two heads are better than one.

But at the same time, we look back on things like Yoast SEO, and to think that those can only exist while supported by a team is to forget the way that all of this, even WordPress, started.

One person has an idea. One person shares the idea. A second person makes a suggestion.

One person.

Of the 45,000 plugins in the repository, the majority happened because of one person. One person had an idea and a dream and built a plugin. One person learned a thing and shared it. One. And the harder we make it for that one person to grow, the harder it will be for them to become the next Yoast, or Woo, or Jetpack.

As of this post, we released four major releases of WordPress within 355 days. I think that speed for the sake of speed is as bad as dragging out feet and having one release a year. Yes, we have improved our stability by having more frequent releases, because we don’t rush to have an unready feature added to a release. There’s going to be another soon. And that’s a good thing.

At the same time, it’s pushed us to release faster and faster, and that causes the bar to be set too high to new people. It causes burnt out. It causes update fatigue.

I don’t think we should revert to ‘release when it’s ready’ again. That has as many problems (if not more) as ‘release X times per year.’ I do feel we need to consider the emotional health and the supportability of what we are releasing.

Do it well, do it fast, do it cheap. Pick two. And know that the price is from our blood and bone.

I think we should turn it down a notch. Just one notch. And we should stop releasing just to be sure we release a number of times a year.

11 December, 2015
Beginning to Understand JSON

Themes without php …

Dynamic content without page requests …

What about Multisite without Multisite?

These are all things I’ve heard when people talk about the JSON REST API and how it’s the next greatest thing in WordPress. Well great, but what is it?

REST stands for representational state transfer. It’s actually the juice that’s been powering the web since forever. RESTful systems generally run over HTTP (hypertext transfer protocol) and use the agreed upon language to get and put data. REST gives you a way to read and write data programmatically. You’ve been using it for years without even realizing it.

This means our question isn’t what is it, but why do we want it or care about it?

The WordPress REST API is a nice way to get at the data from WordPress without having to load all the heavy parts of WordPress. It’s useful for things like mobile apps, which don’t need to load everything, just the data, and it’s faster.

Now, yes, WordPress has an API, called XML-RPC, and it sucks. You’ve used it already if you use the iOS app. We also have APIs like RSS, but that’s pretty much read only. The reasons that the current implementation of XML-RPC sucks are myriad, but basically it’s due to security, abuse, sanitization, and weight. It’s powerful but expensive and risky.

The JSON API being added to WordPress aims to simplify and secure all that.

Want to get your site’s posts? Simply send a GET request to url.com/wp-json/posts. Update user with ID 4? Send a POST request to url.com/wp-json/users/4. Get all posts with the search term “awesome”? GET url.com/wp-json/posts?filter[s]=awesome. It’s that easy.

The WP API is very simply the interface to make it easier to get at your data. That’s it. How it does it is incredibly complicated. What it does is simple.

Make it easier to get at my data without loading WordPress itself.

What I dig the most about it is this idea.

Take a website running backbone js that calls the JSON API from your WordPress site. Say frontend.com and backend.com are your URLs. You blog on backend.com and use WordPress normally. Your readers will visit a non WordPress site on frontend.com….

Go on then. Hack the front end.

It’s not WordPress, so unless you introduce an endpoint that puts you at risk, you have a way to protect your content. Plus now you can upgrade your blog all you want without having to worry really about taking your blog down.

Obviously this isn’t perfect. By not using WordPress on the front end you won’t have access to a lot of features from plugins. Like related posts. And then again, maybe you can use related posts. Maybe you can even us Jetpack’s related posts.

Mind? Blown.

If everything WordPress can do the JSON API can do, then there’s nothing I can’t do. I can make any site where I run WordPress on the backend and anything I want on the front end. And now I can separate my site data, run by WordPress, and my theme and it’s options. I can dry run theme changes and layouts using my live data. I can tell the JSON API frontend.com site to ignore all posts with a special status, tell testend.com to use them, and draft posts.

Migrations become easier. Who cares where the backend is, as long as the API frontend.com page can call what it calls.

WordPress is becoming more and more of an application, and that is why we can all be excite about being at REST.

9 December, 2015
Calypso

You’ve heard about it. Calypso, the WordPress desktop editor for Macs. I’ve been using it and I’m going to give you a quick rundown on what I like and what I don’t.

Like

First of all, it’s Open Source, which is great to look at. Anyone can poke at it and play with it. It’s also a nice GUI to use. Markdown works out of the box if you have it set up in Jetpack. That’s awesome since I’ve gotten very used to using it thanks to Jekyll.

It’s very fast as well, which is great. Fast is good. It also saves rather quickly, even when I’m on some shitty wifi. It’s much faster than using the native WordPress editor.

There have been some bumps in the road, but the development is open to comments and suggestions and steering. Some of the decsions made make sense from every angle except the end users. Users use things in weird ways and, once explained, development seems willing and able to adjust.

Dislike

There’s no spell check. This makes me very sad (I’ve been told it’s a feature request). Clicking back and forth between my sites is a little annoying, and I can’t easily hide sites (or reorder them). There aren’t tabs either, which means I can’t write on three or four posts at once. Yes, I totally do that.

You can’t do Custom Post Types. Yet. This is a deal breaker for one of my sites. Basically I can’t manage my WordPress eCommerce store with this. You also can’t change color schemes. I somewhat wish that it would pick up my user settings and use the profile color from MP6 that I selected there. That way I’d have purple for some posts, green for others, and I’d always easily know where I was.

On the Fence

I don’t really like that it forces me to use Jetpack, but at the same time, the REST API isn’t in core yet, so this makes sense. Similarly, I don’t like that it’s Mac only, but I understand why. Unlike ‘traditional’ software development, the people on the WordPress.com project are primarily Mac users. Of course they went to Mac first. Since it’s open source, I’m hoping someone figures out how to Windows it up soon. Making it Unixy shouldn’t be too hard, since Mac is running Unix.

Back to Jetpack, I would love to see this forked and decoupled from Jetpack, using the REST API instead. Not because I hate Jetpack (quite the opposite) but because I’d like to set my father up with this, and he travels to China where WordPress.com (and Jetpack) are problematic thanks to the Great Firewall.

All in All, I Like It

So far, so good. I like Calpyso and it’s no great effort to remember to use it, unlike pretty much every other desktop app for WordPress. And yes, I’ve tried those.

7 December, 2015