Author: Ipstenu (Mika Epstein)

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
The Details of Your Life

Becuase it’s my son’s birthday this week, can you please do X faster?

I get emails like that a lot. It has to do with the nature of my volunteer work. It doesn’t really matter what the actual, technical, request is. Pretend it’s a request to reboot a server.

I don’t need to know that your partner left you, took your dog and your truck, and so it’s really the worst day in the universe for your site to be down.

The truth of the matter is I really don’t care. No one in support (dev or tech or any) actually cares about the country song that is your life. This doesn’t mean we don’t emphasize with you and feel sorry that you’re having a crappy day. It means the crappiness of your day doesn’t magically make us be able to do things faster.

That server reboot? All the sob-story in the world will just not make your server reboot faster. Got a security issue? Ranting about how life is unfair doesn’t get it fixed and reviewed faster.

We do get it. You’re having a shitty day and this one thing, this item that appears to be at the arbitrary whim of some relative stranger, is holding up your ability to feel better. Except we’re not. We’re following process and procedure for a reason. The world is bigger than just you, and we have to consider all of it when we do a thing.

If rebooting your server impacts more people than you, say 500 other people, then we can’t just reboot on demand. We have to ensure we won’t break them either. If the security fix isn’t complete, or worse, we find more insecure things, we can’t wave our hands at it. We know what hackers look for and we want people to be safe.

When you’re having the worst day of your life, when your server is down or your plugin is closed or your account is locked out, stop making it worse. Take a deep breath. Remember that the world is a big place. Ask politely and trust that the people are doing things to the best of their ability and speed and safety for you and everyone else.

4 December, 2015
It’s Okay To Overwhelm

“Your email overwhelmed me! I can’t do this!”

That’s what the email reply I got was. It had started innocently enough. Someone asked how to set up Multisite. I linked them to the article and sent them a free copy of my ebook WordPress Multisite 101.

He emailed back asking again how to to it and I replied that he needed to read the link and the ebook and, if he had a specific question, to ask, but otherwise, those two items were what I could do for him at the time. He wasn’t a customer, a client, or even a friend. He was barely a friend of a friend of a friend. There was no social contract or legal one. He was basically someone who asked a question.

Seven emails later and a very angry chain, he finally explained that he had already activated Multisite, before the initial emails, and it was broken. He could no longer log in and, damn it, he didn’t actually WANT multisite. So I explained he needed to un-do Multisite, showed him where (in the ebook, and via a link) he could get directions on that.

And that overwhelmed him.

Now at this point, my friend who introduced him to me apologized and said he’d explain to the guy what ‘taking advantage of someone’s kindness’ meant.

While I do feel sad that I overwhelmed someone and that he was in over his head, I don’t feel any guilt for not providing hands on help like that. There’s a limit to how much ‘freebie’ you can throw out into the world, and this fellow was not being very clear about what his actual situation was. If it had started with “I accidentally set up Multisite. How do I undo it?” I would have given him a quick set of directions with a note of “If editing the DB is too complicated for you, you’ll need to hire someone.”

There is no shame in hiring someone when you’re overwhelmed.

When you’re in over your head, you will make bad assumptions, get lost, and make expensive mistakes. If you think someone is expensive before you start your own demolition and plumbing, imagine how much the cost will be when they have to fix what you did to yourself? Websites are pretty much the same way. It’s the nature of the service industry really. You’re trying to perform a service on your own instead of paying an expert. If you get it right, awesome, you’ve learned new things and have a new skill! If not, you pay more.

But that’s actually why I think it’s okay to overwhelm someone sometimes. When you give them a large amount of data, if they’re willing to learn and concentrate, then they can learn not only about a process but about themselves. The issue isn’t the data dump but how we react to it.

When you’re overwhelmed, and believe me I’ve been there too, you have to take the elephant one bite at a time. You didn’t know how to drive a car perfectly the first time you sat in one. You couldn’t ride a bike from day one. You won’t be able to do anything 100% correctly out of the gate unless you’re a savant. Most of us aren’t.

Perfection is the enemy of progress, though. If we all wait until we’re perfect, we’ll never get anywhere.

It’s alright to be overwhelmed. It’s not alright (though certainly understandable) to let that prevent you from making progress.

Be overwhelmed. At if, in that moment, you learn one thing, then you’ve made progress.

2 December, 2015
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:

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.

30 November, 2015
Rant: Lightboxes and Scrolling

Lately I’ve run into a problem where a tool I’m using has a lightbox that’s cut off at the bottom of the screen.

This generally happens because I have my browser at half-height, or because I’ve pressed the ‘increase font’ keys to make a site 110% text for readability (WordPress P2, I’m looking at you). Here’s what life can look like for me:

This image shows a lightbox cut off midway. The bottom of the picture shows the bottom edge of my browser. Obviously I could make my browser window larger, and most of the time this is what I do. But should I have to? There are situations where I can’t do that, like on mobile. Whomever decided that overlays on mobile was a good idea needs to have their favorite sweaters eaten by moths.

Make your screen scrollable. Make sure your lightbox doesn’t get totally jacked up when a screen is ‘too small.’ A major part of responsive design is not just making sure your site works on mobile devices and ‘full blown’ computers, but that it works on all sizes of monitors when a browser isn’t maxed out.

Here’s another example:

In that image I have what I can only presume is an advertisment that wants me to click something. It’s not until I change my zoom to 75% that I can see this is an ad for Dropbox Business:

Oh and Dropbox was totally unhelpful when I reported these things, which is why they’re getting shamed. They said to fix my screensize.

When a similar issue happened with Slack, I got an apology and a promise to address it. Which they did within a week.

27 November, 2015